An operator precedence bug in the kernel results in a scenario where a buffer overflow causes attacker-controlled data to overwrite adjacent execve(2) argument buffers.
The bug may be exploitable by an unprivileged user to obtain superuser privileges.
The BOOTP file field is written to the lease file without escaping embedded double-quotes, allowing injection of arbitrary dhclient.conf directives. When the lease file is subsequently re-parsed by dhclient, e.g., after a system restart, an attacker-controlled field from the lease is passed to dhclient-script(8), which evaluates it.
A rogue DHCP server may be able to execute arbirary code as root on a system running dhclient.
Incorrect packet validation allowed unbounded recursion parsing SCTP chunk parameters. This can eventually result in a stack overflow and panic.
Remote attackers can craft packets which cause affected systems to panic. This affects any system where pf is configured to process traffic, independent of the configured ruleset.
As dhclient is building an environment to pass to dhclient-script, it may need to resize the array of string pointers. The code which expands the array incorrectly calculates its new size when requesting memory, resulting in a heap buffer overrun.
A specially crafted packet can cause dhclient to overrun its buffer of environment entries. This can result in a crash, but it may be possible to leverage this bug to achieve remote code execution.
When exchanging data over a socket, libnv uses select(2) to wait for data to arrive. However, it does not verify whether the provided socket descriptor fits in select(2)'s file descriptor set size limit of FDSETSIZE (1024).
An attacker who is able to force a libnv application to allocate large file descriptors, e.g., by opening many descriptors and executing a program which is not careful to close them upon startup, can trigger stack corruption. If the target application is setuid-root, then this could be used to elevate local privileges.
When processing the header of an incoming message, libnv failed to properly validate the message size.
The lack of validation allows a malicious program to write outside the bounds of a heap allocation. This can trigger a crash or system panic, and it may be possible for an unprivileged user to exploit the bug to elevate their privileges.
The ZFSIOCUSERSPACEMANY ioctl, used by zfs-userspace(8), truncated a 64-bit output buffer size to a 32-bit integer for the kernel allocation, but used the original 64-bit size as the buffer limit when writing records.
A local user with the "userused" delegated ZFS permission can trigger a kernel heap overflow via the ZFSIOCUSERSPACEMANY ioctl, potentially escalating privileges.
The ZFSIOCSETPROP ioctl, used by zfs-set(8), incorrectly validated the calling user such that an unprivileged user is able to set metadata on a dataset indicating that the dataset has received properties from a zfs-recv(8) stream.
Any local user can set the internal ZFS metadata flag "$hasrecvd" on datasets via ZFSIOCSETPROP.
The ZFSIOCRECVNEW ioctl, in the heal receive path, similarly truncated a 64-bit payload size to a 32-bit integer for allocation, then used the original 64-bit size as the length for a byteswap operation.
A local user with the "receive" delegated ZFS permission can trigger kernel memory corruption via ZFSIOCRECVNEW by sending a crafted receive stream in heal mode.
The RTSP handler in libalias rewrote outgoing packets into a fixed-length stack buffer without checking whether the rewritten data fit in the buffer, or whether the result fit back in the original packet.
A host sending crafted RTSP traffic from inside a NAT gateway using libalias can overflow a stack buffer, potentially achieving remote code execution in the kernel (when using ipfw(4) NAT) or in the natd(8) process (which generally runs as the root user).
The RACK setsockopt(2) handler drops the connection lock in order to copy option data from userspace, then reacquires the lock. After reacquiring, it verifies that the TCP stack had not been switched away, but did not reload its pointer to the stack's per-connection control block. If userspace switches stacks twice during this window, the check will succeed but the saved pointer will refer to freed memory.
The bug may be exploitable by an unprivileged local user to escalate privileges.
The kernel function that implements unlinkat(2) and funlinkat(2) validated the ATRESOLVEBENEATH flag but failed to pass it through to the underlying path lookup. The flag was silently dropped, so path resolution was not actually restricted.
A process that uses ATRESOLVEBENEATH with unlinkat(2) or funlinkat(2) to confine path resolution can in fact resolve paths above the starting directory. A caller relying on this flag for path containment may delete files outside the intended directory tree.
Pages belonging to largepage shared memory objects were not explicitly wired. When sendfile(2) transmitted such an object with the SFNOCACHE flag, it freed the underlying pages after transmission even though existing mappings still referred to them.
An unprivileged local user can abuse the bug to access freed kernel memory. This can be exploited to escalate privileges.
Certain system calls, such open(2) with the OTRUNC flag set, and fspacectl(2), could incorrectly free memory in largepage objects. These operations are not permitted on largepage objects, but the implementation did not verify this.
An unprivileged local user can abuse the bug to access freed kernel memory. This can be exploited to escalate privileges.
When auditing a system call executed via ptrace(PTSCREMOTE), the kernel passed the return value of an internal setup function to AUDITSYSCALLEXIT() rather than the actual result of the executed system call. As a result, committed audit records for system calls which returned an error do not reflect the true outcome of the operation. That is, they indicate that the operation succeeded when it in fact failed.
Audit records for system calls executed via ptrace(PTSCREMOTE) may show an incorrect error status. An attacker with the ability to debug a process could use this to produce misleading audit trails, potentially undermining audit-based Intrusion Detection Systems (IDS).
When building the iovec array for a received TLS 1.2 CBC record, ktlsocftlscbcdecrypt() incremented the iovec index for every mbuf in the chain, including mbufs that were skipped because they contained only TLS header bytes. This left uninitialized entries in the iovec array. The iovec array was allocated without zeroing.
A remote TLS peer can cause the kernel to read from uninitialized iovec entries during HMAC computation, resulting in a kernel panic. The peer must be able to control TCP segmentation such that the first mbuf of a CBC record contains only the 5-byte TLS record header.
When msync(MSINVALIDATE) is called on a mapping of an unmanaged device object, the physical pages in the mapping range are marked invalid but remain in the pager's page list. A subsequent page fault will cause the fault handler to re-insert the page into the object's list. This corrupts the list, and on object destruction the page is freed twice.
An unprivileged local user with access to a device that provides memory-mapped I/O can trigger a use-after-free in the kernel, though this is limited to a pool of objects ("fictitious pages") that are never recycled for a different purpose. It may be possible to exploit this to escalate privileges.
During execve(2) of a SUID binary, the new virtual address space is installed before the process credentials are updated. During this window, a process running as the same user can access the target process's memory via procfs or linprocfs, because the kernel's debugging permission check still saw the original credentials.
An unprivileged local user can exploit this race to modify the address space of a SUID binary before its credentials are elevated, potentially gaining full control of the affected system.
When the JAILATDESC flag is specified, kernjailset() and kernjailget() released the reference to the caller's current prison before looking up the jail descriptor. If the descriptor lookup failed, error-handling paths released the same reference a second time.
An unprivileged local user can trigger a prison reference count underflow, which may cause the prison structure to be freed while still in use. When this is done on the jail host, the bug will generally result in an immediate panic. However, if the user is running in a jail, then it may be possible to exploit the bug to elevate privileges.
When fdescfs(4) was mounted in a jail with the "nodup" option, opening /dev/fd/N returned a descriptor that did not inherit FDRESOLVEBENEATH or the Capsicum capability rights of descriptor N.
A process in a jail that has received a directory file descriptor from another jail can use these techniques to escape the jail's filesystem root restriction.
SCMRIGHTS file descriptor passing did not preserve FDRESOLVEBENEATH when a descriptor was transferred. A process could clear the restriction by sending the descriptor to itself over a Unix domain socket.
A process in a jail that has received a directory file descriptor from another jail can use these techniques to escape the jail's filesystem root restriction.
renameat(2) did not enforce FDRESOLVEBENEATH on its directory arguments. A jailed process could rename a directory relative to a restricted descriptor, then escape the jail root via fchdir(2). This requires the directory to reside on a filesystem that is also reachable from the jail's root.
A process in a jail that has received a directory file descriptor from another jail can use these techniques to escape the jail's filesystem root restriction.
The IPv6 UDP send path for unconnected sockets did not apply the jail policy of rewriting a loopback destination address to the jail's primary IPv6 address.
A process in a classic (non-VNET) jail can send UDP datagrams to services listening on the host's IPv6 loopback address, bypassing jail network isolation.
TLS 1.3 embeds the actual record type as the last non-zero byte of the decrypted payload, optionally followed by zero padding. The code which searches for the inner record type had an off-by-one bug which could be triggered by an invalid frame, leading to an underflow followed by an unconditional NULL pointer dereference, causing a kernel panic.
A remote TLS 1.3 peer can send a specially crafted record to trigger a kernel panic, resulting in a Denial of Service (DoS).
When semop(2) blocks waiting for a semaphore condition, it releases the per-set lock and sleeps. Upon waking, it checks the sequence number embedded in the semaphore set's IPC identifier to detect whether the set was removed while the caller was asleep. This sequence number is only 15 bits wide. If enough semaphore sets are created and destroyed in the same table slot while a caller is blocked, the counter wraps around, and semop(2) may falsely conclude that the original set still exists. The subsequent access to a semaphore within the set may then be out of bounds.
An unprivileged local user can trigger an out-of-bounds access on kernel heap memory, potentially leading to privilege escalation.
When a process calls execve(2) to execute a setuid or setgid image, hwpmc(4) is supposed to detach PMCs owned by unprivileged processes. An inverted check meant that this scenario was not handled properly.
An unprivileged local user who has attached PMCs to a process can continue monitoring it after the process executes a setuid or setgid binary, contrary to the intended policy.
The SOCKSTREAM receive path in the unix socket implementation failed to fully detach control messages from the socket buffer before processing them. Some error paths would free those messages, leaving freed data mbufs in the receive socket buffer.
An unprivileged local user can exploit this use-after-free to escalate privileges.
The implementation of this ioctl attempts to acquire locks on all channels in a sync group. If locking a channel would block, it releases the sync group list lock and sleeps. Upon reawakening, it is possible that the sync group structure is freed, but the implementation did not handle this possibility.
On a system with a multiple audio devices, an unprivileged local user can exploit this use-after-free to escalate privileges.
In FreeBSD 15.0, the kernel structure used to represent user credentials changed: previously the primary group ID was stored in the first element of the array containing the list of supplementary group IDs, whereas now the primary group ID is stored in a dedicated field. This change was largely internal to the kernel and not user-visible.
One function, groupisprimary(), was not properly updated as a part of this transition. This function is used by macdo to determine the primary group ID of the credential after applying a transition rule, used when the rule target does not explicitly specify a group.
As a result, with certain macdo rules, it is possible for a credential switch to incorrectly set the primary group ID to the ID stored in the first element of the original credential's supplementary group array.
If the list of supplementary groups is empty, this value will be 0, corresponding to the "wheel" group. For example, a rule such as "uid=1001>uid=1002" can be abused to set the primary group ID to 0 even if the process did not originally belong to group 0.
Certain macdo rules can be abused to set a process' group ID to 0. Note however, that the rule must apply to the caller in order for the bug to be triggered, e.g., given the ruleset "uid=1001>uid=1002", the user must have user ID 1001 in order to trigger the bug.
Further, logged-in users will in general have a non-empty supplementary group list, in which case the bug can at worst be used to set the credential's first supplementary group ID as its primary group ID. Processes must explicitly remove themselves from all supplementary groups, using the privileged setgroups(2) system call, in order to exploit the bug to set 0 as the primary group ID.
Since membership in group 0 is often used to enable controlled privilege escalation, the bug might be further exploitable to obtain root privileges, depending on the system configuration. For instance, a ruleset such as the following could be exploited by a process running as user 1001 and with an empty supplementary group list: "uid=1001>uid=1002;gid=0>uid=0".
The TIOCSCTTY ioctl handler drops the tty lock in order to acquire the process tree lock. After reacquiring the tty lock, the handler did not revalidate the state of the terminal, and could proceed to link a terminal that was concurrently being destroyed to the calling process' session.
An unprivileged local user can exploit this race condition to escalate privileges.