CVE-2026-23199

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]
Configurations

Configuration 1 (hide)

OR cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
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:*:*:*:*:*:*

History

19 Mar 2026, 16:41

Type Values Removed Values Added
References () https://git.kernel.org/stable/c/b5cbacd7f86f4f62b8813688c8e73be94e8e1951 - () https://git.kernel.org/stable/c/b5cbacd7f86f4f62b8813688c8e73be94e8e1951 - Patch
References () https://git.kernel.org/stable/c/b9b97e6aeb534315f9646b2090d1a5024c6a4e82 - () https://git.kernel.org/stable/c/b9b97e6aeb534315f9646b2090d1a5024c6a4e82 - Patch
References () https://git.kernel.org/stable/c/cbc03ce3e6ce7e21214c3f02218213574c1a2d08 - () https://git.kernel.org/stable/c/cbc03ce3e6ce7e21214c3f02218213574c1a2d08 - Patch
CPE cpe:2.3:o:linux:linux_kernel:6.19:rc1:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:6.19:rc8:*:*:*:*:*:*
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:rc2:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:6.19:rc6:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:6.19:rc5:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:6.19:rc7:*:*:*:*:*:*
CVSS v2 : unknown
v3 : unknown
v2 : unknown
v3 : 5.5
First Time Linux
Linux linux Kernel
CWE CWE-667

18 Feb 2026, 17:52

Type Values Removed Values Added
Summary
  • (es) En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta: procfs: evitar la obtención del ID de compilación mientras se mantiene el bloqueo VMA Corregir PROCMAP_QUERY para obtener el ID de compilación opcional solo después de liberar mmap_lock o el bloqueo por VMA, el que se haya utilizado para bloquear el VMA en cuestión, para evitar el interbloqueo informado por 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 otra información que podría ayudarnos a depurar esto: Posible escenario de bloqueo inseguro: 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); * INTERBLOQUEO * Esto parece exacerbarse (ya que no habíamos visto estos informes de syzbot antes de eso) por el reciente: 777a8560fd29 ("lib/buildid: use __kernel_read() for sleepable context") Para que esto sea seguro, necesitamos tomar el recuento de referencias del archivo mientras el VMA aún está bloqueado, pero aparte de eso, todo es bastante sencillo. La API interna build_id_parse() asume que se pasa el VMA, pero solo necesita la referencia de archivo subyacente, así que solo hay que añadir otra variante build_id_parse_file() que espera que el archivo se pase directamente. [akpm@linux-foundation.org: corregir kerneldoc]

14 Feb 2026, 17:15

Type Values Removed Values Added
New CVE

Information

Published : 2026-02-14 17:15

Updated : 2026-03-19 16:41


NVD link : CVE-2026-23199

Mitre link : CVE-2026-23199

CVE.ORG link : CVE-2026-23199


JSON object : View

Products Affected

linux

  • linux_kernel
CWE
CWE-667

Improper Locking