From: yangerkun <yangerkun@huawei.com>
To: <chuck.lever@oracle.com>, <jlayton@kernel.org>
Cc: <linux-nfs@vger.kernel.org>, <yi.zhang@huawei.com>
Subject: Re: Question about CVE-2022-43945
Date: Sat, 12 Nov 2022 17:04:49 +0800 [thread overview]
Message-ID: <265166ff-cd0b-ea5f-ad28-fed756dfd4ff@huawei.com> (raw)
In-Reply-To: <48b858aa-028b-1f56-3740-e59eb7a5fca2@huawei.com>
On 2022/11/12 13:01, yangerkun wrote:
> Hi, Chuck Lever,
>
> CVE-2022-43945(https://nvd.nist.gov/vuln/detail/CVE-2022-43945) describe
> that a normal request header ended with garbage data can trigger the
> nfsd overflow since nfsd share the request and response with the same
> pages array.
>
> It seems that the
> patchset(https://lore.kernel.org/linux-nfs/166204973526.1435.6068003336048840051.stgit@manet.1015granger.net/T/#t)
> has solved NFSv2/NFSv3, but leave NFSv4 still vulnerably?
>
> Another question, for stable branch like lts-5.10, since NFSv2/NFSv3 did
> not switch to xdr_stream, the nfs_request_too_big in nfsd_dispatch will
> reject the request like READ/READDIR with too large request. So it seems
> branch without that "switch" seems ok for NFSv2/NFSv3, but NFSv3 still
> vulnerably. right?
>
> Looking forward to your reply!
Sorry, notice that 76ce4dcec0dc"NFSD: Cap rsize_bop result based on send
buffer size") fix same problem for NFSv4.
So, for the stable branch like lts-5.10 which NFSv2/NFSv3 do not switch
to xdr_stream, it seems we only need 76ce4dcec0dc"NFSD: Cap rsize_bop
result based on send buffer size"). Right?
>
> Thanks,
> Erkun Yang
> .
next prev parent reply other threads:[~2022-11-12 9:04 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-12 5:01 Question about CVE-2022-43945 yangerkun
2022-11-12 9:04 ` yangerkun [this message]
2022-11-12 16:11 ` Chuck Lever III
2023-01-21 14:09 ` Salvatore Bonaccorso
2023-01-22 0:56 ` NeilBrown
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=265166ff-cd0b-ea5f-ad28-fed756dfd4ff@huawei.com \
--to=yangerkun@huawei.com \
--cc=chuck.lever@oracle.com \
--cc=jlayton@kernel.org \
--cc=linux-nfs@vger.kernel.org \
--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