Bug 2461484 (CVE-2026-31597)

Summary: CVE-2026-31597 kernel: ocfs2: fix use-after-free in ocfs2_fault() when VM_FAULT_RETRY
Product: [Other] Security Response Reporter: OSIDB Bzimport <bzimport>
Component: vulnerabilityAssignee: Product Security <prodsec-ir-bot>
Status: NEW --- QA Contact:
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: unspecifiedCC: rhel-process-autobot, watson-tool-maintainers
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: ---
Doc Text:
A flaw was found in the Linux kernel's OCFS2 (Oracle Cluster File System version 2) component. A local attacker could exploit a use-after-free vulnerability when `filemap_fault()` drops the `mmap_lock` before returning `VM_FAULT_RETRY`. This allows a concurrent `munmap()` operation to free a `vm_area_struct`, leading to `ocfs2_fault()` dereferencing a dangling pointer. This issue can result in system instability or crashes.
 Story Points: ---
Clone Of: Environment:
Last Closed: Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description OSIDB Bzimport 2026-04-24 15:04:13 UTC 
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.
Comment 1 Keith Grant 2026-04-24 19:13:04 UTC 
Upstream advisory:
https://lore.kernel.org/linux-cve-announce/2026042417-CVE-2026-31597-79cd@gregkh/T