Re: [PATCH v4] ocfs2: fix use-after-free in ocfs2_fault() when VM_FAULT_RETRY

[tejas bharambe]

Following is my response for question posted on https://sashiko.dev/#/patchset/20260403035333.136824-1-tejas.bharambe%40outlook.com


No. For ocfs2_fault() to be executing, the file must be open and
the process holds an active file descriptor. The inode's lifetime
is tied to the file's reference count, which remains held by the
file descriptor for the duration of the fault handler. munmap()
can free the VMA (decrementing vm_file's refcount) but cannot
free the inode as long as the file descriptor is open. The faulting
thread cannot call close() while it is inside the fault handler,
so the inode is guaranteed to outlive the trace call.

________________________________________
From: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
Sent: Friday, April 3, 2026 12:29 PM
To: Tejas Bharambe <thbharam@xxxxxxxxx>
Cc: ocfs2-devel@xxxxxxxxxxxxxxx <ocfs2-devel@xxxxxxxxxxxxxxx>; mark@xxxxxxxxxx <mark@xxxxxxxxxx>; jlbec@xxxxxxxxxxxx <jlbec@xxxxxxxxxxxx>; joseph.qi@xxxxxxxxxxxxxxxxx <joseph.qi@xxxxxxxxxxxxxxxxx>; linux-kernel@xxxxxxxxxxxxxxx <linux-kernel@xxxxxxxxxxxxxxx>; syzbot+a49010a0e8fcdeea075f@xxxxxxxxxxxxxxxxxxxxxxxxx <syzbot+a49010a0e8fcdeea075f@xxxxxxxxxxxxxxxxxxxxxxxxx>; Tejas Bharambe <tejas.bharambe@xxxxxxxxxxx>; stable@xxxxxxxxxxxxxxx <stable@xxxxxxxxxxxxxxx>
Subject: Re: [PATCH v4] ocfs2: fix use-after-free in ocfs2_fault() when VM_FAULT_RETRY

On Thu,  2 Apr 2026 20:53:33 -0700 Tejas Bharambe <thbharam@xxxxxxxxx> wrote:

> 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 the inode reference before calling filemap_fault(),
> and removing vma from the trace event. The inode remains valid across
> the lock drop since the file is still open, so the trace can fire in
> all cases without dereferencing the potentially freed vma.

There's one question from the Sashiko AI reviewbot:
        https://sashiko.dev/#/patchset/20260403035333.136824-1-tejas.bharambe@xxxxxxxxxxx