Linux NFS development
 help / color / mirror / Atom feed
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
> .

  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