fkie_cve-2023-53247
Vulnerability from fkie_nvd
Published
2025-09-15 15:15
Modified
2025-09-15 15:22
Severity ?
Summary
In the Linux kernel, the following vulnerability has been resolved:
btrfs: set_page_extent_mapped after read_folio in btrfs_cont_expand
While trying to get the subpage blocksize tests running, I hit the
following panic on generic/476
assertion failed: PagePrivate(page) && page->private, in fs/btrfs/subpage.c:229
kernel BUG at fs/btrfs/subpage.c:229!
Internal error: Oops - BUG: 00000000f2000800 [#1] SMP
CPU: 1 PID: 1453 Comm: fsstress Not tainted 6.4.0-rc7+ #12
Hardware name: QEMU KVM Virtual Machine, BIOS edk2-20230301gitf80f052277c8-26.fc38 03/01/2023
pstate: 61400005 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)
pc : btrfs_subpage_assert+0xbc/0xf0
lr : btrfs_subpage_assert+0xbc/0xf0
Call trace:
btrfs_subpage_assert+0xbc/0xf0
btrfs_subpage_clear_checked+0x38/0xc0
btrfs_page_clear_checked+0x48/0x98
btrfs_truncate_block+0x5d0/0x6a8
btrfs_cont_expand+0x5c/0x528
btrfs_write_check.isra.0+0xf8/0x150
btrfs_buffered_write+0xb4/0x760
btrfs_do_write_iter+0x2f8/0x4b0
btrfs_file_write_iter+0x1c/0x30
do_iter_readv_writev+0xc8/0x158
do_iter_write+0x9c/0x210
vfs_iter_write+0x24/0x40
iter_file_splice_write+0x224/0x390
direct_splice_actor+0x38/0x68
splice_direct_to_actor+0x12c/0x260
do_splice_direct+0x90/0xe8
generic_copy_file_range+0x50/0x90
vfs_copy_file_range+0x29c/0x470
__arm64_sys_copy_file_range+0xcc/0x498
invoke_syscall.constprop.0+0x80/0xd8
do_el0_svc+0x6c/0x168
el0_svc+0x50/0x1b0
el0t_64_sync_handler+0x114/0x120
el0t_64_sync+0x194/0x198
This happens because during btrfs_cont_expand we'll get a page, set it
as mapped, and if it's not Uptodate we'll read it. However between the
read and re-locking the page we could have called release_folio() on the
page, but left the page in the file mapping. release_folio() can clear
the page private, and thus further down we blow up when we go to modify
the subpage bits.
Fix this by putting the set_page_extent_mapped() after the read. This
is safe because read_folio() will call set_page_extent_mapped() before
it does the read, and then if we clear page private but leave it on the
mapping we're completely safe re-setting set_page_extent_mapped(). With
this patch I can now run generic/476 without panicing.
References
Impacted products
Vendor | Product | Version |
---|
{ "cveTags": [], "descriptions": [ { "lang": "en", "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: set_page_extent_mapped after read_folio in btrfs_cont_expand\n\nWhile trying to get the subpage blocksize tests running, I hit the\nfollowing panic on generic/476\n\n assertion failed: PagePrivate(page) \u0026\u0026 page-\u003eprivate, in fs/btrfs/subpage.c:229\n kernel BUG at fs/btrfs/subpage.c:229!\n Internal error: Oops - BUG: 00000000f2000800 [#1] SMP\n CPU: 1 PID: 1453 Comm: fsstress Not tainted 6.4.0-rc7+ #12\n Hardware name: QEMU KVM Virtual Machine, BIOS edk2-20230301gitf80f052277c8-26.fc38 03/01/2023\n pstate: 61400005 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)\n pc : btrfs_subpage_assert+0xbc/0xf0\n lr : btrfs_subpage_assert+0xbc/0xf0\n Call trace:\n btrfs_subpage_assert+0xbc/0xf0\n btrfs_subpage_clear_checked+0x38/0xc0\n btrfs_page_clear_checked+0x48/0x98\n btrfs_truncate_block+0x5d0/0x6a8\n btrfs_cont_expand+0x5c/0x528\n btrfs_write_check.isra.0+0xf8/0x150\n btrfs_buffered_write+0xb4/0x760\n btrfs_do_write_iter+0x2f8/0x4b0\n btrfs_file_write_iter+0x1c/0x30\n do_iter_readv_writev+0xc8/0x158\n do_iter_write+0x9c/0x210\n vfs_iter_write+0x24/0x40\n iter_file_splice_write+0x224/0x390\n direct_splice_actor+0x38/0x68\n splice_direct_to_actor+0x12c/0x260\n do_splice_direct+0x90/0xe8\n generic_copy_file_range+0x50/0x90\n vfs_copy_file_range+0x29c/0x470\n __arm64_sys_copy_file_range+0xcc/0x498\n invoke_syscall.constprop.0+0x80/0xd8\n do_el0_svc+0x6c/0x168\n el0_svc+0x50/0x1b0\n el0t_64_sync_handler+0x114/0x120\n el0t_64_sync+0x194/0x198\n\nThis happens because during btrfs_cont_expand we\u0027ll get a page, set it\nas mapped, and if it\u0027s not Uptodate we\u0027ll read it. However between the\nread and re-locking the page we could have called release_folio() on the\npage, but left the page in the file mapping. release_folio() can clear\nthe page private, and thus further down we blow up when we go to modify\nthe subpage bits.\n\nFix this by putting the set_page_extent_mapped() after the read. This\nis safe because read_folio() will call set_page_extent_mapped() before\nit does the read, and then if we clear page private but leave it on the\nmapping we\u0027re completely safe re-setting set_page_extent_mapped(). With\nthis patch I can now run generic/476 without panicing." } ], "id": "CVE-2023-53247", "lastModified": "2025-09-15T15:22:27.090", "metrics": {}, "published": "2025-09-15T15:15:51.930", "references": [ { "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "url": "https://git.kernel.org/stable/c/0a5e0bc8e8618e32a6ca64450867628eb0a627bf" }, { "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "url": "https://git.kernel.org/stable/c/17b17fcd6d446b95904a6929c40012ee7f0afc0c" }, { "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "url": "https://git.kernel.org/stable/c/a5880e69cf7fe4a0bb1eabae02205352d1b59b7b" } ], "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "vulnStatus": "Awaiting Analysis" }
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…