[PATCH 5.10] ocfs2: add fl->fl_type check in ocfs2_flock() to fix use-after-free in lock_get_status

[PATCH 5.10] ocfs2: add fl->fl_type check in ocfs2_flock() to fix use-after-free in lock_get_status

[Alexey Velichayshiy]

No upstream commit exists for this patch.

The KASAN-reported issue described below is no longer reproduced after
upstream commit f7e33bdbd6d1 ("fs: remove mandatory file locking support"),
but that commit removes kernel functionality altogether and is therefore
not suitable for stable branches.

In ocfs2_flock() the __mandatory_lock(inode) check is performed without
taking the lock type into account. In the reproducer an FLOCK is first
taken on the file while its mode is 0100755, so the inode is not
mandatory-locked yet. Then chmod() changes the mode to 0106743 (S_ISGID
set, S_IXGRP cleared), which makes the inode mandatory-locked. Finally,
close() triggers a repeated call into ocfs2_flock() with
fl_type = F_UNLCK (0x2) and fl_flags = 0x42 to release the lock. By that
point __mandatory_lock() returns true, so the call is rejected
with -ENOLCK before reaching the unlock path. The FLOCK lock is therefore
left leaked (as reported by "Leaked FLOCK lock ..."), and a later read of
/proc/locks dereferences the already freed inode in lock_get_status(),
producing the use-after-free.

ocfs2: Mounting device (7,0) on (node local, slot 0) with ordered data mode.
Leaked FLOCK lock on dev=0x7:0x0 ino=0x4322  fl_owner=00000000d09f0d4d fl_flags=0x2 fl_type=0x1 fl_pid=1111
==================================================================
BUG: KASAN: use-after-free in lock_get_status+0x947/0x9e0 fs/locks.c:2930

CPU: 2 PID: 1116 Comm: syz-executor141 Not tainted 5.10.260-syzkaller #0
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-debian-1.17.0-1 04/01/2014
Call Trace:
 __dump_stack lib/dump_stack.c:77 [inline]
 dump_stack+0x107/0x167 lib/dump_stack.c:118
 print_address_description.constprop.0+0x1c/0x220 mm/kasan/report.c:377
 __kasan_report mm/kasan/report.c:537 [inline]
 kasan_report.cold+0x1f/0x37 mm/kasan/report.c:554
 file_inode include/linux/fs.h:1343 [inline]
 lock_get_status+0x947/0x9e0 fs/locks.c:2930
 locks_show+0x178/0x270 fs/locks.c:3005
 seq_read_iter+0x50e/0x1230 fs/seq_file.c:230
 proc_reg_read_iter+0x20a/0x2e0 fs/proc/inode.c:310
 call_read_iter include/linux/fs.h:2042 [inline]
 do_iter_readv_writev+0x574/0x750 fs/read_write.c:738
 do_iter_read+0x2fc/0x760 fs/read_write.c:801
 vfs_readv+0xf0/0x160 fs/read_write.c:921
 do_preadv fs/read_write.c:1013 [inline]
 __do_sys_preadv fs/read_write.c:1063 [inline]
 __se_sys_preadv fs/read_write.c:1058 [inline]
 __x64_sys_preadv+0x235/0x310 fs/read_write.c:1058
 do_syscall_64+0x33/0x40 arch/x86/entry/common.c:46
 entry_SYSCALL_64_after_hwframe+0x67/0xd1

Following the pattern used by other __mandatory_lock() call sites (in
particular, the changes made for ocfs2_lock() in commit ee860b6a6503
("[PATCH] Skip check for mandatory locks when unlocking")), add
a lock-type check to ocfs2_flock(). With the patch applied, the KASAN
report is no longer reproduced.

Found by Linux Verification Center (linuxtesting.org) with Syzkaller.

Fixes: 53fc622b9e82 ("[PATCH 2/2] ocfs2: cluster aware flock()")
Signed-off-by: Alexey Velichayshiy <a.velichayshiy@ispras.ru>
---
 fs/ocfs2/locks.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/ocfs2/locks.c b/fs/ocfs2/locks.c
index 7edc4e5c7c2c..1712f99ed120 100644
--- a/fs/ocfs2/locks.c
+++ b/fs/ocfs2/locks.c
@@ -103,7 +103,7 @@ int ocfs2_flock(struct file *file, int cmd, struct file_lock *fl)
 
 	if (!(fl->fl_flags & FL_FLOCK))
 		return -ENOLCK;
-	if (__mandatory_lock(inode))
+	if (__mandatory_lock(inode) && fl->fl_type != F_UNLCK)
 		return -ENOLCK;
 
 	if ((osb->s_mount_opt & OCFS2_MOUNT_LOCALFLOCKS) ||
-- 
2.55.0

Re: [PATCH 5.10] ocfs2: add fl->fl_type check in ocfs2_flock() to fix use-after-free in lock_get_status

[Joseph Qi]

On 10/30/26 7:26 AM, Alexey Velichayshiy wrote:
> No upstream commit exists for this patch.
> 
> The KASAN-reported issue described below is no longer reproduced after
> upstream commit f7e33bdbd6d1 ("fs: remove mandatory file locking support"),
> but that commit removes kernel functionality altogether and is therefore
> not suitable for stable branches.
> 
> In ocfs2_flock() the __mandatory_lock(inode) check is performed without
> taking the lock type into account. In the reproducer an FLOCK is first
> taken on the file while its mode is 0100755, so the inode is not
> mandatory-locked yet. Then chmod() changes the mode to 0106743 (S_ISGID
> set, S_IXGRP cleared), which makes the inode mandatory-locked. Finally,
> close() triggers a repeated call into ocfs2_flock() with
> fl_type = F_UNLCK (0x2) and fl_flags = 0x42 to release the lock. By that
> point __mandatory_lock() returns true, so the call is rejected
> with -ENOLCK before reaching the unlock path. The FLOCK lock is therefore
> left leaked (as reported by "Leaked FLOCK lock ..."), and a later read of
> /proc/locks dereferences the already freed inode in lock_get_status(),
> producing the use-after-free.
> 
> ocfs2: Mounting device (7,0) on (node local, slot 0) with ordered data mode.
> Leaked FLOCK lock on dev=0x7:0x0 ino=0x4322  fl_owner=00000000d09f0d4d fl_flags=0x2 fl_type=0x1 fl_pid=1111
> ==================================================================
> BUG: KASAN: use-after-free in lock_get_status+0x947/0x9e0 fs/locks.c:2930
> 
> CPU: 2 PID: 1116 Comm: syz-executor141 Not tainted 5.10.260-syzkaller #0
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-debian-1.17.0-1 04/01/2014
> Call Trace:
>  __dump_stack lib/dump_stack.c:77 [inline]
>  dump_stack+0x107/0x167 lib/dump_stack.c:118
>  print_address_description.constprop.0+0x1c/0x220 mm/kasan/report.c:377
>  __kasan_report mm/kasan/report.c:537 [inline]
>  kasan_report.cold+0x1f/0x37 mm/kasan/report.c:554
>  file_inode include/linux/fs.h:1343 [inline]
>  lock_get_status+0x947/0x9e0 fs/locks.c:2930
>  locks_show+0x178/0x270 fs/locks.c:3005
>  seq_read_iter+0x50e/0x1230 fs/seq_file.c:230
>  proc_reg_read_iter+0x20a/0x2e0 fs/proc/inode.c:310
>  call_read_iter include/linux/fs.h:2042 [inline]
>  do_iter_readv_writev+0x574/0x750 fs/read_write.c:738
>  do_iter_read+0x2fc/0x760 fs/read_write.c:801
>  vfs_readv+0xf0/0x160 fs/read_write.c:921
>  do_preadv fs/read_write.c:1013 [inline]
>  __do_sys_preadv fs/read_write.c:1063 [inline]
>  __se_sys_preadv fs/read_write.c:1058 [inline]
>  __x64_sys_preadv+0x235/0x310 fs/read_write.c:1058
>  do_syscall_64+0x33/0x40 arch/x86/entry/common.c:46
>  entry_SYSCALL_64_after_hwframe+0x67/0xd1
> 
> Following the pattern used by other __mandatory_lock() call sites (in
> particular, the changes made for ocfs2_lock() in commit ee860b6a6503
> ("[PATCH] Skip check for mandatory locks when unlocking")), add
> a lock-type check to ocfs2_flock(). With the patch applied, the KASAN
> report is no longer reproduced.
> 
> Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
> 
> Fixes: 53fc622b9e82 ("[PATCH 2/2] ocfs2: cluster aware flock()")
> Signed-off-by: Alexey Velichayshiy <a.velichayshiy@ispras.ru>

Looks fine.
Reviewed-by: Joseph Qi <joseph.qi@linux.alibaba.com>

> ---
>  fs/ocfs2/locks.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/fs/ocfs2/locks.c b/fs/ocfs2/locks.c
> index 7edc4e5c7c2c..1712f99ed120 100644
> --- a/fs/ocfs2/locks.c
> +++ b/fs/ocfs2/locks.c
> @@ -103,7 +103,7 @@ int ocfs2_flock(struct file *file, int cmd, struct file_lock *fl)
>  
>  	if (!(fl->fl_flags & FL_FLOCK))
>  		return -ENOLCK;
> -	if (__mandatory_lock(inode))
> +	if (__mandatory_lock(inode) && fl->fl_type != F_UNLCK)
>  		return -ENOLCK;
>  
>  	if ((osb->s_mount_opt & OCFS2_MOUNT_LOCALFLOCKS) ||