DEBIAN-CVE-2023-54253

In the Linux kernel, the following vulnerability has been resolved: btrfs: set page extent mapped after readfolio in relocateonepage 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 btrfs_ioctl+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 btrfsreadfolio further down. The fix here is the same as the above mentioned patch, move the setpageextentmapped call to after the btrfsreadfolio() block to make sure that we have the subpage blocksize stuff setup properly before using the page.