Linux NFS development
 help / color / mirror / Atom feed
From: yangerkun <yangerkun@huaweicloud.com>
To: yangerkun <yangerkun@huawei.com>,
	Anna Schumaker <anna.schumaker@oracle.com>,
	trondmy@kernel.org, anna@kernel.org
Cc: linux-nfs@vger.kernel.org, yi.zhang@huawei.com
Subject: Re: [PATCH] NFSV4: fix rpc_task use-after-free when open concurrently
Date: Wed, 9 Oct 2024 11:02:58 +0800	[thread overview]
Message-ID: <086eb949-6d07-e5af-da65-e4bccf84dd1a@huaweicloud.com> (raw)
In-Reply-To: <ec268559-2b29-c7b1-85b8-7a86a4ba228a@huawei.com>

Hi,

Ping for this patch...

在 2024/9/29 9:45, yangerkun 写道:
> 
> 
> 在 2024/9/29 9:38, yangerkun 写道:
>>
>>
>> 在 2024/9/28 4:58, Anna Schumaker 写道:
>>> Hi Yang,
>>>
>>> On 9/26/24 2:12 AM, Yang Erkun wrote:
>>>> From: Yang Erkun <yangerkun@huawei.com>
>>>>
>>>> Two threads that work with the same cred try to open different files
>>>> concurrently, they will utilize the same nfs4_state_owner. And in order
>>>> to sequential open request send to server, the second task will fall
>>>> into RPC_TASK_QUEUED in nfs_wait_on_sequence since there is already one
>>>> work doing the open operation. Furthermore, the second task will wait
>>>> until the first task completes its work, call 
>>>> rpc_wake_up_queued_task in
>>>> nfs_release_seqid to wake up the second task, allowing it to complete
>>>> the remaining open operation.
>>>>
>>>> The preceding logic does not cause any problems under normal
>>>> circumstances. However, when once we force an unmount using `umount 
>>>> -f`,
>>>> the function nfs_umount_begin attempts to kill all tasks by calling
>>>> rpc_signal_task. This help wake up the second task, but it sets the
>>>> status to -ERESTARTSYS. This status prevents `nfs4_open_release` from
>>>> calling `nfs4_opendata_to_nfs4_state`. Consequently, while the second
>>>> task will be freed, the original tasks will still exist in
>>>> sequence->list(see nfs_release_seqid). Latter, when the first thread
>>>> calls nfs_release_seqid and attempts to wake up the second task, it 
>>>> will
>>>> trigger the uaf.
>>>>
>>>> To resolve this issue, ensure rpc_task will remove it from
>>>> sequence->list by adding nfs_release_seqid in nfs4_open_release.
>>>>
>>>> ==================================================================
>>>> BUG: KASAN: slab-use-after-free in rpc_wake_up_queued_task+0xbb/0xc0
>>>> Read of size 8 at addr ff11000007639930 by task bash/792
>>>>
>>>> CPU: 0 UID: 0 PID: 792 Comm: bash Tainted: G    B   W
>>>> 6.11.0-09960-gd10b58fe53dc-dirty #10
>>>> Tainted: [B]=BAD_PAGE, [W]=WARN
>>>> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
>>>> 1.16.1-2.fc37 04/01/2014
>>>> Call Trace:
>>>>   <TASK>
>>>>   dump_stack_lvl+0xa3/0x120
>>>>   print_address_description.constprop.0+0x63/0x510
>>>>   print_report+0xf5/0x360
>>>>   kasan_report+0xd9/0x140
>>>>   __asan_report_load8_noabort+0x24/0x40
>>>>   rpc_wake_up_queued_task+0xbb/0xc0
>>>>   nfs_release_seqid+0x1e1/0x2f0
>>>>   nfs_free_seqid+0x1a/0x40
>>>>   nfs4_opendata_free+0xc6/0x3e0
>>>>   _nfs4_do_open.isra.0+0xbe3/0x1380
>>>>   nfs4_do_open+0x28b/0x620
>>>>   nfs4_atomic_open+0x2c6/0x3a0
>>>>   nfs_atomic_open+0x4f8/0x1180
>>>>   atomic_open+0x186/0x4e0
>>>>   lookup_open.isra.0+0x3e7/0x15b0
>>>>   open_last_lookups+0x85d/0x1260
>>>>   path_openat+0x151/0x7b0
>>>>   do_filp_open+0x1e0/0x310
>>>>   do_sys_openat2+0x178/0x1f0
>>>>   do_sys_open+0xa2/0x100
>>>>   __x64_sys_openat+0xa8/0x120
>>>>   x64_sys_call+0x2507/0x4540
>>>>   do_syscall_64+0xa7/0x240
>>>>   entry_SYSCALL_64_after_hwframe+0x76/0x7e
>>>>
>>>> ...
>>>>
>>>> Allocated by task 767:
>>>>   kasan_save_stack+0x3b/0x70
>>>>   kasan_save_track+0x1c/0x40
>>>>   kasan_save_alloc_info+0x44/0x70
>>>>   __kasan_slab_alloc+0xaf/0xc0
>>>>   kmem_cache_alloc_noprof+0x1e0/0x4f0
>>>>   rpc_new_task+0xe7/0x220
>>>>   rpc_run_task+0x27/0x7d0
>>>>   nfs4_run_open_task+0x477/0x810
>>>>   _nfs4_proc_open+0xc0/0x6d0
>>>>   _nfs4_open_and_get_state+0x178/0xc50
>>>>   _nfs4_do_open.isra.0+0x47f/0x1380
>>>>   nfs4_do_open+0x28b/0x620
>>>>   nfs4_atomic_open+0x2c6/0x3a0
>>>>   nfs_atomic_open+0x4f8/0x1180
>>>>   atomic_open+0x186/0x4e0
>>>>   lookup_open.isra.0+0x3e7/0x15b0
>>>>   open_last_lookups+0x85d/0x1260
>>>>   path_openat+0x151/0x7b0
>>>>   do_filp_open+0x1e0/0x310
>>>>   do_sys_openat2+0x178/0x1f0
>>>>   do_sys_open+0xa2/0x100
>>>>   __x64_sys_openat+0xa8/0x120
>>>>   x64_sys_call+0x2507/0x4540
>>>>   do_syscall_64+0xa7/0x240
>>>>   entry_SYSCALL_64_after_hwframe+0x76/0x7e
>>>>
>>>> Freed by task 767:
>>>>   kasan_save_stack+0x3b/0x70
>>>>   kasan_save_track+0x1c/0x40
>>>>   kasan_save_free_info+0x43/0x80
>>>>   __kasan_slab_free+0x4f/0x90
>>>>   kmem_cache_free+0x199/0x4f0
>>>>   mempool_free_slab+0x1f/0x30
>>>>   mempool_free+0xdf/0x3d0
>>>>   rpc_free_task+0x12d/0x180
>>>>   rpc_final_put_task+0x10e/0x150
>>>>   rpc_do_put_task+0x63/0x80
>>>>   rpc_put_task+0x18/0x30
>>>>   nfs4_run_open_task+0x4f4/0x810
>>>>   _nfs4_proc_open+0xc0/0x6d0
>>>>   _nfs4_open_and_get_state+0x178/0xc50
>>>>   _nfs4_do_open.isra.0+0x47f/0x1380
>>>>   nfs4_do_open+0x28b/0x620
>>>>   nfs4_atomic_open+0x2c6/0x3a0
>>>>   nfs_atomic_open+0x4f8/0x1180
>>>>   atomic_open+0x186/0x4e0
>>>>   lookup_open.isra.0+0x3e7/0x15b0
>>>>   open_last_lookups+0x85d/0x1260
>>>>   path_openat+0x151/0x7b0
>>>>   do_filp_open+0x1e0/0x310
>>>>   do_sys_openat2+0x178/0x1f0
>>>>   do_sys_open+0xa2/0x100
>>>>   __x64_sys_openat+0xa8/0x120
>>>>   x64_sys_call+0x2507/0x4540
>>>>   do_syscall_64+0xa7/0x240
>>>>   entry_SYSCALL_64_after_hwframe+0x76/0x7e
>>>
>>> Once I apply this patch I'm seeing my client hang when running 
>>> xfstests generic/451 with NFS v4.0. I was wondering if you could 
>>> check if you see the same hang, and please fix it if so?
>>>
>>
>> I have try to reproduce this with kernel commit:
> 
> Forget to say, add this patch too...
> 
>>
>> commit abf2050f51fdca0fd146388f83cddd95a57a008d
>> Merge: 9ab27b018649 81ee62e8d09e
>> Author: Linus Torvalds <torvalds@linux-foundation.org>
>> Date:   Mon Sep 23 15:27:58 2024 -0700
>>
>>      Merge tag 'media/v6.12-1' of 
>> git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media
>>
>> And for nfs4.0/nfs4.1, all seems ok now...
>>
>> Can you provide more info about the 'hang' you meet now?
>>
>>
>>> Thanks,
>>> Anna
>>>
>>>>
>>>> Fixes: 24ac23ab88df ("NFSv4: Convert open() into an asynchronous RPC 
>>>> call")
>>>> Signed-off-by: Yang Erkun <yangerkun@huawei.com>
>>>> ---
>>>>   fs/nfs/nfs4proc.c | 1 +
>>>>   1 file changed, 1 insertion(+)
>>>>
>>>> diff --git a/fs/nfs/nfs4proc.c b/fs/nfs/nfs4proc.c
>>>> index b8ffbe52ba15..4685621ba469 100644
>>>> --- a/fs/nfs/nfs4proc.c
>>>> +++ b/fs/nfs/nfs4proc.c
>>>> @@ -2603,6 +2603,7 @@ static void nfs4_open_release(void *calldata)
>>>>       struct nfs4_opendata *data = calldata;
>>>>       struct nfs4_state *state = NULL;
>>>> +    nfs_release_seqid(data->o_arg.seqid);
>>>>       /* If this request hasn't been cancelled, do nothing */
>>>>       if (!data->cancelled)
>>>>           goto out_free;


  reply	other threads:[~2024-10-09  3:03 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-09-26  6:12 [PATCH] NFSV4: fix rpc_task use-after-free when open concurrently Yang Erkun
2024-09-27 20:58 ` Anna Schumaker
2024-09-29  1:07   ` yangerkun
2024-09-29  1:38   ` yangerkun
2024-09-29  1:45     ` yangerkun
2024-10-09  3:02       ` yangerkun [this message]
2024-10-09 14:54         ` Trond Myklebust
2024-10-10  3:45           ` yangerkun
2024-10-10 14:56             ` Trond Myklebust
2024-10-11  7:14               ` yangerkun
2024-10-10 13:40           ` yangerkun
2024-10-10 14:14             ` Trond Myklebust
2024-10-11  7:08               ` yangerkun
2024-10-11  7:52                 ` yangerkun

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=086eb949-6d07-e5af-da65-e4bccf84dd1a@huaweicloud.com \
    --to=yangerkun@huaweicloud.com \
    --cc=anna.schumaker@oracle.com \
    --cc=anna@kernel.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=trondmy@kernel.org \
    --cc=yangerkun@huawei.com \
    --cc=yi.zhang@huawei.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