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;
To:     <chuck.lever@oracle.com>, <jlayton@kernel.org>
CC:     <linux-nfs@vger.kernel.org>, <yi.zhang@huawei.com>,
        <yangerkun@huawei.com>
From:   yangerkun <yangerkun@huawei.com>
Subject: Question about CVE-2022-43945
Message-ID: <48b858aa-028b-1f56-3740-e59eb7a5fca2@huawei.com>
Date:   Sat, 12 Nov 2022 13:01:44 +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
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Precedence: bulk

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!

Thanks,
Erkun Yang