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 ? lockrelease+0x708/0x780 kasanreport+0xda/0x1b0 ? lockrelease+0x708/0x780 ? _wakeup+0x44/0x60 lockrelease+0x708/0x780 ? _pfxlockrelease+0x10/0x10 ? _pfxdorawspinlock+0x10/0x10 ? lockisheldtype+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 processonework+0x85c/0x1460 ? _pfxprocessonework+0x10/0x10 ? assignwork+0x16c/0x240 workerthread+0x5e6/0xfc0 ? _pfxworkerthread+0x10/0x10 kthread+0x2c3/0x3a0 ? _pfxkthread+0x10/0x10 retfromfork+0x31/0x70 ? _pfxkthread+0x10/0x10 retfromfork_asm+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 entrySYSCALL64after_hwframe+0x76/0x7e
Freed by task 3661: kasansavestack+0x30/0x50 kasansavetrack+0x14/0x30 kasansavefreeinfo+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] btrfsioctl+0x184a/0x60a0 [btrfs] _x64sysioctl+0x12e/0x1a0 dosyscall64+0x95/0x180 entrySYSCALL64after_hwframe+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---