NULL Pointer Dereference Affecting kernel-uek-modules-usb package, versions <0:6.12.0-200.74.27.el9uek
Threat Intelligence
The probability is the direct output of the EPSS model, and conveys an overall sense of the threat of exploitation in the wild. The percentile measures the EPSS probability relative to all known EPSS scores. Note: This data is updated daily, relying on the latest available EPSS model version. Check out the EPSS documentation for more details.
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 applicationsSnyk Learn
Learn about NULL Pointer Dereference vulnerabilities in an interactive lesson.
Start learning- Snyk IDSNYK-ORACLE9-KERNELUEKMODULESUSB-15865327
- published1 Apr 2026
- disclosed14 Feb 2026
Introduced: 14 Feb 2026
CVE-2026-23163 (opens in a new tab)How to fix?
Upgrade Oracle:9 kernel-uek-modules-usb 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-modules-usb package and not the kernel-uek-modules-usb 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:
drm/amdgpu: fix NULL pointer dereference in amdgpu_gmc_filter_faults_remove
On APUs such as Raven and Renoir (GC 9.1.0, 9.2.2, 9.3.0), the ih1 and ih2 interrupt ring buffers are not initialized. This is by design, as these secondary IH rings are only available on discrete GPUs. See vega10_ih_sw_init() which explicitly skips ih1/ih2 initialization when AMD_IS_APU is set.
However, amdgpu_gmc_filter_faults_remove() unconditionally uses ih1 to get the timestamp of the last interrupt entry. When retry faults are enabled on APUs (noretry=0), this function is called from the SVM page fault recovery path, resulting in a NULL pointer dereference when amdgpu_ih_decode_iv_ts_helper() attempts to access ih->ring[].
The crash manifests as:
BUG: kernel NULL pointer dereference, address: 0000000000000004 RIP: 0010:amdgpu_ih_decode_iv_ts_helper+0x22/0x40 [amdgpu] Call Trace: amdgpu_gmc_filter_faults_remove+0x60/0x130 [amdgpu] svm_range_restore_pages+0xae5/0x11c0 [amdgpu] amdgpu_vm_handle_fault+0xc8/0x340 [amdgpu] gmc_v9_0_process_interrupt+0x191/0x220 [amdgpu] amdgpu_irq_dispatch+0xed/0x2c0 [amdgpu] amdgpu_ih_process+0x84/0x100 [amdgpu]
This issue was exposed by commit 1446226d32a4 ("drm/amdgpu: Remove GC HW IP 9.3.0 from noretry=1") which changed the default for Renoir APU from noretry=1 to noretry=0, enabling retry fault handling and thus exercising the buggy code path.
Fix this by adding a check for ih1.ring_size before attempting to use it. Also restore the soft_ih support from commit dd299441654f ("drm/amdgpu: Rework retry fault removal"). This is needed if the hardware doesn't support secondary HW IH rings.
v2: additional updates (Alex)
(cherry picked from commit 6ce8d536c80aa1f059e82184f0d1994436b1d526)
References
- https://linux.oracle.com/cve/CVE-2026-23163.html
- https://linux.oracle.com/errata/ELSA-2026-50160.html
- https://git.kernel.org/stable/c/7611d7faccc1218be477671f892a89b25c0cb352
- https://git.kernel.org/stable/c/8b1ecc9377bc641533cd9e76dfa3aee3cd04a007
- https://git.kernel.org/stable/c/ac251d17d8af58ddc3daba65eaf0a99e63dc4284
- https://git.kernel.org/stable/c/c74e2dbb5316898fb2113a8ea3a93b27698dbf68