]> CyberLeo.Net >> Repos - FreeBSD/FreeBSD.git/commit
Reject streams that set ->drr_payloadlen to unreasonably large values
authorRichard Yao <richard.yao@alumni.stonybrook.edu>
Mon, 23 Jan 2023 21:16:22 +0000 (16:16 -0500)
committerGitHub <noreply@github.com>
Mon, 23 Jan 2023 21:16:22 +0000 (13:16 -0800)
commit73968defdd0f85489ca97c4c75522bad704a74e9
treef6a9e1b6d2822d8d8ebdedf1ac15bb7abe189b02
parent69f024a56e25e9d1a220f9fa35e46c235aa5bf03
Reject streams that set ->drr_payloadlen to unreasonably large values

In the zstream code, Coverity reported:

"The argument could be controlled by an attacker, who could invoke the
function with arbitrary values (for example, a very high or negative
buffer size)."

It did not report this in the kernel. This is likely because the
userspace code stored this in an int before passing it into the
allocator, while the kernel code stored it in a uint32_t.

However, this did reveal a potentially real problem. On 32-bit systems
and systems with only 4GB of physical memory or less in general, it is
possible to pass a large enough value that the system will hang. Even
worse, on Linux systems, the kernel memory allocator is not able to
support allocations up to the maximum 4GB allocation size that this
allows.

This had already been limited in userspace to 64MB by
`ZFS_SENDRECV_MAX_NVLIST`, but we need a hard limit in the kernel to
protect systems. After some discussion, we settle on 256MB as a hard
upper limit. Attempting to receive a stream that requires more memory
than that will result in E2BIG being returned to user space.

Reported-by: Coverity (CID-1529836)
Reported-by: Coverity (CID-1529837)
Reported-by: Coverity (CID-1529838)
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Richard Yao <richard.yao@alumni.stonybrook.edu>
Closes #14285
cmd/zstream/zstream_decompress.c
cmd/zstream/zstream_recompress.c
cmd/zstream/zstream_redup.c
lib/libzfs/libzfs_sendrecv.c
module/zfs/dmu_recv.c