mirror of
https://git.proxmox.com/git/mirror_zfs.git
synced 2024-12-26 03:09:34 +03:00
73968defdd
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 |
||
|---|---|---|
| .. | ||
| os | ||
| .gitignore | ||
| libzfs_changelist.c | ||
| libzfs_config.c | ||
| libzfs_crypto.c | ||
| libzfs_dataset.c | ||
| libzfs_diff.c | ||
| libzfs_impl.h | ||
| libzfs_import.c | ||
| libzfs_iter.c | ||
| libzfs_mount.c | ||
| libzfs_pool.c | ||
| libzfs_sendrecv.c | ||
| libzfs_status.c | ||
| libzfs_util.c | ||
| libzfs.abi | ||
| libzfs.pc.in | ||
| libzfs.suppr | ||
| Makefile.am | ||
| THIRDPARTYLICENSE.openssl | ||
| THIRDPARTYLICENSE.openssl.descrip | ||