CVE-2026-23199: procfs: avoid fetching build ID while holding VMA lock
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: fix up kerneldoc]
Other sources
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]
— NVD
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
Linux kernelto a version that resolves this vulnerability.Patch 777a8560fd29 - Configuration
Update PROCMAP_QUERY handling so optional build ID is fetched only after dropping mmap_lock to avoid the unsafe locking/deadlock scenario.
procfs/procmap_query (PROCMAP_QUERY) build_id fetch timing = fetch optional build ID only after dropping mmap_lock - Configuration
Modify procfs_procmap_ioctl so it does not fetch build ID while holding the VMA-related lock (mmap_lock/VMA lock), instead using a safer locking/ordering approach (e.g., grab needed file refcount while VMA is still locked, then do build_id parsing after releasing the VMA lock).
procfs_procmap_ioctl build_id retrieval while holding VMA lock = avoid fetching build ID while holding VMA lock
Event History
Frequently Asked Questions
What is the severity of CVE-2026-23199?
CVE-2026-23199 is categorized as a moderate severity vulnerability in the Linux kernel.
How do I fix CVE-2026-23199?
To fix CVE-2026-23199, ensure you apply the latest patch that resolves the issue related to the VMA lock handling.
What systems are affected by CVE-2026-23199?
CVE-2026-23199 affects various versions of the Linux kernel where the procfs subsystem is used.
What type of vulnerability is CVE-2026-23199?
CVE-2026-23199 is a synchronization issue in the Linux kernel concerning the fetching of build IDs.
Can CVE-2026-23199 lead to privilege escalation?
While CVE-2026-23199 is primarily about synchronization, exploitation could lead to unintended behavior but is not directly a privilege escalation vulnerability.