CVE-2024-35784
Full vulnerability record from the local CVENow database.
Description
In the Linux kernel, the following vulnerability has been resolved: btrfs: fix deadlock with fiemap and extent locking While working on the patchset to remove extent locking I got a lockdep splat with fiemap and pagefaulting with my new extent lock replacement lock. This deadlock exists with our normal code, we just don't have lockdep annotations with the extent locking so we've never noticed it. Since we're copying the fiemap extent to user space on every iteration we have the chance of pagefaulting. Because we hold the extent lock for the entire range we could mkwrite into a range in the file that we have mmap'ed. This would deadlock with the following stack trace [<0>] lock_extent+0x28d/0x2f0 [<0>] btrfs_page_mkwrite+0x273/0x8a0 [<0>] do_page_mkwrite+0x50/0xb0 [<0>] do_fault+0xc1/0x7b0 [<0>] __handle_mm_fault+0x2fa/0x460 [<0>] handle_mm_fault+0xa4/0x330 [<0>] do_user_addr_fault+0x1f4/0x800 [<0>] exc_page_fault+0x7c/0x1e0 [<0>] asm_exc_page_fault+0x26/0x30 [<0>] rep_movs_alternative+0x33/0x70 [<0>] _copy_to_user+0x49/0x70 [<0>] fiemap_fill_next_extent+0xc8/0x120 [<0>] emit_fiemap_extent+0x4d/0xa0 [<0>] extent_fiemap+0x7f8/0xad0 [<0>] btrfs_fiemap+0x49/0x80 [<0>] __x64_sys_ioctl+0x3e1/0xb50 [<0>] do_syscall_64+0x94/0x1a0 [<0>] entry_SYSCALL_64_after_hwframe+0x6e/0x76 I wrote an fstest to reproduce this deadlock without my replacement lock and verified that the deadlock exists with our existing locking. To fix this simply don't take the extent lock for the entire duration of the fiemap. This is safe in general because we keep track of where we are when we're searching the tree, so if an ordered extent updates in the middle of our fiemap call we'll still emit the correct extents because we know what offset we were on before. The only place we maintain the lock is searching delalloc. Since the delalloc stuff can change during writeback we want to lock the extent range so we have a consistent view of delalloc at the time we're checking to see if we need to set the delalloc flag. With this patch applied we no longer deadlock with my testcase.
Severity
MEDIUM
CVSS score
5.5
(v3.1)
Vulnerability status
Modified
Source identifier
416baaa9-dc9f-4396-8d5f-8c081fb06d67
Published
2024-05-17 13:15:58.270000
Last modified
2026-10-30 13:17:26.290000
View original CVE JSON
{
"id": "CVE-2024-35784",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2024-05-17T13:15:58.270",
"lastModified": "2026-10-30T13:17:26.290",
"vulnStatus": "Modified",
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: fix deadlock with fiemap and extent locking\n\nWhile working on the patchset to remove extent locking I got a lockdep\nsplat with fiemap and pagefaulting with my new extent lock replacement\nlock.\n\nThis deadlock exists with our normal code, we just don't have lockdep\nannotations with the extent locking so we've never noticed it.\n\nSince we're copying the fiemap extent to user space on every iteration\nwe have the chance of pagefaulting. Because we hold the extent lock for\nthe entire range we could mkwrite into a range in the file that we have\nmmap'ed. This would deadlock with the following stack trace\n\n[<0>] lock_extent+0x28d/0x2f0\n[<0>] btrfs_page_mkwrite+0x273/0x8a0\n[<0>] do_page_mkwrite+0x50/0xb0\n[<0>] do_fault+0xc1/0x7b0\n[<0>] __handle_mm_fault+0x2fa/0x460\n[<0>] handle_mm_fault+0xa4/0x330\n[<0>] do_user_addr_fault+0x1f4/0x800\n[<0>] exc_page_fault+0x7c/0x1e0\n[<0>] asm_exc_page_fault+0x26/0x30\n[<0>] rep_movs_alternative+0x33/0x70\n[<0>] _copy_to_user+0x49/0x70\n[<0>] fiemap_fill_next_extent+0xc8/0x120\n[<0>] emit_fiemap_extent+0x4d/0xa0\n[<0>] extent_fiemap+0x7f8/0xad0\n[<0>] btrfs_fiemap+0x49/0x80\n[<0>] __x64_sys_ioctl+0x3e1/0xb50\n[<0>] do_syscall_64+0x94/0x1a0\n[<0>] entry_SYSCALL_64_after_hwframe+0x6e/0x76\n\nI wrote an fstest to reproduce this deadlock without my replacement lock\nand verified that the deadlock exists with our existing locking.\n\nTo fix this simply don't take the extent lock for the entire duration of\nthe fiemap. This is safe in general because we keep track of where we\nare when we're searching the tree, so if an ordered extent updates in\nthe middle of our fiemap call we'll still emit the correct extents\nbecause we know what offset we were on before.\n\nThe only place we maintain the lock is searching delalloc. Since the\ndelalloc stuff can change during writeback we want to lock the extent\nrange so we have a consistent view of delalloc at the time we're\nchecking to see if we need to set the delalloc flag.\n\nWith this patch applied we no longer deadlock with my testcase."
},
{
"lang": "es",
"value": "En el kernel de Linux, se resolvió la siguiente vulnerabilidad: btrfs: soluciona el punto muerto con fiemap y bloqueo de extensión Mientras trabajaba en el conjunto de parches para eliminar el bloqueo de extensión, obtuve un lockdep splat con fiemap y pagefaulting con mi nuevo bloqueo de reemplazo de bloqueo de extensión. Este punto muerto existe con nuestro código normal, simplemente no tenemos anotaciones de bloqueo con el bloqueo de extensión, por lo que nunca lo hemos notado. Dado que copiamos la extensión del mapa de archivos al espacio del usuario en cada iteración, tenemos la posibilidad de que se produzcan errores de página. Debido a que mantenemos el bloqueo de extensión para todo el rango, podemos escribir en un rango en el archivo que hemos asignado. Esto se bloquearía con el siguiente seguimiento de pila [<0>] lock_extent+0x28d/0x2f0 [<0>] btrfs_page_mkwrite+0x273/0x8a0 [<0>] do_page_mkwrite+0x50/0xb0 [<0>] do_fault+0xc1/0x7b0 [< 0>] __handle_mm_fault+0x2fa/0x460 [<0>] handle_mm_fault+0xa4/0x330 [<0>] do_user_addr_fault+0x1f4/0x800 [<0>] exc_page_fault+0x7c/0x1e0 [<0>] asm_exc_page_fault+0x26/0x30 [< 0>] rep_movs_alternative+0x33/0x70 [<0>] _copy_to_user+0x49/0x70 [<0>] fiemap_fill_next_extent+0xc8/0x120 [<0>] emit_fiemap_extent+0x4d/0xa0 [<0>] extend_fiemap+0x7f8/0xad0 [< 0>] btrfs_fiemap+0x49/0x80 [<0>] __x64_sys_ioctl+0x3e1/0xb50 [<0>] do_syscall_64+0x94/0x1a0 [<0>] Entry_SYSCALL_64_after_hwframe+0x6e/0x76 Escribí un fstest para reproducir este interbloqueo sin mi bloqueo de reemplazo y verifiqué que existe un punto muerto con nuestro bloqueo existente. Para solucionar este problema, simplemente no utilice el bloqueo de extensión durante toda la duración del mapa de archivos. En general, esto es seguro porque realizamos un seguimiento de dónde estamos cuando buscamos en el árbol, por lo que si una extensión ordenada se actualiza en medio de nuestra llamada a fiemap, seguiremos emitiendo las extensiones correctas porque sabemos en qué desplazamiento estábamos. antes. El único lugar donde mantenemos el bloqueo es buscando en delalloc. Dado que las cosas de delalloc pueden cambiar durante la reescritura, queremos bloquear el rango de extensión para tener una vista consistente de delalloc en el momento en que verificamos si necesitamos configurar el indicador delalloc. Con este parche aplicado ya no nos estancamos con mi caso de prueba."
}
],
"affected": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"affectedData": [
{
"vendor": "Linux",
"product": "Linux",
"defaultStatus": "unaffected",
"programFiles": [
"fs/btrfs/extent_io.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"versions": [
{
"version": "1506fcc8189cdd4b95e06df7845a09f18b4526a6",
"lessThan": "06d3879bb51be205a04b3da752cfd121a3367fb1",
"versionType": "git",
"status": "affected"
},
{
"version": "1506fcc8189cdd4b95e06df7845a09f18b4526a6",
"lessThan": "ded566b4637f1b6b4c9ba74e7d0b8493e93f19cf",
"versionType": "git",
"status": "affected"
},
{
"version": "1506fcc8189cdd4b95e06df7845a09f18b4526a6",
"lessThan": "89bca7fe6382d61e88c67a0b0e7bce315986fb8b",
"versionType": "git",
"status": "affected"
},
{
"version": "1506fcc8189cdd4b95e06df7845a09f18b4526a6",
"lessThan": "b0ad381fa7690244802aed119b478b4bdafc31dd",
"versionType": "git",
"status": "affected"
}
]
},
{
"vendor": "Linux",
"product": "Linux",
"defaultStatus": "affected",
"programFiles": [
"fs/btrfs/extent_io.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"versions": [
{
"version": "2.6.29",
"status": "affected"
},
{
"version": "0",
"lessThan": "2.6.29",
"versionType": "semver",
"status": "unaffected"
},
{
"version": "6.1.191",
"lessThanOrEqual": "6.1.*",
"versionType": "semver",
"status": "unaffected"
},
{
"version": "6.6.24",
"lessThanOrEqual": "6.6.*",
"versionType": "semver",
"status": "unaffected"
},
{
"version": "6.7.12",
"lessThanOrEqual": "6.7.*",
"versionType": "semver",
"status": "unaffected"
},
{
"version": "6.8",
"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:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"baseScore": 5.5,
"baseSeverity": "MEDIUM",
"attackVector": "LOCAL",
"attackComplexity": "LOW",
"privilegesRequired": "LOW",
"userInteraction": "NONE",
"scope": "UNCHANGED",
"confidentialityImpact": "NONE",
"integrityImpact": "NONE",
"availabilityImpact": "HIGH"
},
"exploitabilityScore": 1.8,
"impactScore": 3.6
}
],
"ssvcV203": [
{
"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"ssvcData": {
"timestamp": "2024-09-10T15:42:57.457443Z",
"id": "CVE-2024-35784",
"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"
}
]
}
],
"configurations": [
{
"nodes": [
{
"operator": "OR",
"negate": false,
"cpeMatch": [
{
"vulnerable": true,
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.6.24",
"matchCriteriaId": "B6EDF98F-EEBC-45A5-B968-B78881A5BE83"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionStartIncluding": "6.7",
"versionEndExcluding": "6.7.12",
"matchCriteriaId": "6BE9771A-BAFD-4624-95F9-58D536540C53"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:o:linux:linux_kernel:6.8:rc1:*:*:*:*:*:*",
"matchCriteriaId": "B9F4EA73-0894-400F-A490-3A397AB7A517"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:o:linux:linux_kernel:6.8:rc2:*:*:*:*:*:*",
"matchCriteriaId": "056BD938-0A27-4569-B391-30578B309EE3"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:o:linux:linux_kernel:6.8:rc3:*:*:*:*:*:*",
"matchCriteriaId": "F02056A5-B362-4370-9FF8-6F0BD384D520"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:o:linux:linux_kernel:6.8:rc4:*:*:*:*:*:*",
"matchCriteriaId": "62075ACE-B2A0-4B16-829D-B3DA5AE5CC41"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:o:linux:linux_kernel:6.8:rc5:*:*:*:*:*:*",
"matchCriteriaId": "A780F817-2A77-4130-A9B7-5C25606314E3"
}
]
}
]
}
],
"references": [
{
"url": "https://git.kernel.org/stable/c/06d3879bb51be205a04b3da752cfd121a3367fb1",
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
},
{
"url": "https://git.kernel.org/stable/c/89bca7fe6382d61e88c67a0b0e7bce315986fb8b",
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
]
},
{
"url": "https://git.kernel.org/stable/c/b0ad381fa7690244802aed119b478b4bdafc31dd",
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
]
},
{
"url": "https://git.kernel.org/stable/c/ded566b4637f1b6b4c9ba74e7d0b8493e93f19cf",
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
]
},
{
"url": "https://git.kernel.org/stable/c/89bca7fe6382d61e88c67a0b0e7bce315986fb8b",
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
]
},
{
"url": "https://git.kernel.org/stable/c/b0ad381fa7690244802aed119b478b4bdafc31dd",
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
]
},
{
"url": "https://git.kernel.org/stable/c/ded566b4637f1b6b4c9ba74e7d0b8493e93f19cf",
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
]
}
]
}