Description
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.

[akpm@linux-foundation.org: fix up kerneldoc]
Published: 2026-02-14
Score: 5.5 Medium
EPSS: < 1% Very Low
KEV: No
Impact: Denial of Service (kernel deadlock)
Action: Apply Patch
AI Analysis

Impact

A flaw in the Linux kernel’s procfs implementation allows the build ID of a mapped file to be fetched while holding critical locks on the virtual memory area (VMA). This can cause a deadlock between the mmap lock and the inode mutex during read operations. Based on the description, it is inferred that an attacker could trigger the deadlock by invoking the procmap ioctl interface, which could freeze the kernel or hang involved processes, resulting in a denial of service.

Affected Systems

All Linux kernel releases that include the vulnerable procfs code, notably kernel versions 6.19 and its release candidates up to 6.19rc8, are affected. The issue is present in the kernel tree prior to the commit that moves build ID fetching out of the VMA lock region.

Risk and Exploitability

The CVSS score of 5.5 indicates moderate severity, and the EPSS probability is less than 1%, pointing to a low likelihood of widespread exploitation at present. The vulnerability is not listed in the CISA KEV catalog. Based on the description, it is inferred that the attack vector is local, requiring a user to issue the procmap ioctl request that triggers the deadlock. Based on the description, it is inferred that there is no remote code execution risk. A successful exploit can permanently halt the kernel or hang critical processes until a reboot occurs.

Generated by OpenCVE AI on April 18, 2026 at 18:01 UTC.

Remediation

No vendor fix or workaround currently provided.

OpenCVE Recommended Actions

  • Upgrade the Linux kernel to a version that incorporates the fix for CVE‑2026‑23199, which removes the deadlock by fetching the build ID only after releasing the mmap or inode lock.
  • Reboot the system after applying the updated kernel to ensure all modules are reloaded with the safe code path.
  • If the procmap ioctl must remain available, restrict its use to trusted users or disable it entirely until a fully patched kernel is deployed.

Generated by OpenCVE AI on April 18, 2026 at 18:01 UTC.

Tracking

Sign in to view the affected projects.

Advisories
Source ID Title
Debian DSA Debian DSA DSA-6141-1 linux security update
History

Thu, 19 Mar 2026 16:45:00 +0000

Type Values Removed Values Added
Weaknesses CWE-667
CPEs cpe:2.3:o:linux:linux_kernel:6.19:rc1:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:6.19:rc2:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:6.19:rc3:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:6.19:rc4:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:6.19:rc5:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:6.19:rc6:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:6.19:rc7:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:6.19:rc8:*:*:*:*:*:*
Metrics cvssV3_1

{'score': 7.0, 'vector': 'CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H'}

cvssV3_1

{'score': 5.5, 'vector': 'CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H'}


Tue, 17 Feb 2026 00:15:00 +0000

Type Values Removed Values Added
References
Metrics threat_severity

None

cvssV3_1

{'score': 7.0, 'vector': 'CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H'}

threat_severity

Moderate


Sat, 14 Feb 2026 16:45:00 +0000

Type Values Removed Values Added
Description 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. [akpm@linux-foundation.org: fix up kerneldoc]
Title procfs: avoid fetching build ID while holding VMA lock
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References

Subscriptions

Linux Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-02-14T16:27:24.326Z

Reserved: 2026-01-13T15:37:45.985Z

Link: CVE-2026-23199

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Analyzed

Published: 2026-02-14T17:15:57.743

Modified: 2026-03-19T16:41:57.087

Link: CVE-2026-23199

cve-icon Redhat

Severity : Moderate

Publid Date: 2026-02-14T00:00:00Z

Links: CVE-2026-23199 - Bugzilla

cve-icon OpenCVE Enrichment

Updated: 2026-04-18T18:15:06Z

Weaknesses