From: Chuck Lever <chuck.lever@oracle.com>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Li Lingfeng <lilingfeng3@huawei.com>
Cc: cve@kernel.org, linux-kernel@vger.kernel.org,
linux-cve-announce@vger.kernel.org,
"linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>,
Olga Kornievskaia <okorniev@redhat.com>,
Jeff Layton <jlayton@kernel.org>, NeilBrown <neilb@suse.de>,
yangerkun <yangerkun@huawei.com>,
"zhangyi (F)" <yi.zhang@huawei.com>, Hou Tao <houtao1@huawei.com>,
"yukuai (C)" <yukuai3@huawei.com>,
"chengzhihao1@huawei.com" <chengzhihao1@huawei.com>,
ZhangXiaoxu <zhangxiaoxu5@huawei.com>
Subject: Re: CVE-2024-50106: nfsd: fix race between laundromat and free_stateid
Date: Tue, 17 Dec 2024 20:55:20 -0500 [thread overview]
Message-ID: <e6bc81ec-4536-44e4-983a-28b8bc0f3979@oracle.com> (raw)
In-Reply-To: <2024121713-reproduce-rippling-73cc@gregkh>
On 12/17/24 10:59 AM, Greg Kroah-Hartman wrote:
> On Tue, Dec 17, 2024 at 11:30:41PM +0800, Li Lingfeng wrote:
>> Hi,
>> after analysis, we think that this issue is not introduced by commit
>> 2d4a532d385f ("nfsd: ensure that clp->cl_revoked list is protected by
>> clp->cl_lock") but by commit 83e733161fde ("nfsd: avoid race after
>> unhash_delegation_locked()").
>> Therefore, kernel versions earlier than 6.9 do not involve this issue.
>>
>> // normal case 1 -- free deleg by delegreturn
>> 1) OP_DELEGRETURN
>> nfsd4_delegreturn
>> nfsd4_lookup_stateid
>> destroy_delegation
>> destroy_unhashed_deleg
>> nfs4_unlock_deleg_lease
>> vfs_setlease // unlock
>> nfs4_put_stid // put last refcount
>> idr_remove // remove from cl_stateids
>> s->sc_free // free deleg
>>
>> 2) OP_FREE_STATEID
>> nfsd4_free_stateid
>> find_stateid_locked // can not find the deleg in cl_stateids
>>
>>
>> // normal case 2 -- free deleg by laundromat
>> nfs4_laundromat
>> state_expired
>> unhash_delegation_locked // set NFS4_REVOKED_DELEG_STID
>> list_add // add the deleg to reaplist
>> list_first_entry // get the deleg from reaplist
>> revoke_delegation
>> destroy_unhashed_deleg
>> nfs4_unlock_deleg_lease
>> nfs4_put_stid
>>
>>
>> // abnormal case
>> nfs4_laundromat
>> state_expired
>> unhash_delegation_locked
>> // set NFS4_REVOKED_DELEG_STID
>> list_add
>> // add the deleg to reaplist
>> 1) OP_DELEGRETURN
>> nfsd4_delegreturn
>> nfsd4_lookup_stateid
>> nfsd4_stid_check_stateid_generation
>> nfsd4_verify_open_stid
>> // check NFS4_REVOKED_DELEG_STID
>> // and return nfserr_deleg_revoked
>> // skip destroy_delegation
>>
>> 2) OP_FREE_STATEID
>> nfsd4_free_stateid
>> // check NFS4_REVOKED_DELEG_STID
>> list_del_init
>> // remove deleg from reaplist
>> nfs4_put_stid
>> // free deleg
>> list_first_entry
>> // cant not get the deleg from reaplist
>>
>>
>> Before commit 83e733161fde ("nfsd: avoid race after
>> unhash_delegation_locked()"), nfs4_laundromat --> unhash_delegation_locked
>> would not set NFS4_REVOKED_DELEG_STID for the deleg.
>> So the description "it marks the delegation stid revoked" in the CVE fix
>> patch does not hold true. And the OP_FREE_STATEID operation will not
>> release the deleg.
>
> Thanks for the research. If the maintainers involved agree, we'll be
> glad to add a .vulnerable file to our git repo and regenerate the json
> entry to reflect this starting point for the issue.
Hi Greg,
As mentioned earlier, our reviewers felt that this bug would indeed be
difficult or impossible to reproduce before 83e733161fde, and there
have been no reports of similar crash symptoms in kernels before v6.9.
No objection to updating the CVE to reflect that.
--
Chuck Lever
next prev parent reply other threads:[~2024-12-18 1:55 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <2024110553-CVE-2024-50106-c095@gregkh>
2024-12-17 15:30 ` CVE-2024-50106: nfsd: fix race between laundromat and free_stateid Li Lingfeng
2024-12-17 15:59 ` Greg Kroah-Hartman
2024-12-18 1:55 ` Chuck Lever [this message]
2025-01-06 16:27 ` Greg Kroah-Hartman
2024-12-17 18:25 ` Chuck Lever
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=e6bc81ec-4536-44e4-983a-28b8bc0f3979@oracle.com \
--to=chuck.lever@oracle.com \
--cc=chengzhihao1@huawei.com \
--cc=cve@kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=houtao1@huawei.com \
--cc=jlayton@kernel.org \
--cc=lilingfeng3@huawei.com \
--cc=linux-cve-announce@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=neilb@suse.de \
--cc=okorniev@redhat.com \
--cc=yangerkun@huawei.com \
--cc=yi.zhang@huawei.com \
--cc=yukuai3@huawei.com \
--cc=zhangxiaoxu5@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