Homepage

Use After Free Affecting kernel-uek-modules-wireless package, versions <0:6.12.0-204.92.4.2.el9uek

Severity

 Recommended
high

Based on Oracle Linux security rating.

Threat Intelligence

EPSS
0.13% (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-KERNELUEKMODULESWIRELESS-17867595
  • published6 Jul 2026
  • disclosed24 Apr 2026
Report a new vulnerability Found a mistake?

Introduced: 24 Apr 2026

CVE-2026-31597  (opens in a new tab)
CWE-416  (opens in a new tab)

How to fix?

Upgrade Oracle:9 kernel-uek-modules-wireless to version 0:6.12.0-204.92.4.2.el9uek or higher.
This issue was patched in ELSA-2026-50372.

NVD Description

Note: Versions mentioned in the description apply only to the upstream kernel-uek-modules-wireless package and not the kernel-uek-modules-wireless 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:

ocfs2: fix use-after-free in ocfs2_fault() when VM_FAULT_RETRY

filemap_fault() may drop the mmap_lock before returning VM_FAULT_RETRY, as documented in mm/filemap.c:

"If our return value has VM_FAULT_RETRY set, it's because the mmap_lock may be dropped before doing I/O or by lock_folio_maybe_drop_mmap()."

When this happens, a concurrent munmap() can call remove_vma() and free the vm_area_struct via RCU. The saved 'vma' pointer in ocfs2_fault() then becomes a dangling pointer, and the subsequent trace_ocfs2_fault() call dereferences it -- a use-after-free.

Fix this by saving ip_blkno as a plain integer before calling filemap_fault(), and removing vma from the trace event. Since ip_blkno is copied by value before the lock can be dropped, it remains valid regardless of what happens to the vma or inode afterward.