Search
Search Results (8 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2025-15576 | 1 Freebsd | 1 Freebsd | 2026-03-10 | 7.5 High |
| If two sibling jails are restricted to separate filesystem trees, which is to say that neither of the two jail root directories is an ancestor of the other, jailed processes may nonetheless be able to access a shared directory via a nullfs mount, if the administrator has configured one. In this case, cooperating processes in the two jails may establish a connection using a unix domain socket and exchange directory descriptors with each other. When performing a filesystem name lookup, at each step of the lookup, the kernel checks whether the lookup would descend below the jail root of the current process. If the jail root directory is not encountered, the lookup continues. In a configuration where processes in two different jails are able to exchange file descriptors using a unix domain socket, it is possible for a jailed process to receive a directory for a descriptor that is below that process' jail root. This enables full filesystem access for a jailed process, breaking the chroot. Note that the system administrator is still responsible for ensuring that an unprivileged user on the jail host is not able to pass directory descriptors to a jailed process, even in a patched kernel. | ||||
| CVE-2025-15547 | 1 Freebsd | 1 Freebsd | 2026-03-10 | 8.8 High |
| By default, jailed processes cannot mount filesystems, including nullfs(4). However, the allow.mount.nullfs option enables mounting nullfs filesystems, subject to privilege checks. If a privileged user within a jail is able to nullfs-mount directories, a limitation of the kernel's path lookup logic allows that user to escape the jail's chroot, yielding access to the full filesystem of the host or parent jail. In a jail configured to allow nullfs(4) mounts from within the jail, the jailed root user can escape the jail's filesystem root. | ||||
| CVE-2025-14558 | 1 Freebsd | 1 Freebsd | 2026-03-10 | 7.2 High |
| The rtsol(8) and rtsold(8) programs do not validate the domain search list options provided in router advertisement messages; the option body is passed to resolvconf(8) unmodified. resolvconf(8) is a shell script which does not validate its input. A lack of quoting meant that shell commands pass as input to resolvconf(8) may be executed. | ||||
| CVE-2025-14769 | 1 Freebsd | 1 Freebsd | 2026-03-10 | 7.5 High |
| In some cases, the `tcp-setmss` handler may free the packet data and throw an error without halting the rule processing engine. A subsequent rule can then allow the traffic after the packet data is gone, resulting in a NULL pointer dereference. Maliciously crafted packets sent from a remote host may result in a Denial of Service (DoS) if the `tcp-setmss` directive is used and a subsequent rule would allow the traffic to pass. | ||||
| CVE-2025-24934 | 1 Freebsd | 1 Freebsd | 2025-10-23 | 5.4 Medium |
| Software which sets SO_REUSEPORT_LB on a socket and then connects it to a host will not directly observe any problems. However, due to its membership in a load-balancing group, that socket will receive packets originating from any host. This breaks the contract of the connect(2) and implied connect via sendto(2), and may leave the application vulnerable to spoofing attacks. The kernel failed to check the connection state of sockets when adding them to load-balancing groups. Furthermore, when looking up the destination socket for an incoming packet, the kernel will match a socket belonging to a load-balancing group even if it is connected, in violation of the contract that connected sockets are only supposed to receive packets originating from the connected host. | ||||
| CVE-2025-0373 | 2 Freebsd, Netapp | 2 Freebsd, Ontap | 2025-07-13 | 6 Medium |
| On 64-bit systems, the implementation of VOP_VPTOFH() in the cd9660, tarfs and ext2fs filesystems overflows the destination FID buffer by 4 bytes, a stack buffer overflow. A NFS server that exports a cd9660, tarfs, or ext2fs file system can be made to panic by mounting and accessing the export with an NFS client. Further exploitation (e.g., bypassing file permission checking or remote kernel code execution) is potentially possible, though this has not been demonstrated. In particular, release kernels are compiled with stack protection enabled, and some instances of the overflow are caught by this mechanism, causing a panic. | ||||
| CVE-2025-0374 | 1 Freebsd | 1 Freebsd | 2025-07-12 | 6.5 Medium |
| When etcupdate encounters conflicts while merging files, it saves a version containing conflict markers in /var/db/etcupdate/conflicts. This version does not preserve the mode of the input file, and is world-readable. This applies to files that would normally have restricted visibility, such as /etc/master.passwd. An unprivileged local user may be able to read encrypted root and user passwords from the temporary master.passwd file created in /var/db/etcupdate/conflicts. This is possible only when conflicts within the password file arise during an update, and the unprotected file is deleted when conflicts are resolved. | ||||
| CVE-2025-0662 | 1 Freebsd | 1 Freebsd | 2025-07-12 | 4.9 Medium |
| In some cases, the ktrace facility will log the contents of kernel structures to userspace. In one such case, ktrace dumps a variable-sized sockaddr to userspace. There, the full sockaddr is copied, even when it is shorter than the full size. This can result in up to 14 uninitialized bytes of kernel memory being copied out to userspace. It is possible for an unprivileged userspace program to leak 14 bytes of a kernel heap allocation to userspace. | ||||
Page 1 of 1.