ghsa-hg9c-4q92-whw7
Vulnerability from github
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.
{
"affected": [],
"aliases": [
"CVE-2024-35784"
],
"database_specific": {
"cwe_ids": [],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-05-17T13:15:58Z",
"severity": null
},
"details": "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\u0027t have lockdep\nannotations with the extent locking so we\u0027ve never noticed it.\n\nSince we\u0027re 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\u0027ed. This would deadlock with the following stack trace\n\n[\u003c0\u003e] lock_extent+0x28d/0x2f0\n[\u003c0\u003e] btrfs_page_mkwrite+0x273/0x8a0\n[\u003c0\u003e] do_page_mkwrite+0x50/0xb0\n[\u003c0\u003e] do_fault+0xc1/0x7b0\n[\u003c0\u003e] __handle_mm_fault+0x2fa/0x460\n[\u003c0\u003e] handle_mm_fault+0xa4/0x330\n[\u003c0\u003e] do_user_addr_fault+0x1f4/0x800\n[\u003c0\u003e] exc_page_fault+0x7c/0x1e0\n[\u003c0\u003e] asm_exc_page_fault+0x26/0x30\n[\u003c0\u003e] rep_movs_alternative+0x33/0x70\n[\u003c0\u003e] _copy_to_user+0x49/0x70\n[\u003c0\u003e] fiemap_fill_next_extent+0xc8/0x120\n[\u003c0\u003e] emit_fiemap_extent+0x4d/0xa0\n[\u003c0\u003e] extent_fiemap+0x7f8/0xad0\n[\u003c0\u003e] btrfs_fiemap+0x49/0x80\n[\u003c0\u003e] __x64_sys_ioctl+0x3e1/0xb50\n[\u003c0\u003e] do_syscall_64+0x94/0x1a0\n[\u003c0\u003e] 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\u0027t 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\u0027re searching the tree, so if an ordered extent updates in\nthe middle of our fiemap call we\u0027ll 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\u0027re\nchecking to see if we need to set the delalloc flag.\n\nWith this patch applied we no longer deadlock with my testcase.",
"id": "GHSA-hg9c-4q92-whw7",
"modified": "2024-05-17T15:31:08Z",
"published": "2024-05-17T15:31:08Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35784"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/89bca7fe6382d61e88c67a0b0e7bce315986fb8b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b0ad381fa7690244802aed119b478b4bdafc31dd"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ded566b4637f1b6b4c9ba74e7d0b8493e93f19cf"
}
],
"schema_version": "1.4.0",
"severity": []
}
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.