CVE-2023-53247

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: set_page_extent_mapped after read_folio in btrfs_cont_expand<br /> <br /> While trying to get the subpage blocksize tests running, I hit the<br /> following panic on generic/476<br /> <br /> assertion failed: PagePrivate(page) &amp;&amp; page-&gt;private, in fs/btrfs/subpage.c:229<br /> kernel BUG at fs/btrfs/subpage.c:229!<br /> Internal error: Oops - BUG: 00000000f2000800 [#1] SMP<br /> CPU: 1 PID: 1453 Comm: fsstress Not tainted 6.4.0-rc7+ #12<br /> Hardware name: QEMU KVM Virtual Machine, BIOS edk2-20230301gitf80f052277c8-26.fc38 03/01/2023<br /> pstate: 61400005 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)<br /> pc : btrfs_subpage_assert+0xbc/0xf0<br /> lr : btrfs_subpage_assert+0xbc/0xf0<br /> Call trace:<br /> btrfs_subpage_assert+0xbc/0xf0<br /> btrfs_subpage_clear_checked+0x38/0xc0<br /> btrfs_page_clear_checked+0x48/0x98<br /> btrfs_truncate_block+0x5d0/0x6a8<br /> btrfs_cont_expand+0x5c/0x528<br /> btrfs_write_check.isra.0+0xf8/0x150<br /> btrfs_buffered_write+0xb4/0x760<br /> btrfs_do_write_iter+0x2f8/0x4b0<br /> btrfs_file_write_iter+0x1c/0x30<br /> do_iter_readv_writev+0xc8/0x158<br /> do_iter_write+0x9c/0x210<br /> vfs_iter_write+0x24/0x40<br /> iter_file_splice_write+0x224/0x390<br /> direct_splice_actor+0x38/0x68<br /> splice_direct_to_actor+0x12c/0x260<br /> do_splice_direct+0x90/0xe8<br /> generic_copy_file_range+0x50/0x90<br /> vfs_copy_file_range+0x29c/0x470<br /> __arm64_sys_copy_file_range+0xcc/0x498<br /> invoke_syscall.constprop.0+0x80/0xd8<br /> do_el0_svc+0x6c/0x168<br /> el0_svc+0x50/0x1b0<br /> el0t_64_sync_handler+0x114/0x120<br /> el0t_64_sync+0x194/0x198<br /> <br /> This happens because during btrfs_cont_expand we&amp;#39;ll get a page, set it<br /> as mapped, and if it&amp;#39;s not Uptodate we&amp;#39;ll read it. However between the<br /> read and re-locking the page we could have called release_folio() on the<br /> page, but left the page in the file mapping. release_folio() can clear<br /> the page private, and thus further down we blow up when we go to modify<br /> the subpage bits.<br /> <br /> Fix this by putting the set_page_extent_mapped() after the read. This<br /> is safe because read_folio() will call set_page_extent_mapped() before<br /> it does the read, and then if we clear page private but leave it on the<br /> mapping we&amp;#39;re completely safe re-setting set_page_extent_mapped(). With<br /> this patch I can now run generic/476 without panicing.