CVE-2023-54253

In the Linux kernel, the following vulnerability has been resolved:

btrfs: set page extent mapped after readfolio in relocateone_page

One of the CI runs triggered the following panic

assertion failed: PagePrivate(page) && page->private, in fs/btrfs/subpage.c:229 ------------[ cut here ]------------ kernel BUG at fs/btrfs/subpage.c:229! Internal error: Oops - BUG: 00000000f2000800 [#1] SMP CPU: 0 PID: 923660 Comm: btrfs Not tainted 6.5.0-rc3+ #1 pstate: 61400005 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) pc : btrfssubpageassert+0xbc/0xf0 lr : btrfssubpageassert+0xbc/0xf0 sp : ffff800093213720 x29: ffff800093213720 x28: ffff8000932138b4 x27: 000000000c280000 x26: 00000001b5d00000 x25: 000000000c281000 x24: 000000000c281fff x23: 0000000000001000 x22: 0000000000000000 x21: ffffff42b95bf880 x20: ffff42b9528e0000 x19: 0000000000001000 x18: ffffffffffffffff x17: 667274622f736620 x16: 6e69202c65746176 x15: 0000000000000028 x14: 0000000000000003 x13: 00000000002672d7 x12: 0000000000000000 x11: ffffcd3f0ccd9204 x10: ffffcd3f0554ae50 x9 : ffffcd3f0379528c x8 : ffff800093213428 x7 : 0000000000000000 x6 : ffffcd3f091771e8 x5 : ffff42b97f333948 x4 : 0000000000000000 x3 : 0000000000000000 x2 : 0000000000000000 x1 : ffff42b9556cde80 x0 : 000000000000004f Call trace: btrfssubpageassert+0xbc/0xf0 btrfssubpagesetdirty+0x38/0xa0 btrfspagesetdirty+0x58/0x88 relocateonepage+0x204/0x5f0 relocatefileextentcluster+0x11c/0x180 relocatedataextent+0xd0/0xf8 relocateblockgroup+0x3d0/0x4e8 btrfsrelocateblockgroup+0x2d8/0x490 btrfsrelocatechunk+0x54/0x1a8 btrfsbalance+0x7f4/0x1150 btrfsioctl+0x10f0/0x20b8 _arm64sysioctl+0x120/0x11d8 invokesyscall.constprop.0+0x80/0xd8 doel0svc+0x6c/0x158 el0svc+0x50/0x1b0 el0t64synchandler+0x120/0x130 el0t64sync+0x194/0x198 Code: 91098021 b0007fa0 91346000 97e9c6d2 (d4210000)

This is the same problem outlined in 17b17fcd6d44 ("btrfs: setpageextentmapped after readfolio in btrfscontexpand") , and the fix is the same. I originally looked for the same pattern elsewhere in our code, but mistakenly skipped over this code because I saw the page cache readahead before we setpageextentmapped, not realizing that this was only in the !page case, that we can still end up with a !uptodate page and then do the btrfsread_folio further down.

The fix here is the same as the above mentioned patch, move the setpageextentmapped call to after the btrfsread_folio() block to make sure that we have the subpage blocksize stuff setup properly before using the page.