In pf packet processing with a 'scrub fragment reassemble' rule, a packet containing multiple IPv6 fragment headers would be reassembled, and then immediately processed. That is, a packet with multiple fragment extension headers would not be recognized as the correct ultimate payload. Instead a packet with multiple IPv6 fragment headers would unexpectedly be interpreted as a fragmented packet, rather than as whatever the real payload is. As a result, IPv6 fragments may bypass pf firewall rules written on the assumption all fragments have been reassembled and, as a result, be forwarded or processed by the host.

The fwctl driver implements a state machine which is executed when a bhyve guest accesses certain x86 I/O ports. The interface lets the guest copy a string into a buffer resident in the bhyve process' memory. A bug in the state machine implementation can result in a buffer overflowing when copying this string. Malicious, privileged software running in a guest VM can exploit the buffer overflow to achieve code execution on the host in the bhyve userspace process, which typically runs as root, mitigated by the capabilities assigned through the Capsicum sandbox available to the bhyve process.

A set of carefully crafted ipv6 packets can trigger an integer overflow in the calculation of a fragment reassembled packet's payload length field. This allows an attacker to trigger a kernel panic, resulting in a denial of service.

pam_krb5 authenticates a user by essentially running kinit with the password, getting a ticket-granting ticket (tgt) from the Kerberos KDC (Key Distribution Center) over the network, as a way to verify the password. However, if a keytab is not provisioned on the system, pam_krb5 has no way to validate the response from the KDC, and essentially trusts the tgt provided over the network as being valid. In a non-default FreeBSD installation that leverages pam_krb5 for authentication and does not have a keytab provisioned, an attacker that is able to control both the password and the KDC responses can return a valid tgt, allowing authentication to occur for any user on the system.

When GELI reads a key file from standard input, it does not reuse the key file to initialize multiple providers at once resulting in the second and subsequent devices silently using a NULL key as the user key file. If a user only uses a key file without a user passphrase, the master key is encrypted with an empty key file allowing trivial recovery of the master key.

sys/netinet/tcp_timer.h in FreeBSD before 7.0 contains a denial-of-service (DoS) vulnerability due to improper handling of TSopt on TCP connections. NOTE: This vulnerability only affects products that are no longer supported by the maintainer

In FreeBSD 13.0-STABLE before n247428-9352de39c3dc, 12.2-STABLE before r370674, 13.0-RELEASE before p6, and 12.2-RELEASE before p12, certain conditions involving use of the highlight buffer while text is scrolling on the console, console data may overwrite data structures associated with the system console or other kernel memory.

FreeBSD's crontab calculates the MD5 sum of the previous and new cronjob to determine if any changes have been made before copying the new version in. In particular, it uses the MD5File() function, which takes a pathname as an argument, and is called with euid 0. A race condition in this process may lead to an arbitrary MD5 comparison regardless of the read permissions.

In FreeBSD 13.0-STABLE before n246938-0729ba2f49c9, 12.2-STABLE before r370383, 11.4-STABLE before r370381, 13.0-RELEASE before p4, 12.2-RELEASE before p10, and 11.4-RELEASE before p13, the ggatec daemon does not validate the size of a response before writing it to a fixed-sized buffer allowing a malicious attacker in a privileged network position to overwrite the stack of ggatec and potentially execute arbitrary code.

In FreeBSD 13.0-STABLE before n246941-20f96f215562, 12.2-STABLE before r370400, 11.4-STABLE before r370399, 13.0-RELEASE before p4, 12.2-RELEASE before p10, and 11.4-RELEASE before p13, certain VirtIO-based device models in bhyve failed to handle errors when fetching I/O descriptors. A malicious guest may cause the device model to operate on uninitialized I/O vectors leading to memory corruption, crashing of the bhyve process, and possibly arbitrary code execution in the bhyve process.