lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
Message-ID: <2024071652-CVE-2022-48827-f95b@gregkh>
Date: Tue, 16 Jul 2024 13:46:19 +0200
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: linux-cve-announce@...r.kernel.org
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Subject: CVE-2022-48827: NFSD: Fix the behavior of READ near OFFSET_MAX

Description
===========

In the Linux kernel, the following vulnerability has been resolved:

NFSD: Fix the behavior of READ near OFFSET_MAX

Dan Aloni reports:
> Due to commit 8cfb9015280d ("NFS: Always provide aligned buffers to
> the RPC read layers") on the client, a read of 0xfff is aligned up
> to server rsize of 0x1000.
>
> As a result, in a test where the server has a file of size
> 0x7fffffffffffffff, and the client tries to read from the offset
> 0x7ffffffffffff000, the read causes loff_t overflow in the server
> and it returns an NFS code of EINVAL to the client. The client as
> a result indefinitely retries the request.

The Linux NFS client does not handle NFS?ERR_INVAL, even though all
NFS specifications permit servers to return that status code for a
READ.

Instead of NFS?ERR_INVAL, have out-of-range READ requests succeed
and return a short result. Set the EOF flag in the result to prevent
the client from retrying the READ request. This behavior appears to
be consistent with Solaris NFS servers.

Note that NFSv3 and NFSv4 use u64 offset values on the wire. These
must be converted to loff_t internally before use -- an implicit
type cast is not adequate for this purpose. Otherwise VFS checks
against sb->s_maxbytes do not work properly.

The Linux kernel CVE team has assigned CVE-2022-48827 to this issue.


Affected and fixed versions
===========================

	Fixed in 5.10.220 with commit 1726a39b0879
	Fixed in 5.15.24 with commit c6eff5c42771
	Fixed in 5.16.10 with commit 44502aca8e02
	Fixed in 5.17 with commit 0cb4d23ae08c

Please see https://www.kernel.org for a full list of currently supported
kernel versions by the kernel community.

Unaffected versions might change over time as fixes are backported to
older supported kernel versions.  The official CVE entry at
	https://cve.org/CVERecord/?id=CVE-2022-48827
will be updated if fixes are backported, please check that for the most
up to date information about this issue.


Affected files
==============

The file(s) affected by this issue are:
	fs/nfsd/nfs3proc.c
	fs/nfsd/nfs4proc.c
	fs/nfsd/nfs4xdr.c


Mitigation
==========

The Linux kernel CVE team recommends that you update to the latest
stable kernel version for this, and many other bugfixes.  Individual
changes are never tested alone, but rather are part of a larger kernel
release.  Cherry-picking individual commits is not recommended or
supported by the Linux kernel community at all.  If however, updating to
the latest release is impossible, the individual changes to resolve this
issue can be found at these commits:
	https://git.kernel.org/stable/c/1726a39b0879acfb490b22dca643f26f4f907da9
	https://git.kernel.org/stable/c/c6eff5c4277146a78b4fb8c9b668dd64542c41b0
	https://git.kernel.org/stable/c/44502aca8e02ab32d6b0eb52e006a5ec9402719b
	https://git.kernel.org/stable/c/0cb4d23ae08c48f6bf3c29a8e5c4a74b8388b960

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ