CVE-2026-23199 in Linux
Summary
by MITRE • 02/14/2026
In the Linux kernel, the following vulnerability has been resolved:
procfs: avoid fetching build ID while holding VMA lock
Fix PROCMAP_QUERY to fetch optional build ID only after dropping mmap_lock or per-VMA lock, whichever was used to lock VMA under question, to avoid deadlock reported by syzbot:
-> #1 (&mm->mmap_lock){++++}-{4:4}:
__might_fault+0xed/0x170 _copy_to_iter+0x118/0x1720 copy_page_to_iter+0x12d/0x1e0 filemap_read+0x720/0x10a0 blkdev_read_iter+0x2b5/0x4e0 vfs_read+0x7f4/0xae0 ksys_read+0x12a/0x250 do_syscall_64+0xcb/0xf80 entry_SYSCALL_64_after_hwframe+0x77/0x7f
-> #0 (&sb->s_type->i_mutex_key#8){++++}-{4:4}:
__lock_acquire+0x1509/0x26d0 lock_acquire+0x185/0x340 down_read+0x98/0x490 blkdev_read_iter+0x2a7/0x4e0 __kernel_read+0x39a/0xa90 freader_fetch+0x1d5/0xa80 __build_id_parse.isra.0+0xea/0x6a0 do_procmap_query+0xd75/0x1050 procfs_procmap_ioctl+0x7a/0xb0 __x64_sys_ioctl+0x18e/0x210 do_syscall_64+0xcb/0xf80 entry_SYSCALL_64_after_hwframe+0x77/0x7f
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0 CPU1 ---- ---- rlock(&mm->mmap_lock); lock(&sb->s_type->i_mutex_key#8); lock(&mm->mmap_lock); rlock(&sb->s_type->i_mutex_key#8);
*** DEADLOCK ***
This seems to be exacerbated (as we haven't seen these syzbot reports before that) by the recent:
777a8560fd29 ("lib/buildid: use __kernel_read() 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 build_id_parse() API assumes VMA is passed, but it only needs the underlying file reference, so just add another variant build_id_parse_file() that expects file passed directly.
[[email protected]: fix up kerneldoc]
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 05/06/2026
The vulnerability described in CVE-2026-23199 resides within the Linux kernel's procfs implementation, specifically concerning the handling of build ID retrieval during memory mapping operations. This flaw manifests as a potential deadlock condition that can severely impact system stability and availability. The issue occurs when the kernel attempts to fetch build ID information while holding virtual memory area locks, creating a circular dependency that prevents proper resource acquisition and leads to system hangs.
The technical root cause involves the PROCMAP_QUERY ioctl operation which, when processing memory mappings, attempts to access build ID information while maintaining locks on virtual memory areas. The deadlock scenario emerges from a classic lock ordering violation where one CPU thread holds the mmap_lock while attempting to acquire an inode mutex, while another thread holds the inode mutex and attempts to acquire the mmap_lock. This creates a circular dependency that results in system-wide deadlock conditions, as demonstrated by the syzbot crash report showing the exact lock acquisition sequence leading to the problematic state.
This vulnerability directly relates to CWE-367, which addresses Time-of-Check to Time-of-Use (TOCTOU) flaws and improper lock ordering issues. The problem is exacerbated by recent kernel changes that modified how build ID parsing operates within sleepable contexts, specifically the commit 777a8560fd29 that introduced __kernel_read() usage for build ID operations. The existing code structure forces the build_id_parse function to operate on virtual memory areas while locks are held, creating an unnecessary dependency that opens the door to deadlock scenarios.
The operational impact of this vulnerability extends beyond simple system hangs, as it can affect any process that attempts to query memory mappings through procfs interfaces. Attackers could potentially trigger this condition through carefully crafted memory mapping operations, leading to denial of service conditions where the system becomes unresponsive to legitimate operations. The vulnerability affects systems running kernel versions that include the problematic build ID handling code, particularly those with memory mapping and process introspection capabilities.
Mitigation strategies should focus on restructuring the build ID retrieval mechanism to avoid holding virtual memory area locks during file access operations. The recommended fix involves creating a new build_id_parse_file() API variant that accepts file references directly rather than virtual memory area structures, allowing the kernel to acquire necessary file references while locks are still held and then release the locks before performing the actual build ID parsing operations. This approach follows the principle of minimizing lock duration and avoiding cross-lock dependencies that can lead to deadlocks. System administrators should apply kernel patches that implement this fix and monitor for any related performance impacts from the changed locking behavior, while also ensuring that the modified code maintains proper reference counting for file objects to prevent use-after-free conditions.