Linux kernel -stable discussions
 help / color / mirror / Atom feed
From: Greg KH <gregkh@linuxfoundation.org>
To: Cliff Liu <donghua.liu@windriver.com>
Cc: stable@vger.kernel.org, sfrench@samba.org, pc@cjr.nz,
	lsahlber@redhat.com, sprasad@microsoft.com, tom@talpey.com,
	linux-cifs@vger.kernel.org, samba-technical@lists.samba.org,
	linux-kernel@vger.kernel.org, paul@darkrain42.org,
	Zhe.He@windriver.com
Subject: Re: [PATCH 6.1.y] smb: prevent use-after-free due to open_cached_dir error paths
Date: Wed, 19 Mar 2025 07:03:26 -0700	[thread overview]
Message-ID: <2025031913-unclaimed-ocean-06f5@gregkh> (raw)
In-Reply-To: <20250319090839.3631424-1-donghua.liu@windriver.com>

On Wed, Mar 19, 2025 at 05:08:39PM +0800, Cliff Liu wrote:
> From: Paul Aurich <paul@darkrain42.org>
> 
> If open_cached_dir() encounters an error parsing the lease from the
> server, the error handling may race with receiving a lease break,
> resulting in open_cached_dir() freeing the cfid while the queued work is
> pending.
> 
> Update open_cached_dir() to drop refs rather than directly freeing the
> cfid.
> 
> Have cached_dir_lease_break(), cfids_laundromat_worker(), and
> invalidate_all_cached_dirs() clear has_lease immediately while still
> holding cfids->cfid_list_lock, and then use this to also simplify the
> reference counting in cfids_laundromat_worker() and
> invalidate_all_cached_dirs().
> 
> Fixes this KASAN splat (which manually injects an error and lease break
> in open_cached_dir()):
> 
> ==================================================================
> BUG: KASAN: slab-use-after-free in smb2_cached_lease_break+0x27/0xb0
> Read of size 8 at addr ffff88811cc24c10 by task kworker/3:1/65
> 
> CPU: 3 UID: 0 PID: 65 Comm: kworker/3:1 Not tainted 6.12.0-rc6-g255cf264e6e5-dirty #87
> Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020
> Workqueue: cifsiod smb2_cached_lease_break
> Call Trace:
>  <TASK>
>  dump_stack_lvl+0x77/0xb0
>  print_report+0xce/0x660
>  kasan_report+0xd3/0x110
>  smb2_cached_lease_break+0x27/0xb0
>  process_one_work+0x50a/0xc50
>  worker_thread+0x2ba/0x530
>  kthread+0x17c/0x1c0
>  ret_from_fork+0x34/0x60
>  ret_from_fork_asm+0x1a/0x30
>  </TASK>
> 
> Allocated by task 2464:
>  kasan_save_stack+0x33/0x60
>  kasan_save_track+0x14/0x30
>  __kasan_kmalloc+0xaa/0xb0
>  open_cached_dir+0xa7d/0x1fb0
>  smb2_query_path_info+0x43c/0x6e0
>  cifs_get_fattr+0x346/0xf10
>  cifs_get_inode_info+0x157/0x210
>  cifs_revalidate_dentry_attr+0x2d1/0x460
>  cifs_getattr+0x173/0x470
>  vfs_statx_path+0x10f/0x160
>  vfs_statx+0xe9/0x150
>  vfs_fstatat+0x5e/0xc0
>  __do_sys_newfstatat+0x91/0xf0
>  do_syscall_64+0x95/0x1a0
>  entry_SYSCALL_64_after_hwframe+0x76/0x7e
> 
> Freed by task 2464:
>  kasan_save_stack+0x33/0x60
>  kasan_save_track+0x14/0x30
>  kasan_save_free_info+0x3b/0x60
>  __kasan_slab_free+0x51/0x70
>  kfree+0x174/0x520
>  open_cached_dir+0x97f/0x1fb0
>  smb2_query_path_info+0x43c/0x6e0
>  cifs_get_fattr+0x346/0xf10
>  cifs_get_inode_info+0x157/0x210
>  cifs_revalidate_dentry_attr+0x2d1/0x460
>  cifs_getattr+0x173/0x470
>  vfs_statx_path+0x10f/0x160
>  vfs_statx+0xe9/0x150
>  vfs_fstatat+0x5e/0xc0
>  __do_sys_newfstatat+0x91/0xf0
>  do_syscall_64+0x95/0x1a0
>  entry_SYSCALL_64_after_hwframe+0x76/0x7e
> 
> Last potentially related work creation:
>  kasan_save_stack+0x33/0x60
>  __kasan_record_aux_stack+0xad/0xc0
>  insert_work+0x32/0x100
>  __queue_work+0x5c9/0x870
>  queue_work_on+0x82/0x90
>  open_cached_dir+0x1369/0x1fb0
>  smb2_query_path_info+0x43c/0x6e0
>  cifs_get_fattr+0x346/0xf10
>  cifs_get_inode_info+0x157/0x210
>  cifs_revalidate_dentry_attr+0x2d1/0x460
>  cifs_getattr+0x173/0x470
>  vfs_statx_path+0x10f/0x160
>  vfs_statx+0xe9/0x150
>  vfs_fstatat+0x5e/0xc0
>  __do_sys_newfstatat+0x91/0xf0
>  do_syscall_64+0x95/0x1a0
>  entry_SYSCALL_64_after_hwframe+0x76/0x7e
> 
> The buggy address belongs to the object at ffff88811cc24c00
>  which belongs to the cache kmalloc-1k of size 1024
> The buggy address is located 16 bytes inside of
>  freed 1024-byte region [ffff88811cc24c00, ffff88811cc25000)
> 
> Cc: stable@vger.kernel.org
> Signed-off-by: Paul Aurich <paul@darkrain42.org>
> Signed-off-by: Steve French <stfrench@microsoft.com>
> [ Do not apply the change for cfids_laundromat_worker() since there is no
>   this function and related feature on 6.1.y. Update open_cached_dir()
>   according to method of upstream patch. ]
> Signed-off-by: Cliff Liu <donghua.liu@windriver.com>
> Signed-off-by: He Zhe <Zhe.He@windriver.com>
> ---
> Verified the build test.
> ---
>  fs/smb/client/cached_dir.c | 39 ++++++++++++++++----------------------
>  1 file changed, 16 insertions(+), 23 deletions(-)

No upstream git id :(

  parent reply	other threads:[~2025-03-19 14:04 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-19  9:08 [PATCH 6.1.y] smb: prevent use-after-free due to open_cached_dir error paths Cliff Liu
2025-03-19 11:02 ` Sasha Levin
2025-03-19 14:03 ` Greg KH [this message]
2025-03-20  2:12   ` Cliff Liu
2025-03-20  3:05 ` Paul Aurich

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2025031913-unclaimed-ocean-06f5@gregkh \
    --to=gregkh@linuxfoundation.org \
    --cc=Zhe.He@windriver.com \
    --cc=donghua.liu@windriver.com \
    --cc=linux-cifs@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lsahlber@redhat.com \
    --cc=paul@darkrain42.org \
    --cc=pc@cjr.nz \
    --cc=samba-technical@lists.samba.org \
    --cc=sfrench@samba.org \
    --cc=sprasad@microsoft.com \
    --cc=stable@vger.kernel.org \
    --cc=tom@talpey.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox