CVE-2025-39884
Full vulnerability record from the local CVENow database.
Description
In the Linux kernel, the following vulnerability has been resolved: btrfs: fix subvolume deletion lockup caused by inodes xarray race There is a race condition between inode eviction and inode caching that can cause a live struct btrfs_inode to be missing from the root->inodes xarray. Specifically, there is a window during evict() between the inode being unhashed and deleted from the xarray. If btrfs_iget() is called for the same inode in that window, it will be recreated and inserted into the xarray, but then eviction will delete the new entry, leaving nothing in the xarray: Thread 1 Thread 2 --------------------------------------------------------------- evict() remove_inode_hash() btrfs_iget_path() btrfs_iget_locked() btrfs_read_locked_inode() btrfs_add_inode_to_root() destroy_inode() btrfs_destroy_inode() btrfs_del_inode_from_root() __xa_erase In turn, this can cause issues for subvolume deletion. Specifically, if an inode is in this lost state, and all other inodes are evicted, then btrfs_del_inode_from_root() will call btrfs_add_dead_root() prematurely. If the lost inode has a delayed_node attached to it, then when btrfs_clean_one_deleted_snapshot() calls btrfs_kill_all_delayed_nodes(), it will loop forever because the delayed_nodes xarray will never become empty (unless memory pressure forces the inode out). We saw this manifest as soft lockups in production. Fix it by only deleting the xarray entry if it matches the given inode (using __xa_cmpxchg()).
Severity
MEDIUM
CVSS score
4.7
(v3.1)
Vulnerability status
Modified
Source identifier
416baaa9-dc9f-4396-8d5f-8c081fb06d67
Published
2025-09-23 06:15:48.227000
Last modified
2026-10-19 21:10:00.160000
View original CVE JSON
{
"id": "CVE-2025-39884",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2025-09-23T06:15:48.227",
"lastModified": "2026-10-19T21:10:00.160",
"vulnStatus": "Modified",
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: fix subvolume deletion lockup caused by inodes xarray race\n\nThere is a race condition between inode eviction and inode caching that\ncan cause a live struct btrfs_inode to be missing from the root->inodes\nxarray. Specifically, there is a window during evict() between the inode\nbeing unhashed and deleted from the xarray. If btrfs_iget() is called\nfor the same inode in that window, it will be recreated and inserted\ninto the xarray, but then eviction will delete the new entry, leaving\nnothing in the xarray:\n\nThread 1 Thread 2\n---------------------------------------------------------------\nevict()\n remove_inode_hash()\n btrfs_iget_path()\n btrfs_iget_locked()\n btrfs_read_locked_inode()\n btrfs_add_inode_to_root()\n destroy_inode()\n btrfs_destroy_inode()\n btrfs_del_inode_from_root()\n __xa_erase\n\nIn turn, this can cause issues for subvolume deletion. Specifically, if\nan inode is in this lost state, and all other inodes are evicted, then\nbtrfs_del_inode_from_root() will call btrfs_add_dead_root() prematurely.\nIf the lost inode has a delayed_node attached to it, then when\nbtrfs_clean_one_deleted_snapshot() calls btrfs_kill_all_delayed_nodes(),\nit will loop forever because the delayed_nodes xarray will never become\nempty (unless memory pressure forces the inode out). We saw this\nmanifest as soft lockups in production.\n\nFix it by only deleting the xarray entry if it matches the given inode\n(using __xa_cmpxchg())."
},
{
"lang": "es",
"value": "En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:\n\nbtrfs: soluciona el bloqueo en la eliminación de subvolúmenes causado por una condición de carrera en el xarray de inodos\n\nExiste una condición de carrera entre la expulsión de inodos y el almacenamiento en caché de inodos que puede causar que una estructura struct btrfs_inode activa falte del xarray root->inodes. Específicamente, existe una ventana durante evict() entre el momento en que el inodo es deshasheado y eliminado del xarray. Si se llama a btrfs_iget() para el mismo inodo en esa ventana, será recreado e insertado en el xarray, pero luego la expulsión eliminará la nueva entrada, sin dejar nada en el xarray:\n\nHilo 1 Hilo 2\n---------------------------------------------------------------\nevict()\n remove_inode_hash()\n btrfs_iget_path()\n btrfs_iget_locked()\n btrfs_read_locked_inode()\n btrfs_add_inode_to_root()\n destroy_inode()\n btrfs_destroy_inode()\n btrfs_del_inode_from_root()\n __xa_erase\n\nA su vez, esto puede causar problemas para la eliminación de subvolúmenes. Específicamente, si un inodo se encuentra en este estado perdido, y todos los demás inodos son expulsados, entonces btrfs_del_inode_from_root() llamará a btrfs_add_dead_root() prematuramente. Si el inodo perdido tiene un delayed_node adjunto, entonces, cuando btrfs_clean_one_deleted_snapshot() llama a btrfs_kill_all_delayed_nodes(), entrará en un bucle infinito porque el xarray de delayed_nodes nunca quedará vacío (a menos que la presión de memoria fuerce la expulsión del inodo). Vimos que esto se manifestaba como bloqueos suaves en producción.\n\nSe soluciona eliminando la entrada del xarray solo si coincide con el inodo dado (usando __xa_cmpxchg())."
}
],
"affected": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"affectedData": [
{
"vendor": "Linux",
"product": "Linux",
"defaultStatus": "unaffected",
"programFiles": [
"fs/btrfs/inode.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"versions": [
{
"version": "310b2f5d5a9451b708ab1d3385c3b0998084904c",
"lessThan": "9ba898c9fcbe6ebb88bcd4df8aab0f90090d202e",
"versionType": "git",
"status": "affected"
},
{
"version": "310b2f5d5a9451b708ab1d3385c3b0998084904c",
"lessThan": "f1498abaf74f8d7b1e7001f16ed77818d8ae6a59",
"versionType": "git",
"status": "affected"
},
{
"version": "310b2f5d5a9451b708ab1d3385c3b0998084904c",
"lessThan": "f6a6c280059c4ddc23e12e3de1b01098e240036f",
"versionType": "git",
"status": "affected"
}
]
},
{
"vendor": "Linux",
"product": "Linux",
"defaultStatus": "affected",
"programFiles": [
"fs/btrfs/inode.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"versions": [
{
"version": "6.11",
"status": "affected"
},
{
"version": "0",
"lessThan": "6.11",
"versionType": "semver",
"status": "unaffected"
},
{
"version": "6.12.48",
"lessThanOrEqual": "6.12.*",
"versionType": "semver",
"status": "unaffected"
},
{
"version": "6.16.8",
"lessThanOrEqual": "6.16.*",
"versionType": "semver",
"status": "unaffected"
},
{
"version": "6.17",
"lessThanOrEqual": "*",
"versionType": "original_commit_for_fix",
"status": "unaffected"
}
]
}
]
}
],
"metrics": {
"cvssMetricV31": [
{
"source": "[email protected]",
"type": "Primary",
"cvssData": {
"version": "3.1",
"vectorString": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H",
"baseScore": 4.7,
"baseSeverity": "MEDIUM",
"attackVector": "LOCAL",
"attackComplexity": "HIGH",
"privilegesRequired": "LOW",
"userInteraction": "NONE",
"scope": "UNCHANGED",
"confidentialityImpact": "NONE",
"integrityImpact": "NONE",
"availabilityImpact": "HIGH"
},
"exploitabilityScore": 1.0,
"impactScore": 3.6
},
{
"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"type": "Secondary",
"cvssData": {
"version": "3.1",
"vectorString": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H",
"baseScore": 4.7,
"baseSeverity": "MEDIUM",
"attackVector": "LOCAL",
"attackComplexity": "HIGH",
"privilegesRequired": "LOW",
"userInteraction": "NONE",
"scope": "UNCHANGED",
"confidentialityImpact": "NONE",
"integrityImpact": "NONE",
"availabilityImpact": "HIGH"
},
"exploitabilityScore": 1.0,
"impactScore": 3.6
}
],
"ssvcV203": [
{
"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"ssvcData": {
"timestamp": "2026-01-14T19:26:01.035116Z",
"id": "CVE-2025-39884",
"options": [
{
"exploitation": "none"
},
{
"automatable": "no"
},
{
"technicalImpact": "partial"
}
],
"role": "CISA Coordinator",
"version": "2.0.3"
}
}
]
},
"weaknesses": [
{
"source": "[email protected]",
"type": "Primary",
"description": [
{
"lang": "en",
"value": "CWE-667"
}
]
},
{
"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"type": "Secondary",
"description": [
{
"lang": "en",
"value": "CWE-667"
}
]
}
],
"configurations": [
{
"nodes": [
{
"operator": "OR",
"negate": false,
"cpeMatch": [
{
"vulnerable": true,
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionStartIncluding": "6.11",
"versionEndExcluding": "6.12.48",
"matchCriteriaId": "D35EB26A-CFDE-4E9A-9177-B36C1AF15545"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionStartIncluding": "6.13",
"versionEndExcluding": "6.16.8",
"matchCriteriaId": "8DA00A4E-AABB-4A69-AB39-67B22D0B36D2"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:o:linux:linux_kernel:6.17:rc1:*:*:*:*:*:*",
"matchCriteriaId": "327D22EF-390B-454C-BD31-2ED23C998A1C"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:o:linux:linux_kernel:6.17:rc2:*:*:*:*:*:*",
"matchCriteriaId": "C730CD9A-D969-4A8E-9522-162AAF7C0EE9"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:o:linux:linux_kernel:6.17:rc3:*:*:*:*:*:*",
"matchCriteriaId": "39982C4B-716E-4B2F-8196-FA301F47807D"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:o:linux:linux_kernel:6.17:rc4:*:*:*:*:*:*",
"matchCriteriaId": "340BEEA9-D70D-4290-B502-FBB1032353B1"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:o:linux:linux_kernel:6.17:rc5:*:*:*:*:*:*",
"matchCriteriaId": "47E4C5C0-079F-4838-971B-8C503D48FCC2"
}
]
}
]
}
],
"references": [
{
"url": "https://git.kernel.org/stable/c/9ba898c9fcbe6ebb88bcd4df8aab0f90090d202e",
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
]
},
{
"url": "https://git.kernel.org/stable/c/f1498abaf74f8d7b1e7001f16ed77818d8ae6a59",
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
]
},
{
"url": "https://git.kernel.org/stable/c/f6a6c280059c4ddc23e12e3de1b01098e240036f",
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
]
}
]
}