2024-09-08 FreeBSD security patches #2219
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Ensure that the calculation of size of array doesn't overflow. Security: FreeBSD-24:09.libnv Security: CVE-2024-45287 Security: CAP-02 Reported by: Synacktiv Reported by: Taylor R Campbell (NetBSD) Sponsored by: The Alpha-Omega Project Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D46131 (cherry picked from commit 36fa90dbde0060aacb5677d0b113ee168e839071)
During unpacking, we ensure that we do not read beyond the declared size. However, unpack uses a function that copies null-terminated strings. Prior to this commit, if the last string was not null-terminated, it could result in copying data into a buffer smaller than the allocated size. Security: FreeBSD-24:09.libnv Security: CVE-2024-45288 Security: CAP-03 Reported by: Synacktiv Sponsored by: The Alpha-Omega Project Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D46138 (cherry picked from commit 3aaaca1b51ad844ef9e9b3d945217ab3dd189bae)
The function tpm_ppi_mem_handler is vulnerable to buffer over-read and over-write, the MMIO handler serves the heap allocated structure tpm_ppi_qemu. The issue is that the structure size is smaller than 0x1000 and the handler does not validate the offset and size (sizeof is 0x15A while the handler allows up to 0x1000 bytes) Reported by: Synacktiv Reviewed by: corvink Security: FreeBSD-SA-24:10.bhyve Security: CVE-2024-41928 Security: HYP-01 Sponsored by: The Alpha-Omega Project Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D45980 (cherry picked from commit a06fc21e770a482c8915411ebc98c870e42dd29b)
The virtio_scsi device allows a guest VM to directly send SCSI commands to the kernel driver exposed on /dev/cam/ctl. This setup makes the vulnerability directly accessible from VMs through the pci_virtio_scsi bhyve device. The function ctl_write_buffer sets the CTL_FLAG_ALLOCATED flag, causing the kern_data_ptr to be freed when the command finishes processing. However, the buffer is still stored in lun->write_buffer, leading to a Use-After-Free vulnerability. Since the buffer needs to persist indefinitely, so it can be accessed by READ BUFFER, do not set CTL_FLAG_ALLOCATED. Reported by: Synacktiv Reviewed by: Pierre Pronchery <pierre@freebsdfoundation.org> Reviewed by: jhb Security: FreeBSD-SA-24:11.ctl Security: CVE-2024-45063 Security: HYP-03 Sponsored by: Axcient Sponsored by: The Alpha-Omega Project Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D46424 (cherry picked from commit 670b582db6cb827a8760df942ed8af0020a0b4d0)
The functions ctl_write_buffer() and ctl_read_buffer() are vulnerable to a kernel memory disclosure caused by an uninitialized kernel allocation. If one of these functions is called for the first time for a given LUN, a kernel allocation is performed without the M_ZERO flag. Then a call to ctl_read_buffer() returns the content of this allocation, which may contain kernel data. Reported by: Synacktiv Reviewed by: asomers Reviewed by: jhb Security: FreeBSD-SA-24:11.ctl Security: CVE-2024-8178 Security: HYP-05 Sponsored by: The Alpha-Omega Project Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D45952 (cherry picked from commit ea44766b78d639d3a89afd5302ec6feffaade813)
This vulnerability is directly accessible to a guest VM through the pci_virtio_scsi bhyve device. In the function ctl_report_supported_opcodes() accessible from the VM, the option RSO_OPTIONS_OC_ASA does not check the requested service_action value before accessing &ctl_cmd_table[]. Reported by: Synacktiv Reviewed by: asomers Security: FreeBSD-SA-24:11.ctl Security: CVE-2024-42416 Security: HYP-06 Sponsored by: The Alpha-Omega Project Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D46027 (cherry picked from commit af438acbfde3d25dbdc82b2b3d72380f0191e9d9)
Previously 3 bytes of data from the heap could be leaked to ctl consumers. Reported by: Synacktiv Reviewed by: asomers, mav Sponsored by: The Alpha-Omega Project Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D46091 (cherry picked from commit db87c98168b1605f067d283fa36a710369c3849d)
The function pci_xhci_find_stream validates that the streamid is valid but the bound check accepts up to ep_MaxPStreams included. The bug results in an out-of-bounds write on the heap with controlled data. Reported by: Synacktiv Reviewed by: jhb Security: FreeBSD-SA-24:12.bhyve Security: CVE-2024-32668 Security: HYP-04 Sponsored by: The Alpha-Omega Project Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D45994 (cherry picked from commit 5c9308a4130858598c76f3ae6e3e3dfb41ccfe68)
The incorrectly typed data is read only, used in a compare operation, so neither remote code execution, nor memory content disclosure were possible. However, applications performing certificate name checks were vulnerable to denial of service. The GENERAL_TYPE data type is a union, and we must take care to access the correct member, based on `gen->type`, not all the member fields have the same structure, and a segfault is possible if the wrong member field is read. The code in question was lightly refactored with the intent to make it more obviously correct. Security: CVE-2024-6119 Obtained from: OpenSSL Project (cherry picked from commit 1486960d6cdb052e4fc0109a56a0597b4e902ba1) (cherry picked from commit 5946b0c6cbc77e6c5f62f5f7e635c6036e14f4d0)
...into the only USHMF_LINKED, as they are always set or unset together. This is both to stop giving the impression that they can be set/unset independently, which they can't with the current code, and to make it clearer that an upcoming reference counting fix is correct. Reviewed by: kib Approved by: emaste (mentor) Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D46126 (cherry picked from commit dd83da532c36830a0c0aac624903849262ec6f68)
…eference umtx_shm_unref_reg_locked() would unconditionally drop the "registry" reference, tied to USHMF_LINKED. This is not a problem for caller umtx_shm_object_terminated(), which operates under the 'umtx_shm_lock' lock end-to-end, but it is for indirect caller umtx_shm(), which drops the lock between umtx_shm_find_reg() and the call to umtx_shm_unref_reg(true) that deregisters the umtx shared region (from 'umtx_shm_registry'; umtx_shm_find_reg() only finds registered shared mutexes). Thus, two concurrent user-space callers of _umtx_op() with UMTX_OP_SHM and flags UMTX_SHM_DESTROY, both progressing past umtx_shm_find_reg() but before umtx_shm_unref_reg(true), would then decrease twice the reference count for the single reference standing for the shared mutex's registration. Reported by: Synacktiv Reviewed by: kib Approved by: emaste (mentor) Security: FreeBSD-SA-24:14.umtx Security: CVE-2024-43102 Security: CAP-01 Sponsored by: The Alpha-Omega Project Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D46126 (cherry picked from commit 62f40433ab47ad4a9694a22a0313d57661502ca1)
This hardens against provoked use-after-free occurences should there be reference counting leaks in the future (which is currently not the case). At the deepest level, umtx_shm_find_reg_unlocked() now returns EOVERFLOW when it cannot grant an additional reference to the registry object, and so will umtx_shm_find_reg(). umtx_shm_create_reg() will fail if calling umtx_shm_find_reg() returns EOVERFLOW (meaning a SHM object for the passed key already exists, but we can't acquire another reference on it), avoiding the creation of a duplicate registry entry for a given key (this wouldn't pose problem for the rest of the code in its current form, but is expressly avoided for intelligibility and hardening purposes). Since umtx_shm_find_reg*(), and consequently the whole _umtx_op() system call, can only return EOVERFLOW on such a bug manifesting, we don't document that return value. Reviewed by: kib, emaste Approved by: emaste (mentor) Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D46126 (cherry picked from commit c3e6dfe55c0e81d0717b0458bc95128384c3ebe8)
'ushm_refcnt' is unsigned. Don't leave the impression it isn't. No functional change (intended). Reviewed by: kib Approved by: emaste (mentor) Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D46126 (cherry picked from commit c75a18905e308f69b01f19c3d7d613883a008e79)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes for: