Skip to main content

CVE detail

CVE-2025-15576

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.

CVSS 7.5 · HighBuzz score 11.9

Buzz score

Why this CVE is surfacing

Buzz score total 11.9

This all-time snapshot uses the same composite formula as Trending across a 30-year evidence window, rather than a current rolling window.

Buzz score components · mention 6.9 · diversity 5.0 · KEV 0.0 · OTX 0.0 · PoC 0.0
Mention score
6.9
1 evidence mentions in the snapshot
Diversity score
5.0
1 sources across 1 categories
KEV score
0.0
No KEV entry observed
OTX score
0.0
0 OTX pulses
PoC score
0.0
0 repos · best confidence N/A
Best PoC traction
0
Maximum stars on a matched PoC repo

Why it matters now

Mention timeline

Total mentions
0
within the 30d window
Peak daily
0
highest bucket

Evidence

Source links by recency

Newest mentions first
1 source links · newest first

Exploit code

Public exploit repository references

Public PoC repositories are third-party, potentially unsafe artifacts. Treat their code as untrusted and use it only on authorized systems in an isolated, least-privilege environment. cvebuzz does not execute the code or verify that an exploit works.

0 repository references · best confidence N/A · max 0 stars
No public PoC repositories have been matched yet.

Related records

Similar CVEs

6 related CVEs with shared weakness or product evidence
  • CVE-2026-45256

    When used to deliver a signal to a specific thread, thr_kill2(2) called p_cansignal() to determine whether the operation was permitted but did not check the result before deliveri…

    CVSS 5.5 · Medium
    1 mention
  • CVE-2026-45254

    In the case of the cap_net service, when a key present in the old limit was omitted from the new limit, the missing key was treated as "allow any" instead of being rejected. In c…

    CVSS 6.5 · Medium
    1 mention
  • CVE-2026-6386

    In order to apply a particular protection key to an address range, the kernel must update the corresponding page table entries. The subroutine which handled this failed to take i…

    CVSS 6.2 · Medium
  • CVE-2025-15547

    By default, jailed processes cannot mount filesystems, including nullfs(4). However, the allow.mount.nullfs option enables mounting nullfs filesystems, subject to privilege check…

    CVSS 8.8 · High
    1 mention
  • CVE-2024-42416

    The ctl_report_supported_opcodes function did not sufficiently validate a field provided by userspace, allowing an arbitrary write to a limited amount of kernel help memory. Mali…

    CVSS 8.8 · High
  • CVE-2023-5978

    In versions of FreeBSD 13-RELEASE before 13-RELEASE-p5, under certain circumstances the cap_net libcasper(3) service incorrectly validates that updated constraints are strictly su…

    CVSS 7.5 · High