linux-kernel - Re: [PATCH] ksmbd: vfs: fix race on m_flags in vfs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAKYAXd9NWRLf8eyqC4+bUx_MaNoKf8-G8q+_pwUdp4_V+_MhCg@mail.gmail.com>
Date: Mon, 24 Nov 2025 16:33:19 +0900
From: Namjae Jeon <linkinjeon@...nel.org>
To: Qianchang Zhao <pioooooooooip@...il.com>
Cc: Steve French <smfrench@...il.com>, gregkh@...uxfoundation.org, 
	linux-cifs@...r.kernel.org, linux-kernel@...r.kernel.org, 
	Zhitong Liu <liuzhitong1993@...il.com>, stable@...r.kernel.org
Subject: Re: [PATCH] ksmbd: vfs: fix race on m_flags in vfs_cache

On Sun, Nov 23, 2025 at 11:54 AM Qianchang Zhao <pioooooooooip@...il.com> wrote:
>
> ksmbd maintains delete-on-close and pending-delete state in
> ksmbd_inode->m_flags. In vfs_cache.c this field is accessed under
> inconsistent locking: some paths read and modify m_flags under
> ci->m_lock while others do so without taking the lock at all.
>
> Examples:
>
>  - ksmbd_query_inode_status() and __ksmbd_inode_close() use
>    ci->m_lock when checking or updating m_flags.
>  - ksmbd_inode_pending_delete(), ksmbd_set_inode_pending_delete(),
>    ksmbd_clear_inode_pending_delete() and ksmbd_fd_set_delete_on_close()
>    used to read and modify m_flags without ci->m_lock.
>
> This creates a potential data race on m_flags when multiple threads
> open, close and delete the same file concurrently. In the worst case
> delete-on-close and pending-delete bits can be lost or observed in an
> inconsistent state, leading to confusing delete semantics (files that
> stay on disk after delete-on-close, or files that disappear while still
> in use).
>
> Fix it by:
>
>  - Making ksmbd_query_inode_status() look at m_flags under ci->m_lock
>    after dropping inode_hash_lock.
>  - Adding ci->m_lock protection to all helpers that read or modify
>    m_flags (ksmbd_inode_pending_delete(), ksmbd_set_inode_pending_delete(),
>    ksmbd_clear_inode_pending_delete(), ksmbd_fd_set_delete_on_close()).
>  - Keeping the existing ci->m_lock protection in __ksmbd_inode_close(),
>    and moving the actual unlink/xattr removal outside the lock.
>
> This unifies the locking around m_flags and removes the data race while
> preserving the existing delete-on-close behaviour.
>
> Reported-by: Qianchang Zhao <pioooooooooip@...il.com>
> Reported-by: Zhitong Liu <liuzhitong1993@...il.com>
> Cc: stable@...r.kernel.org
> Signed-off-by: Qianchang Zhao <pioooooooooip@...il.com>
I have directly updated your patch and applied it to #ksmbd-for-next-next.
Please check the attached patch and let me know if you find any issues.
Thanks.

View attachment "0001-ksmbd-vfs-fix-race-on-m_flags-in-vfs_cache.patch" of type "text/x-patch" (5515 bytes)