Question about CVE-2022-43945

Question about CVE-2022-43945

[yangerkun]

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

Re: Question about CVE-2022-43945

[yangerkun]

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

Re: Question about CVE-2022-43945

[Chuck Lever III]

> On Nov 12, 2022, at 4:04 AM, yangerkun <yangerkun@huawei.com> wrote:
> 
> 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?

I asked the folks who reported this issue to check NFSv4 as well.
They were not able to exploit NFSv4 in the same way. For now we
believe this vulnerability does not impact the NFSv4 code paths.


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

76ce4dcec0dc is a defensive fix. But, as I stated above, we haven't
yet found that NFSD's NFSv4 implementation is vulnerable to this
issue.


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

At this time we don't believe 76ce4dcec0dc is required. But if
you want it applied to v5.10 (or any LTS kernel) please first
test that it does not result in a regression, and then make a
request to the usual stable maintainers.


--
Chuck Lever

Re: Question about CVE-2022-43945

[Salvatore Bonaccorso]

Hi Chuck, 

On Sat, Nov 12, 2022 at 04:11:47PM +0000, Chuck Lever III wrote:
> 
> 
> > On Nov 12, 2022, at 4:04 AM, yangerkun <yangerkun@huawei.com> wrote:
> > 
> > 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?
> 
> I asked the folks who reported this issue to check NFSv4 as well.
> They were not able to exploit NFSv4 in the same way. For now we
> believe this vulnerability does not impact the NFSv4 code paths.
> 
> 
> >> 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.
> 
> 76ce4dcec0dc is a defensive fix. But, as I stated above, we haven't
> yet found that NFSD's NFSv4 implementation is vulnerable to this
> issue.
> 
> 
> > 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?
> 
> At this time we don't believe 76ce4dcec0dc is required. But if
> you want it applied to v5.10 (or any LTS kernel) please first
> test that it does not result in a regression, and then make a
> request to the usual stable maintainers.

I was reviewing open CVEs for Debian, based on the 5.10.y stable
series, and noticed CVE-2022-43945 is yet unfixed in 5.10.162. I see
SUSE did some backporting, with Neil Brown, according to
https://bugzilla.suse.com/show_bug.cgi?id=1205128#c4 . From the set of
fixes the first two of 

Commit 90bfc37b5ab9 ("SUNRPC: Fix svcxdr_init_decode's end-of-buffer calculation")
Commit 1242a87da0d8 ("SUNRPC: Fix svcxdr_init_encode's buflen calculation")
Commit 00b4492686e0 ("NFSD: Protect against send buffer overflow in NFSv2 READDIR")
Commit 640f87c190e0 ("NFSD: Protect against send buffer overflow in NFSv3 READDIR")
Commit 401bc1f90874 ("NFSD: Protect against send buffer overflow in NFSv2 READ")
Commit fa6be9cc6e80 ("NFSD: Protect against send buffer overflow in NFSv3 READ")
Commit 76ce4dcec0dc ("NFSD: Cap rsize_bop result based on send buffer size")

would not be needed, but still the others, though won't apply cleanly
as thei need substantial changes. Neil, would it be possible to have
the fixes backported to the 5.10.y series as well?

Regards,
Salvatore

Re: Question about CVE-2022-43945

[NeilBrown]

On Sun, 22 Jan 2023, Salvatore Bonaccorso wrote:
> Hi Chuck, 
> 
> On Sat, Nov 12, 2022 at 04:11:47PM +0000, Chuck Lever III wrote:
> > 
> > 
> > > On Nov 12, 2022, at 4:04 AM, yangerkun <yangerkun@huawei.com> wrote:
> > > 
> > > 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?
> > 
> > I asked the folks who reported this issue to check NFSv4 as well.
> > They were not able to exploit NFSv4 in the same way. For now we
> > believe this vulnerability does not impact the NFSv4 code paths.
> > 
> > 
> > >> 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.
> > 
> > 76ce4dcec0dc is a defensive fix. But, as I stated above, we haven't
> > yet found that NFSD's NFSv4 implementation is vulnerable to this
> > issue.
> > 
> > 
> > > 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?
> > 
> > At this time we don't believe 76ce4dcec0dc is required. But if
> > you want it applied to v5.10 (or any LTS kernel) please first
> > test that it does not result in a regression, and then make a
> > request to the usual stable maintainers.
> 
> I was reviewing open CVEs for Debian, based on the 5.10.y stable
> series, and noticed CVE-2022-43945 is yet unfixed in 5.10.162. I see
> SUSE did some backporting, with Neil Brown, according to
> https://bugzilla.suse.com/show_bug.cgi?id=1205128#c4 . From the set of
> fixes the first two of 
> 
> Commit 90bfc37b5ab9 ("SUNRPC: Fix svcxdr_init_decode's end-of-buffer calculation")
> Commit 1242a87da0d8 ("SUNRPC: Fix svcxdr_init_encode's buflen calculation")
> Commit 00b4492686e0 ("NFSD: Protect against send buffer overflow in NFSv2 READDIR")
> Commit 640f87c190e0 ("NFSD: Protect against send buffer overflow in NFSv3 READDIR")
> Commit 401bc1f90874 ("NFSD: Protect against send buffer overflow in NFSv2 READ")
> Commit fa6be9cc6e80 ("NFSD: Protect against send buffer overflow in NFSv3 READ")
> Commit 76ce4dcec0dc ("NFSD: Cap rsize_bop result based on send buffer size")
> 
> would not be needed, but still the others, though won't apply cleanly
> as thei need substantial changes. Neil, would it be possible to have
> the fixes backported to the 5.10.y series as well?

You can find my 5.3 patches at
  https://github.com/SUSE/kernel-source/commit/e93318a3f8b5618afcda871b6d8201466af333a8
and earlier - follow the "parent" link.

Feel free to check they apply to 5.10.y, review them, and forward to
stable@vger.kernel.org.

NeilBrown

> 
> Regards,
> Salvatore
>