DEBIAN-CVE-2026-23199

In the Linux kernel, the following vulnerability has been resolved: procfs: avoid fetching build ID while holding VMA lock Fix PROCMAPQUERY to fetch optional build ID only after dropping mmaplock or per-VMA lock, whichever was used to lock VMA under question, to avoid deadlock reported by syzbot: -> #1 (&mm->mmaplock){++++}-{4:4}: _mightfault+0xed/0x170 _copytoiter+0x118/0x1720 copypagetoiter+0x12d/0x1e0 filemapread+0x720/0x10a0 blkdevreaditer+0x2b5/0x4e0 vfsread+0x7f4/0xae0 ksysread+0x12a/0x250 dosyscall64+0xcb/0xf80 entrySYSCALL64afterhwframe+0x77/0x7f -> #0 (&sb->stype->imutexkey#8){++++}-{4:4}: _lockacquire+0x1509/0x26d0 lockacquire+0x185/0x340 downread+0x98/0x490 blkdevreaditer+0x2a7/0x4e0 _kernelread+0x39a/0xa90 freaderfetch+0x1d5/0xa80 _buildidparse.isra.0+0xea/0x6a0 doprocmapquery+0xd75/0x1050 procfsprocmapioctl+0x7a/0xb0 _x64sysioctl+0x18e/0x210 dosyscall64+0xcb/0xf80 entrySYSCALL64afterhwframe+0x77/0x7f other info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- rlock(&mm->mmaplock); lock(&sb->stype->imutexkey#8); lock(&mm->mmaplock); rlock(&sb->stype->imutexkey#8); * DEADLOCK * This seems to be exacerbated (as we haven't seen these syzbot reports before that) by the recent: 777a8560fd29 ("lib/buildid: use _kernelread() for sleepable context") To make this safe, we need to grab file refcount while VMA is still locked, but other than that everything is pretty straightforward. Internal buildidparse() API assumes VMA is passed, but it only needs the underlying file reference, so just add another variant buildidparsefile() that expects file passed directly. [akpm@linux-foundation.org: fix up kerneldoc]