CVE-2025-39738 (GCVE-0-2025-39738)
Vulnerability from cvelistv5
Published
2025-09-11 16:52
Modified
2025-09-11 16:52
Severity ?
VLAI Severity ?
EPSS score ?
Summary
In the Linux kernel, the following vulnerability has been resolved:
btrfs: do not allow relocation of partially dropped subvolumes
[BUG]
There is an internal report that balance triggered transaction abort,
with the following call trace:
item 85 key (594509824 169 0) itemoff 12599 itemsize 33
extent refs 1 gen 197740 flags 2
ref#0: tree block backref root 7
item 86 key (594558976 169 0) itemoff 12566 itemsize 33
extent refs 1 gen 197522 flags 2
ref#0: tree block backref root 7
...
BTRFS error (device loop0): extent item not found for insert, bytenr 594526208 num_bytes 16384 parent 449921024 root_objectid 934 owner 1 offset 0
BTRFS error (device loop0): failed to run delayed ref for logical 594526208 num_bytes 16384 type 182 action 1 ref_mod 1: -117
------------[ cut here ]------------
BTRFS: Transaction aborted (error -117)
WARNING: CPU: 1 PID: 6963 at ../fs/btrfs/extent-tree.c:2168 btrfs_run_delayed_refs+0xfa/0x110 [btrfs]
And btrfs check doesn't report anything wrong related to the extent
tree.
[CAUSE]
The cause is a little complex, firstly the extent tree indeed doesn't
have the backref for 594526208.
The extent tree only have the following two backrefs around that bytenr
on-disk:
item 65 key (594509824 METADATA_ITEM 0) itemoff 13880 itemsize 33
refs 1 gen 197740 flags TREE_BLOCK
tree block skinny level 0
(176 0x7) tree block backref root CSUM_TREE
item 66 key (594558976 METADATA_ITEM 0) itemoff 13847 itemsize 33
refs 1 gen 197522 flags TREE_BLOCK
tree block skinny level 0
(176 0x7) tree block backref root CSUM_TREE
But the such missing backref item is not an corruption on disk, as the
offending delayed ref belongs to subvolume 934, and that subvolume is
being dropped:
item 0 key (934 ROOT_ITEM 198229) itemoff 15844 itemsize 439
generation 198229 root_dirid 256 bytenr 10741039104 byte_limit 0 bytes_used 345571328
last_snapshot 198229 flags 0x1000000000001(RDONLY) refs 0
drop_progress key (206324 EXTENT_DATA 2711650304) drop_level 2
level 2 generation_v2 198229
And that offending tree block 594526208 is inside the dropped range of
that subvolume. That explains why there is no backref item for that
bytenr and why btrfs check is not reporting anything wrong.
But this also shows another problem, as btrfs will do all the orphan
subvolume cleanup at a read-write mount.
So half-dropped subvolume should not exist after an RW mount, and
balance itself is also exclusive to subvolume cleanup, meaning we
shouldn't hit a subvolume half-dropped during relocation.
The root cause is, there is no orphan item for this subvolume.
In fact there are 5 subvolumes from around 2021 that have the same
problem.
It looks like the original report has some older kernels running, and
caused those zombie subvolumes.
Thankfully upstream commit 8d488a8c7ba2 ("btrfs: fix subvolume/snapshot
deletion not triggered on mount") has long fixed the bug.
[ENHANCEMENT]
For repairing such old fs, btrfs-progs will be enhanced.
Considering how delayed the problem will show up (at run delayed ref
time) and at that time we have to abort transaction already, it is too
late.
Instead here we reject any half-dropped subvolume for reloc tree at the
earliest time, preventing confusion and extra time wasted on debugging
similar bugs.
References
Impacted products
| Vendor | Product | Version | |||||||
|---|---|---|---|---|---|---|---|---|---|
| ▼ | Linux | Linux |
Version: 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 Version: 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 Version: 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 Version: 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 Version: 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 Version: 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 Version: 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 |
||||||
|
|||||||||
{
"containers": {
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"fs/btrfs/relocation.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "fa086b1398cf7e5f7dee7241bd5f2855cb5df8dc",
"status": "affected",
"version": "1da177e4c3f41524e886b7f1b8a0c1fc7321cac2",
"versionType": "git"
},
{
"lessThan": "fcb1f77b8ed8795608ca7a1f6505e2b07236c1f3",
"status": "affected",
"version": "1da177e4c3f41524e886b7f1b8a0c1fc7321cac2",
"versionType": "git"
},
{
"lessThan": "f83d4c81bda3b7d1813268ab77408f7a0ce691ff",
"status": "affected",
"version": "1da177e4c3f41524e886b7f1b8a0c1fc7321cac2",
"versionType": "git"
},
{
"lessThan": "39a93e1c9dbf7e11632efeb20fcf0fc1dcf64d51",
"status": "affected",
"version": "1da177e4c3f41524e886b7f1b8a0c1fc7321cac2",
"versionType": "git"
},
{
"lessThan": "125e94a4b76b7b75d194f85bedd628097d2121f0",
"status": "affected",
"version": "1da177e4c3f41524e886b7f1b8a0c1fc7321cac2",
"versionType": "git"
},
{
"lessThan": "4e403bd8e127d40dc7c05f06ee969c1ba1537ec5",
"status": "affected",
"version": "1da177e4c3f41524e886b7f1b8a0c1fc7321cac2",
"versionType": "git"
},
{
"lessThan": "4289b494ac553e74e86fed1c66b2bf9530bc1082",
"status": "affected",
"version": "1da177e4c3f41524e886b7f1b8a0c1fc7321cac2",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"fs/btrfs/relocation.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThanOrEqual": "5.15.*",
"status": "unaffected",
"version": "5.15.190",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.1.*",
"status": "unaffected",
"version": "6.1.149",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.6.*",
"status": "unaffected",
"version": "6.6.103",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.12.*",
"status": "unaffected",
"version": "6.12.43",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.15.*",
"status": "unaffected",
"version": "6.15.11",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.16.*",
"status": "unaffected",
"version": "6.16.2",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "6.17-rc2",
"versionType": "original_commit_for_fix"
}
]
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.15.190",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.1.149",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.6.103",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.12.43",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.15.11",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.16.2",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.17-rc2",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: do not allow relocation of partially dropped subvolumes\n\n[BUG]\nThere is an internal report that balance triggered transaction abort,\nwith the following call trace:\n\n item 85 key (594509824 169 0) itemoff 12599 itemsize 33\n extent refs 1 gen 197740 flags 2\n ref#0: tree block backref root 7\n item 86 key (594558976 169 0) itemoff 12566 itemsize 33\n extent refs 1 gen 197522 flags 2\n ref#0: tree block backref root 7\n ...\n BTRFS error (device loop0): extent item not found for insert, bytenr 594526208 num_bytes 16384 parent 449921024 root_objectid 934 owner 1 offset 0\n BTRFS error (device loop0): failed to run delayed ref for logical 594526208 num_bytes 16384 type 182 action 1 ref_mod 1: -117\n ------------[ cut here ]------------\n BTRFS: Transaction aborted (error -117)\n WARNING: CPU: 1 PID: 6963 at ../fs/btrfs/extent-tree.c:2168 btrfs_run_delayed_refs+0xfa/0x110 [btrfs]\n\nAnd btrfs check doesn\u0027t report anything wrong related to the extent\ntree.\n\n[CAUSE]\nThe cause is a little complex, firstly the extent tree indeed doesn\u0027t\nhave the backref for 594526208.\n\nThe extent tree only have the following two backrefs around that bytenr\non-disk:\n\n item 65 key (594509824 METADATA_ITEM 0) itemoff 13880 itemsize 33\n refs 1 gen 197740 flags TREE_BLOCK\n tree block skinny level 0\n (176 0x7) tree block backref root CSUM_TREE\n item 66 key (594558976 METADATA_ITEM 0) itemoff 13847 itemsize 33\n refs 1 gen 197522 flags TREE_BLOCK\n tree block skinny level 0\n (176 0x7) tree block backref root CSUM_TREE\n\nBut the such missing backref item is not an corruption on disk, as the\noffending delayed ref belongs to subvolume 934, and that subvolume is\nbeing dropped:\n\n item 0 key (934 ROOT_ITEM 198229) itemoff 15844 itemsize 439\n generation 198229 root_dirid 256 bytenr 10741039104 byte_limit 0 bytes_used 345571328\n last_snapshot 198229 flags 0x1000000000001(RDONLY) refs 0\n drop_progress key (206324 EXTENT_DATA 2711650304) drop_level 2\n level 2 generation_v2 198229\n\nAnd that offending tree block 594526208 is inside the dropped range of\nthat subvolume. That explains why there is no backref item for that\nbytenr and why btrfs check is not reporting anything wrong.\n\nBut this also shows another problem, as btrfs will do all the orphan\nsubvolume cleanup at a read-write mount.\n\nSo half-dropped subvolume should not exist after an RW mount, and\nbalance itself is also exclusive to subvolume cleanup, meaning we\nshouldn\u0027t hit a subvolume half-dropped during relocation.\n\nThe root cause is, there is no orphan item for this subvolume.\nIn fact there are 5 subvolumes from around 2021 that have the same\nproblem.\n\nIt looks like the original report has some older kernels running, and\ncaused those zombie subvolumes.\n\nThankfully upstream commit 8d488a8c7ba2 (\"btrfs: fix subvolume/snapshot\ndeletion not triggered on mount\") has long fixed the bug.\n\n[ENHANCEMENT]\nFor repairing such old fs, btrfs-progs will be enhanced.\n\nConsidering how delayed the problem will show up (at run delayed ref\ntime) and at that time we have to abort transaction already, it is too\nlate.\n\nInstead here we reject any half-dropped subvolume for reloc tree at the\nearliest time, preventing confusion and extra time wasted on debugging\nsimilar bugs."
}
],
"providerMetadata": {
"dateUpdated": "2025-09-11T16:52:13.228Z",
"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"shortName": "Linux"
},
"references": [
{
"url": "https://git.kernel.org/stable/c/fa086b1398cf7e5f7dee7241bd5f2855cb5df8dc"
},
{
"url": "https://git.kernel.org/stable/c/fcb1f77b8ed8795608ca7a1f6505e2b07236c1f3"
},
{
"url": "https://git.kernel.org/stable/c/f83d4c81bda3b7d1813268ab77408f7a0ce691ff"
},
{
"url": "https://git.kernel.org/stable/c/39a93e1c9dbf7e11632efeb20fcf0fc1dcf64d51"
},
{
"url": "https://git.kernel.org/stable/c/125e94a4b76b7b75d194f85bedd628097d2121f0"
},
{
"url": "https://git.kernel.org/stable/c/4e403bd8e127d40dc7c05f06ee969c1ba1537ec5"
},
{
"url": "https://git.kernel.org/stable/c/4289b494ac553e74e86fed1c66b2bf9530bc1082"
}
],
"title": "btrfs: do not allow relocation of partially dropped subvolumes",
"x_generator": {
"engine": "bippy-1.2.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"assignerShortName": "Linux",
"cveId": "CVE-2025-39738",
"datePublished": "2025-09-11T16:52:13.228Z",
"dateReserved": "2025-04-16T07:20:57.119Z",
"dateUpdated": "2025-09-11T16:52:13.228Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.1",
"vulnerability-lookup:meta": {
"nvd": "{\"cve\":{\"id\":\"CVE-2025-39738\",\"sourceIdentifier\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"published\":\"2025-09-11T17:15:35.443\",\"lastModified\":\"2025-09-15T15:22:38.297\",\"vulnStatus\":\"Awaiting Analysis\",\"cveTags\":[],\"descriptions\":[{\"lang\":\"en\",\"value\":\"In the Linux kernel, the following vulnerability has been resolved:\\n\\nbtrfs: do not allow relocation of partially dropped subvolumes\\n\\n[BUG]\\nThere is an internal report that balance triggered transaction abort,\\nwith the following call trace:\\n\\n item 85 key (594509824 169 0) itemoff 12599 itemsize 33\\n extent refs 1 gen 197740 flags 2\\n ref#0: tree block backref root 7\\n item 86 key (594558976 169 0) itemoff 12566 itemsize 33\\n extent refs 1 gen 197522 flags 2\\n ref#0: tree block backref root 7\\n ...\\n BTRFS error (device loop0): extent item not found for insert, bytenr 594526208 num_bytes 16384 parent 449921024 root_objectid 934 owner 1 offset 0\\n BTRFS error (device loop0): failed to run delayed ref for logical 594526208 num_bytes 16384 type 182 action 1 ref_mod 1: -117\\n ------------[ cut here ]------------\\n BTRFS: Transaction aborted (error -117)\\n WARNING: CPU: 1 PID: 6963 at ../fs/btrfs/extent-tree.c:2168 btrfs_run_delayed_refs+0xfa/0x110 [btrfs]\\n\\nAnd btrfs check doesn\u0027t report anything wrong related to the extent\\ntree.\\n\\n[CAUSE]\\nThe cause is a little complex, firstly the extent tree indeed doesn\u0027t\\nhave the backref for 594526208.\\n\\nThe extent tree only have the following two backrefs around that bytenr\\non-disk:\\n\\n item 65 key (594509824 METADATA_ITEM 0) itemoff 13880 itemsize 33\\n refs 1 gen 197740 flags TREE_BLOCK\\n tree block skinny level 0\\n (176 0x7) tree block backref root CSUM_TREE\\n item 66 key (594558976 METADATA_ITEM 0) itemoff 13847 itemsize 33\\n refs 1 gen 197522 flags TREE_BLOCK\\n tree block skinny level 0\\n (176 0x7) tree block backref root CSUM_TREE\\n\\nBut the such missing backref item is not an corruption on disk, as the\\noffending delayed ref belongs to subvolume 934, and that subvolume is\\nbeing dropped:\\n\\n item 0 key (934 ROOT_ITEM 198229) itemoff 15844 itemsize 439\\n generation 198229 root_dirid 256 bytenr 10741039104 byte_limit 0 bytes_used 345571328\\n last_snapshot 198229 flags 0x1000000000001(RDONLY) refs 0\\n drop_progress key (206324 EXTENT_DATA 2711650304) drop_level 2\\n level 2 generation_v2 198229\\n\\nAnd that offending tree block 594526208 is inside the dropped range of\\nthat subvolume. That explains why there is no backref item for that\\nbytenr and why btrfs check is not reporting anything wrong.\\n\\nBut this also shows another problem, as btrfs will do all the orphan\\nsubvolume cleanup at a read-write mount.\\n\\nSo half-dropped subvolume should not exist after an RW mount, and\\nbalance itself is also exclusive to subvolume cleanup, meaning we\\nshouldn\u0027t hit a subvolume half-dropped during relocation.\\n\\nThe root cause is, there is no orphan item for this subvolume.\\nIn fact there are 5 subvolumes from around 2021 that have the same\\nproblem.\\n\\nIt looks like the original report has some older kernels running, and\\ncaused those zombie subvolumes.\\n\\nThankfully upstream commit 8d488a8c7ba2 (\\\"btrfs: fix subvolume/snapshot\\ndeletion not triggered on mount\\\") has long fixed the bug.\\n\\n[ENHANCEMENT]\\nFor repairing such old fs, btrfs-progs will be enhanced.\\n\\nConsidering how delayed the problem will show up (at run delayed ref\\ntime) and at that time we have to abort transaction already, it is too\\nlate.\\n\\nInstead here we reject any half-dropped subvolume for reloc tree at the\\nearliest time, preventing confusion and extra time wasted on debugging\\nsimilar bugs.\"}],\"metrics\":{},\"references\":[{\"url\":\"https://git.kernel.org/stable/c/125e94a4b76b7b75d194f85bedd628097d2121f0\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"},{\"url\":\"https://git.kernel.org/stable/c/39a93e1c9dbf7e11632efeb20fcf0fc1dcf64d51\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"},{\"url\":\"https://git.kernel.org/stable/c/4289b494ac553e74e86fed1c66b2bf9530bc1082\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"},{\"url\":\"https://git.kernel.org/stable/c/4e403bd8e127d40dc7c05f06ee969c1ba1537ec5\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"},{\"url\":\"https://git.kernel.org/stable/c/f83d4c81bda3b7d1813268ab77408f7a0ce691ff\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"},{\"url\":\"https://git.kernel.org/stable/c/fa086b1398cf7e5f7dee7241bd5f2855cb5df8dc\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"},{\"url\":\"https://git.kernel.org/stable/c/fcb1f77b8ed8795608ca7a1f6505e2b07236c1f3\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"}]}}"
}
}
Loading…
Loading…
Sightings
| Author | Source | Type | Date |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
- Confirmed: The vulnerability is confirmed from an analyst perspective.
- Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
- Patched: This vulnerability was successfully patched by the user reporting the sighting.
- Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
- Not confirmed: The user expresses doubt about the veracity of the vulnerability.
- Not patched: This vulnerability was not successfully patched by the user reporting the sighting.
Loading…