Homepage

Improper Locking Affecting kernel-uek-doc package, versions <0:6.12.0-200.74.27.el9uek

Severity

 Recommended
high

Based on Oracle Linux security rating.

Threat Intelligence

EPSS
0.01% (3rd percentile)

Do your applications use this vulnerable package?

In a few clicks we can analyze your entire application and see what components are vulnerable in your application, and suggest you quick fixes.

Test your applications
  • Snyk IDSNYK-ORACLE9-KERNELUEKDOC-15865944
  • published1 Apr 2026
  • disclosed14 Feb 2026
Report a new vulnerability Found a mistake?

Introduced: 14 Feb 2026

CVE-2026-23199  (opens in a new tab)
CWE-667  (opens in a new tab)

How to fix?

Upgrade Oracle:9 kernel-uek-doc to version 0:6.12.0-200.74.27.el9uek or higher.
This issue was patched in ELSA-2026-50160.

NVD Description

Note: Versions mentioned in the description apply only to the upstream kernel-uek-doc package and not the kernel-uek-doc package as distributed by Oracle. See How to fix? for Oracle:9 relevant fixed versions and status.

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 (&#34;lib/buildid: use __kernel_read() for sleepable context&#34;)

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]

CVSS Base Scores

version 3.1