Re: [PATCH] kernfs: protect of->kn access in fop_read_iter/fop_mmap

[Tejun Heo]

Hello,

On Mon, Apr 27, 2026 at 03:35:21PM +0200, Ravineet Singh wrote:
> kernfs_fop_read_iter() and kernfs_fop_mmap() dereference of->kn->flags
> without holding an active reference on the kernfs node. If the node is
> removed concurrently, this leads to a use-after-free:
> 
> [  448.037888] Unable to handle kernel paging request at virtual address ffffff821d8cedf0
> [  448.093213] Mem abort info:
> [  448.104535]   ESR = 0x0000000096000005
> [  448.113391]   EC = 0x25: DABT (current EL), IL = 32 bits
> [  448.126411]   SET = 0, FnV = 0
> [  448.130758]   EA = 0, S1PTW = 0
> [  448.134268]   FSC = 0x05: level 1 translation fault
> [  448.140335] Data abort info:
> [  448.143275]   ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000
> [  448.150223]   CM = 0, WnR = 0, TnD = 0, TagAccess = 0
> [  448.155668]   GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
> [  448.161233] swapper pgtable: 4k pages, 39-bit VAs, pgdp=00000000afab8000
> [  448.168835] [ffffff821d8cedf0] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000
> [  448.178817] Internal error: Oops: 0000000096000005 [#1] PREEMPT SMP
> [  448.284717] pc : kernfs_fop_read_iter+0x1c/0x1ac
> [  448.289416] lr : vfs_read+0x1c0/0x2a0
> [  448.368374] Call trace:
> [  448.370855]  kernfs_fop_read_iter+0x1c/0x1ac
> [  448.375156]  vfs_read+0x1c0/0x2a0
> [  448.378508]  ksys_read+0x6c/0x100
> [  448.381901]  __arm64_sys_read+0x18/0x20
> [  448.385768]  invoke_syscall.constprop.0+0x4c/0xe0
> [  448.390502]  do_el0_svc+0x3c/0xb8
> [  448.393898]  el0_svc+0x18/0x4c
> [  448.396990]  el0t_64_sync_handler+0x118/0x124
> [  448.401377]  el0t_64_sync+0x14c/0x150

Do you have a repro for this?

> Use kernfs_get_active_of() to obtain an active reference that also
> checks the released flag, consistent with other of->kn accesses in
> fs/kernfs/file.c. These paths were not covered when
> kernfs_get_active_of() was introduced in commit 3c9ba2777d6c8
> ("kernfs: Fix UAF in polling when open file is released").

My memory is hazy but of->kn should be valid as long as of is alive. inode
holds the pin to its kn until inode is released and open files pin their
inodes. Active ref is something different - it's used to implement revoke
semantics so that the backend kernfs implementation can disconnect from
lingering open files, but that's not what controls the object lifetimes.

Thanks.

-- 
tejun