Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Subject: Re: Question about CVE-2022-43945
To:     <chuck.lever@oracle.com>, <jlayton@kernel.org>
CC:     <linux-nfs@vger.kernel.org>, <yi.zhang@huawei.com>
References: <48b858aa-028b-1f56-3740-e59eb7a5fca2@huawei.com>
From:   yangerkun <yangerkun@huawei.com>
Message-ID: <265166ff-cd0b-ea5f-ad28-fed756dfd4ff@huawei.com>
Date:   Sat, 12 Nov 2022 17:04:49 +0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
 Thunderbird/78.5.0
MIME-Version: 1.0
In-Reply-To: <48b858aa-028b-1f56-3740-e59eb7a5fca2@huawei.com>
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Precedence: bulk


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
> .