A signal handler in sshd(8) may call a logging function that is not async-signal-safe. The signal handler is invoked when a client does not authenticate within the LoginGraceTime seconds (120 by default). This signal handler executes in the context of the sshd(8)'s privileged code, which is not sandboxed and runs with full root privileges.
This issue is another instance of the problem in CVE-2024-6387 addressed by FreeBSD-SA-24:04.openssh. The faulty code in this case is from the integration of blacklistd in OpenSSH in FreeBSD.
As a result of calling functions that are not async-signal-safe in the privileged sshd(8) context, a race condition exists that a determined attacker may be able to exploit to allow an unauthenticated remote code execution as root.
When mounting a remote filesystem using NFS, the kernel did not sanitize remotely provided filenames for the path separator character, "/". This allows readdir(3) and related functions to return filesystem entries with names containing additional path components.
The lack of validation described above gives rise to a confused deputy problem. For example, a program copying files from an NFS mount could be tricked into copying from outside the intended source directory, and/or to a location outside the intended destination directory.
A logic bug in the code which disables kernel tracing for setuid programs meant that tracing was not disabled when it should have, allowing unprivileged users to trace and inspect the behavior of setuid programs.
The bug may be used by an unprivileged user to read the contents of files to which they would not otherwise have access, such as the local password database.
A particular case of memory sharing is mishandled in the virtual memory system. This is very similar to SA-21:08.vm, but with a different root cause.
An unprivileged local user process can maintain a mapping of a page after it is freed, allowing that process to read private data belonging to other processes or the kernel.
`bhyveload -h <host-path>` may be used to grant loader access to the <host-path> directory tree on the host. Affected versions of bhyveload(8) do not make any attempt to restrict loader's access to <host-path>, allowing the loader to read any file the host user has access to. In the bhyveload(8) model, the host supplies a userboot.so to boot with, but the loader scripts generally come from the guest image. A maliciously crafted script could be used to exfiltrate sensitive data from the host accessible to the user running bhyhveload(8), which is often the system root.
The jail(2) system call has not limited a visiblity of allocated TTYs (the kern.ttys sysctl). This gives rise to an information leak about processes outside the current jail.
Attacker can get information about TTYs allocated on the host or in other jails. Effectively, the information printed by "pstat -t" may be leaked.
A user-provided integer option was passed to nmreq_copyin() without checking if it would overflow. This insufficient bounds checking could lead to kernel memory corruption.
On systems configured to include netmap in their devfs_ruleset, a privileged process running in a jail can affect the host environment.
Handlers for *_CFG_PAGE read / write ioctls in the mpr, mps, and mpt drivers allocated a buffer of a caller-specified size, but copied to it a fixed size header. Other heap content would be overwritten if the specified size was too small.
Users with access to the mpr, mps or mpt device node may overwrite heap data, potentially resulting in privilege escalation. Note that the device node is only accessible to root and members of the operator group.
The e1000 network adapters permit a variety of modifications to an Ethernet packet when it is being transmitted. These include the insertion of IP and TCP checksums, insertion of an Ethernet VLAN header, and TCP segmentation offload ("TSO"). The e1000 device model uses an on-stack buffer to generate the modified packet header when simulating these modifications on transmitted packets.
When checksum offload is requested for a transmitted packet, the e1000 device model used a guest-provided value to specify the checksum offset in the on-stack buffer. The offset was not validated for certain packet types.
A misbehaving bhyve guest could overwrite memory in the bhyve process on the host, possibly leading to code execution in the host context.
The bhyve process runs in a Capsicum sandbox, which (depending on the FreeBSD version and bhyve configuration) limits the impact of exploiting this issue.
The 802.11 beacon handling routine failed to validate the length of an IEEE 802.11s Mesh ID before copying it to a heap-allocated buffer.
While a FreeBSD Wi-Fi client is in scanning mode (i.e., not associated with a SSID) a malicious beacon frame may overwrite kernel memory, leading to remote code execution.