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

tejas bharambe <[email protected]>
Newsgroups dev.linux.lists.ocfs2-devel,org.kernel.vger.linux-kernel,org.kernel.vger.stable
Message-ID <JH0PR06MB6632F1A4381AB798FED980CE895BA@JH0PR06MB6632.apcprd06.prod.outlook.com>
Hi Andrew,

You're right, I missed that scenario.

The inode can be freed if the file descriptor is closed after mmap() and munmap() races with the fault handler.

I can do one of the following:
1. I can skip the trace firing when VM_FAULT_RETRY is set as I did in v1. It was changed to v4 after Joseph's suggestion to keep traces.
2. If we want to keep traces, we can use ihold()/iput() as shown below:

ihold(inode);   //pin inode
ret = filemap_fault(vmf);
trace_ocfs2_fault(OCFS2_I(inode)->ip_blkno, ...);  // safe, refcount held
iput(inode);  //release inode


Which approach do you prefer?

Thanks,
Tejas
________________________________________
From: Andrew Morton <[email protected]>
Sent: Saturday, April 4, 2026 5:50 PM
To: tejas bharambe <[email protected]>
Cc: Tejas Bharambe <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]>
Subject: Re: [PATCH v4] ocfs2: fix use-after-free in ocfs2_fault() when VM_FAULT_RETRY

On Sun, 5 Apr 2026 00:30:14 +0000 tejas bharambe <[email protected]> wrote:

> 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.

I don't think that's the scenario which Sashiko is suggesting.

Suppose userspace does

        fd = open(...);
        p = mmap(fd, ...);
        close(fd);

Now, that mmap is the only ref against fd.

Now, suppose that userspace does munmap() while another thread is in
the fault handler.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.