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

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

[Tejas Bharambe]

From: Tejas Bharambe <tejas.bharambe@outlook.com>

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.

Reported-by: syzbot+a49010a0e8fcdeea075f@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=a49010a0e8fcdeea075f
Cc: stable@vger.kernel.org
Suggested-by: Joseph Qi <joseph.qi@linux.alibaba.com>
Signed-off-by: Tejas Bharambe <tejas.bharambe@outlook.com>
---
 fs/ocfs2/mmap.c        |  6 +++---
 fs/ocfs2/ocfs2_trace.h | 10 ++++------
 2 files changed, 7 insertions(+), 9 deletions(-)

diff --git a/fs/ocfs2/mmap.c b/fs/ocfs2/mmap.c
index 50e2faf64c..41c08c5a3d 100644
--- a/fs/ocfs2/mmap.c
+++ b/fs/ocfs2/mmap.c
@@ -30,7 +30,7 @@
 
 static vm_fault_t ocfs2_fault(struct vm_fault *vmf)
 {
-	struct vm_area_struct *vma = vmf->vma;
+	struct inode *inode = file_inode(vmf->vma->vm_file);
 	sigset_t oldset;
 	vm_fault_t ret;
 
@@ -38,8 +38,8 @@ static vm_fault_t ocfs2_fault(struct vm_fault *vmf)
 	ret = filemap_fault(vmf);
 	ocfs2_unblock_signals(&oldset);
 
-	trace_ocfs2_fault(OCFS2_I(vma->vm_file->f_mapping->host)->ip_blkno,
-			  vma, vmf->page, vmf->pgoff);
+	trace_ocfs2_fault(OCFS2_I(inode)->ip_blkno,
+			  vmf->page, vmf->pgoff);
 	return ret;
 }
 
diff --git a/fs/ocfs2/ocfs2_trace.h b/fs/ocfs2/ocfs2_trace.h
index 4b32fb5658..6c2c97a980 100644
--- a/fs/ocfs2/ocfs2_trace.h
+++ b/fs/ocfs2/ocfs2_trace.h
@@ -1246,22 +1246,20 @@ TRACE_EVENT(ocfs2_write_end_inline,
 
 TRACE_EVENT(ocfs2_fault,
 	TP_PROTO(unsigned long long ino,
-		 void *area, void *page, unsigned long pgoff),
-	TP_ARGS(ino, area, page, pgoff),
+		 void *page, unsigned long pgoff),
+	TP_ARGS(ino, page, pgoff),
 	TP_STRUCT__entry(
 		__field(unsigned long long, ino)
-		__field(void *, area)
 		__field(void *, page)
 		__field(unsigned long, pgoff)
 	),
 	TP_fast_assign(
 		__entry->ino = ino;
-		__entry->area = area;
 		__entry->page = page;
 		__entry->pgoff = pgoff;
 	),
-	TP_printk("%llu %p %p %lu",
-		  __entry->ino, __entry->area, __entry->page, __entry->pgoff)
+	TP_printk("%llu %p %lu",
+		  __entry->ino, __entry->page, __entry->pgoff)
 );
 
 /* End of trace events for fs/ocfs2/mmap.c. */
-- 
2.53.0

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

[Andrew Morton]

On Thu,  2 Apr 2026 20:53:33 -0700 Tejas Bharambe <thbharam@gmail.com> 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@outlook.com

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@linux-foundation.org>
Sent: Friday, April 3, 2026 12:29 PM
To: Tejas Bharambe <thbharam@gmail.com>
Cc: ocfs2-devel@lists.linux.dev <ocfs2-devel@lists.linux.dev>; mark@fasheh.com <mark@fasheh.com>; jlbec@evilplan.org <jlbec@evilplan.org>; joseph.qi@linux.alibaba.com <joseph.qi@linux.alibaba.com>; linux-kernel@vger.kernel.org <linux-kernel@vger.kernel.org>; syzbot+a49010a0e8fcdeea075f@syzkaller.appspotmail.com <syzbot+a49010a0e8fcdeea075f@syzkaller.appspotmail.com>; Tejas Bharambe <tejas.bharambe@outlook.com>; stable@vger.kernel.org <stable@vger.kernel.org>
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@gmail.com> 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@outlook.com

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

[Andrew Morton]

On Sun, 5 Apr 2026 00:30:14 +0000 tejas bharambe <tejas.bharambe@outlook.com> 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.

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

[tejas bharambe]

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 <akpm@linux-foundation.org>
Sent: Saturday, April 4, 2026 5:50 PM
To: tejas bharambe <tejas.bharambe@outlook.com>
Cc: Tejas Bharambe <thbharam@gmail.com>; ocfs2-devel@lists.linux.dev <ocfs2-devel@lists.linux.dev>; mark@fasheh.com <mark@fasheh.com>; jlbec@evilplan.org <jlbec@evilplan.org>; joseph.qi@linux.alibaba.com <joseph.qi@linux.alibaba.com>; linux-kernel@vger.kernel.org <linux-kernel@vger.kernel.org>; syzbot+a49010a0e8fcdeea075f@syzkaller.appspotmail.com <syzbot+a49010a0e8fcdeea075f@syzkaller.appspotmail.com>; stable@vger.kernel.org <stable@vger.kernel.org>
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 <tejas.bharambe@outlook.com> 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.

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

[Joseph Qi]

On 4/8/26 11:50 AM, tejas bharambe wrote:
> 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?
> 
It seems theoretically possible.
Since we only want to trace ip_blkno here, not inode itself, we can
simply save it at first.

Thanks,
Joseph

> Thanks,
> Tejas
> ________________________________________
> From: Andrew Morton <akpm@linux-foundation.org>
> Sent: Saturday, April 4, 2026 5:50 PM
> To: tejas bharambe <tejas.bharambe@outlook.com>
> Cc: Tejas Bharambe <thbharam@gmail.com>; ocfs2-devel@lists.linux.dev <ocfs2-devel@lists.linux.dev>; mark@fasheh.com <mark@fasheh.com>; jlbec@evilplan.org <jlbec@evilplan.org>; joseph.qi@linux.alibaba.com <joseph.qi@linux.alibaba.com>; linux-kernel@vger.kernel.org <linux-kernel@vger.kernel.org>; syzbot+a49010a0e8fcdeea075f@syzkaller.appspotmail.com <syzbot+a49010a0e8fcdeea075f@syzkaller.appspotmail.com>; stable@vger.kernel.org <stable@vger.kernel.org>
> 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 <tejas.bharambe@outlook.com> 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.

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

[Andrew Morton]

On Wed, 8 Apr 2026 03:50:17 +0000 tejas bharambe <tejas.bharambe@outlook.com> wrote:

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

Well, that's down to the ocfs2 maintiners.  Me, omitting traces doesn't
sound good.

But we should consider performance implications - this is a fairly hot
path and iget/iput are a little costly.  Perhaps there's a way to avoid
the iget/iput if tracing isn't enabled.  As long as we handle the case
where tracing get enabled immediately after we've done the

	if (tracing enabled)
		iget()


> Thanks,
> Tejas
> ________________________________________
> From: Andrew Morton <akpm@linux-foundation.org>
> Sent: Saturday, April 4, 2026 5:50 PM
> To: tejas bharambe <tejas.bharambe@outlook.com>
> Cc: Tejas Bharambe <thbharam@gmail.com>; ocfs2-devel@lists.linux.dev <ocfs2-devel@lists.linux.dev>; mark@fasheh.com <mark@fasheh.com>; jlbec@evilplan.org <jlbec@evilplan.org>; joseph.qi@linux.alibaba.com <joseph.qi@linux.alibaba.com>; linux-kernel@vger.kernel.org <linux-kernel@vger.kernel.org>; syzbot+a49010a0e8fcdeea075f@syzkaller.appspotmail.com <syzbot+a49010a0e8fcdeea075f@syzkaller.appspotmail.com>; stable@vger.kernel.org <stable@vger.kernel.org>
> 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 <tejas.bharambe@outlook.com> 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.

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

[Tejas Bharambe]

I see the concern on using ihold/iput on performance. I find Jospeh's
suggestion valuable. Let me send in a new patch, I will just save
ip_blkno as a plain integer, that should be zero overhead


On Wed, Apr 8, 2026 at 1:12 PM Andrew Morton <akpm@linux-foundation.org> wrote:
>
> On Wed, 8 Apr 2026 03:50:17 +0000 tejas bharambe <tejas.bharambe@outlook.com> wrote:
>
> > 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?
>
> Well, that's down to the ocfs2 maintiners.  Me, omitting traces doesn't
> sound good.
>
> But we should consider performance implications - this is a fairly hot
> path and iget/iput are a little costly.  Perhaps there's a way to avoid
> the iget/iput if tracing isn't enabled.  As long as we handle the case
> where tracing get enabled immediately after we've done the
>
>         if (tracing enabled)
>                 iget()
>
>
> > Thanks,
> > Tejas
> > ________________________________________
> > From: Andrew Morton <akpm@linux-foundation.org>
> > Sent: Saturday, April 4, 2026 5:50 PM
> > To: tejas bharambe <tejas.bharambe@outlook.com>
> > Cc: Tejas Bharambe <thbharam@gmail.com>; ocfs2-devel@lists.linux.dev <ocfs2-devel@lists.linux.dev>; mark@fasheh.com <mark@fasheh.com>; jlbec@evilplan.org <jlbec@evilplan.org>; joseph.qi@linux.alibaba.com <joseph.qi@linux.alibaba.com>; linux-kernel@vger.kernel.org <linux-kernel@vger.kernel.org>; syzbot+a49010a0e8fcdeea075f@syzkaller.appspotmail.com <syzbot+a49010a0e8fcdeea075f@syzkaller.appspotmail.com>; stable@vger.kernel.org <stable@vger.kernel.org>
> > 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 <tejas.bharambe@outlook.com> 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.