CVE-2024-56582

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

btrfs: fix use-after-free in btrfsencodedread_endio()

Shinichiro reported the following use-after free that sometimes is happening in our CI system when running fstests' btrfs/284 on a TCMU runner device:

BUG: KASAN: slab-use-after-free in lock_release+0x708/0x780 Read of size 8 at addr ffff888106a83f18 by task kworker/u80:6/219

CPU: 8 UID: 0 PID: 219 Comm: kworker/u80:6 Not tainted 6.12.0-rc6-kts+ #15 Hardware name: Supermicro Super Server/X11SPi-TF, BIOS 3.3 02/21/2020 Workqueue: btrfs-endio btrfsendbiowork [btrfs] Call Trace: <TASK> dumpstacklvl+0x6e/0xa0 ? lockrelease+0x708/0x780 printreport+0x174/0x505 ? lockrelease+0x708/0x780 ? __virtaddrvalid+0x224/0x410 ? lock_release+0x708/0x780 kasanreport+0xda/0x1b0 ? lockrelease+0x708/0x780 ? __wakeup+0x44/0x60 lockrelease+0x708/0x780 ? __pfxlockrelease+0x10/0x10 ? __pfxdorawspinlock+0x10/0x10 ? lock_isheldtype+0x9a/0x110 rawspinunlockirqrestore+0x1f/0x60 __wakeup+0x44/0x60 btrfsencodedreadendio+0x14b/0x190 [btrfs] btrfscheckreadbio+0x8d9/0x1360 [btrfs] ? lockrelease+0x1b0/0x780 ? tracelockacquire+0x12f/0x1a0 ? __pfxbtrfscheckreadbio+0x10/0x10 [btrfs] ? processonework+0x7e3/0x1460 ? lockacquire+0x31/0xc0 ? processonework+0x7e3/0x1460 processone_work+0x85c/0x1460 ? __pfxprocessonework+0x10/0x10 ? assignwork+0x16c/0x240 worker_thread+0x5e6/0xfc0 ? __pfxworkerthread+0x10/0x10 kthread+0x2c3/0x3a0 ? __pfxkthread+0x10/0x10 retfrom_fork+0x31/0x70 ? __pfxkthread+0x10/0x10 retfromforkasm+0x1a/0x30 </TASK>

Allocated by task 3661: kasansavestack+0x30/0x50 kasansavetrack+0x14/0x30 __kasankmalloc+0xaa/0xb0 btrfsencodedreadregularfillpages+0x16c/0x6d0 [btrfs] sendextentdata+0xf0f/0x24a0 [btrfs] processextent+0x48a/0x1830 [btrfs] changedcb+0x178b/0x2ea0 [btrfs] btrfsioctlsend+0x3bf9/0x5c20 [btrfs] btrfsioctlsend+0x117/0x330 [btrfs] btrfsioctl+0x184a/0x60a0 [btrfs] __x64sysioctl+0x12e/0x1a0 dosyscall64+0x95/0x180 entrySYSCALL64afterhwframe+0x76/0x7e

Freed by task 3661: kasansavestack+0x30/0x50 kasansavetrack+0x14/0x30 kasansavefree_info+0x3b/0x70 __kasanslabfree+0x4f/0x70 kfree+0x143/0x490 btrfsencodedreadregularfillpages+0x531/0x6d0 [btrfs] sendextentdata+0xf0f/0x24a0 [btrfs] processextent+0x48a/0x1830 [btrfs] changedcb+0x178b/0x2ea0 [btrfs] btrfsioctlsend+0x3bf9/0x5c20 [btrfs] btrfsioctlsend+0x117/0x330 [btrfs] btrfs_ioctl+0x184a/0x60a0 [btrfs] __x64sysioctl+0x12e/0x1a0 dosyscall64+0x95/0x180 entrySYSCALL64afterhwframe+0x76/0x7e

The buggy address belongs to the object at ffff888106a83f00 which belongs to the cache kmalloc-rnd-07-96 of size 96 The buggy address is located 24 bytes inside of freed 96-byte region [ffff888106a83f00, ffff888106a83f60)

The buggy address belongs to the physical page: page: refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff888106a83800 pfn:0x106a83 flags: 0x17ffffc0000000(node=0|zone=2|lastcpupid=0x1fffff) page_type: f5(slab) raw: 0017ffffc0000000 ffff888100053680 ffffea0004917200 0000000000000004 raw: ffff888106a83800 0000000080200019 00000001f5000000 0000000000000000 page dumped because: kasan: bad access detected

Memory state around the buggy address: ffff888106a83e00: fa fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc ffff888106a83e80: fa fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc

ffff888106a83f00: fa fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc ^ ffff888106a83f80: fa fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc ffff888106a84000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ==================================================================

Further analyzing the trace and ---truncated---