A subtle ordering bug in the Linux kernel’s 9p (v9fs) client can crash a system when creating subdirectories under mounted 9p trees that use POSIX ACL defaults — the defect tracked as CVE‑2025‑22070 is a NULL‑pointer dereference in fs/9p’s mkdir path that has been fixed upstream but remains an operational concern for unpatched kernels and long‑tail vendor images.
The 9p protocol (v9fs) is commonly used for lightweight filesystem sharing between host and guest or between containers and hypervisors (for example virtio‑based virtfs), and it implements POSIX extensions such as ACLs. Under a specific configuration — when a 9p mount uses the posixacl option and the parent directory has a default ACL for newly created subdirectories — invoking mkdir triggers a code path that, in some kernel versions, ends up dereferencing a NULL pointer and generates a kernel oops. This is an availability / Denial‑of‑Service issue rather than a confidentiality or privilege escalation problem. The bug was recorded publicly as CVE‑2025‑22070 and is described in standard vulnerability repositories and vendor trackers. Upstream kernel maintenance fixed the underlying logic with small, targeted changes merged into the stable trees; distribution vendors have been rolling the fix into package updates.
Source: MSRC Security Update Guide - Microsoft Security Response Center
Background / Overview
The 9p protocol (v9fs) is commonly used for lightweight filesystem sharing between host and guest or between containers and hypervisors (for example virtio‑based virtfs), and it implements POSIX extensions such as ACLs. Under a specific configuration — when a 9p mount uses the posixacl option and the parent directory has a default ACL for newly created subdirectories — invoking mkdir triggers a code path that, in some kernel versions, ends up dereferencing a NULL pointer and generates a kernel oops. This is an availability / Denial‑of‑Service issue rather than a confidentiality or privilege escalation problem. The bug was recorded publicly as CVE‑2025‑22070 and is described in standard vulnerability repositories and vendor trackers. Upstream kernel maintenance fixed the underlying logic with small, targeted changes merged into the stable trees; distribution vendors have been rolling the fix into package updates. What went wrong — technical anatomy
The call‑order regression
The root cause is an ordering regression introduced earlier in the 6.0 development cycle: a call to v9fs_fid_add in v9fs_vfs_mkdir_dotl can set the passed fid pointer to NULL in certain failure cases, but immediately after the call the code unconditionally calls v9fs_set_create_acl, which expects a valid non‑NULL fid. The mismatch leads to a NULL dereference and an immediate kernel BUG/oops when the condition is triggered (for example by creating a subdirectory under a parent that carries default ACL entries). The upstream CVE announcement explicitly ties the regression to a commit introduced in 6.0 and documents the fix as a reversal or reorder of the two calls so that ACL setup happens before v9fs_fid_add or is performed under conditions that guarantee a valid fid.Why the kernel crashes
A NULL pointer dereference in kernel space is severe: unlike userland, where a process can be terminated, a kernel NULL dereference typically produces an oops and often a system crash or persistent instability. Because the failing code runs in the v9fs path — which is executed in kernel context during filesystem operations — the observed symptom is immediate availability loss for the host or affected subsystem. The stack traces published in public advisories show the fault surfacing through v9fs_vfs_mkdir_dotl and related v9fs/xattr/acl call frames.Affected code, versions and provenance
- The issue was introduced around Linux 6.0 by the commit identified in the upstream advisories and mailing lists (the regression commit referenced as dafbe689736f62c696ac64809b17bdc752cfbe76 in upstream metadata).
- Upstream stable fixes were applied into multiple kernel lines and are available in stable commits (for example fixes referenced in 6.13.11, 6.14.2 and subsequent series; commit IDs are linked in the linux‑cve‑announce message). Operators should consult their distribution’s kernel changelog for the concrete backport mapping.
- Distribution trackers (Ubuntu, Debian, SUSE, Oracle, Amazon’s ALAS mapping, etc. have imported the CVE and provided distribution‑specific advisories and CVSS scoring (commonly CVSS v3 ≈ 5.5). The vulnerability is commonly classified as Medium because the attack vector is local and the impact is availability.
Realistic exposure and attack model
This is not a trivial remote exploit: the attacker needs the ability to cause the vulnerable v9fs code path to execute with a mounted 9p export that uses posixacl and default ACLs. Typical exposure scenarios include:- Virtualization hosts or guests using virtfs/9p to export directories between host and guest.
- CI, build or automation systems that mount untrusted images or expose 9p shares to less‑trusted workloads.
- Developer or platform images where 9p/virtfs is enabled for convenience, often with relaxed mount policies.
How to detect if you’re affected
Look for operational artifacts and log signatures rather than attempting to find an exploit payload:- Kernel oops/panic messages referencing v9fs_vfs_mkdir_dotl, v9fs_set_create_acl, v9fs_fid_xattr_get, or p9_client_walk in dmesg/journalctl. Public reproductions and reports include stack traces that name these symbols.
- Repeated failures when creating subdirectories on 9p‑mounted trees that use posixacl and default ACLs.
- Automated scanners may flag unpatched kernels based on package metadata; treat scanner alerts as triage signals and verify by checking kernel changelogs or the presence of upstream commit IDs in your kernel source.
- Check whether 9p is present / in use:
- lsmod | grep -E '9p|9pnet'
- findmnt -t 9p
- Search kernel logs for the signature stack traces:
- journalctl -k | grep -E 'v9fs_vfs_mkdir_dotl|v9fs_set_create_acl|p9_client_walk'
- Confirm whether your shipped kernel build includes the upstream fix by checking distribution advisory changelogs or, for self‑built kernels, searching the git history for the stable commit IDs referenced by the linux‑cve‑announce entry.
Remediation and mitigation guidance
Definitive fix (recommended)
- Install vendor/distribution kernel updates that include the stable fixes referenced in the upstream announcements and reboot into the patched kernel. Distribution advisories map the upstream stable commit(s) into packaged kernel versions and should be the primary source for which package to install. Do not cherry‑pick arbitrary commits in production unless you maintain a rigorous kernel build and backport process.
Short‑term compensating controls (if you cannot patch immediately)
- Avoid mounting 9p filesystems with posixacl on production systems unless strictly required; remove or restrict automated mounts from untrusted sources.
- Unload or blacklist 9p-related kernel modules on hosts that do not need 9p functionality. Common module names:
9p,9pnet,9pnet_virtio. To blacklist persistently, create a file such as /etc/modprobe.d/disable-9p.conf containing: - blacklist 9p
- blacklist 9pnet
- blacklist 9pnet_virtio
- Tighten mount policies:
- Restrict who can mount filesystems (use filesystem mount namespaces, sysctl controls, or least‑privilege policies).
- In virtualization environments, prefer alternatives to 9p such as virtio‑fs where applicable, and restrict which guests are permitted to use passthrough/shared filesystems.
Operational checklist for patch rollout
- Inventory systems with 9p enabled: use configuration management and runtime checks (findmnt, lsmod).
- Prioritize patching hosts that host multiple tenants, host CI/image ingestion tooling, or mount untrusted media.
- Validate updated kernels in a test/pilot ring (confirm the distribution package changelog references the CVE or the upstream commit hashes if your distro provides them).
- Deploy to production and reboot hosts in controlled waves; monitor kernel logs for residual traces of the failing stack frames.
- For appliances or vendor kernels, engage the vendor for a firmware/kernel update if the vendor did not yet publish a backport. Long‑tail vendor kernels commonly lag upstream fixes and can remain exposed.
Vendor and distribution responses
Multiple major distributions and vendors have imported the CVE into their trackers and released kernel updates or guidance. Examples observed in public feeds include Ubuntu, Debian, SUSE and Oracle Linux advisories mapping the fix into distribution kernel packages; Amazon’s ALAS catalog shows platform‑specific status entries. Because the kernel change is small and low‑risk, maintainers generally backported it into stable kernels and produced package updates quickly. Operators should consult their vendor’s security tracker for the exact package names and deployment instructions for their release.Why this fix is low‑risk — and what remains risky
Strengths of the upstream fix- The code change upstream is narrowly scoped: it eliminates the unsafe ordering that produced a NULL dereference and converts a crash into a controlled error path. Small, defensive fixes of this type are easy to review and backport and have a low regression profile. The linux‑cve‑announce entry highlights that the fix is a simple reordering/defensive check and has been merged into stable series.
- Vendor lag is the dominant operational risk. Embedded vendors, Android OEM kernels, and appliances frequently maintain downstream forks and may not pull small stable backports promptly. Those long‑tail devices represent the most persistent exposure.
- Scanning false positives/negatives. Vulnerability scanners often flag unpatched kernel trees based on package metadata; however, the definitive verification is the presence of the upstream stable commit(s) in your kernel package changelog or source. Treat scanner output as a prioritization tool rather than final proof.
- Operational impact of mitigations. Blacklisting 9p modules or removing mount capability can disrupt running virtualization setups that rely on virtfs; any mitigation must be validated against service impact.
Incident response tips
If you observe a kernel oops referencing the v9fs stack frames:- Isolate — if the affected host is multi‑tenant, isolate or migrate guests to reduce blast radius.
- Collect forensic logs — save dmesg, journalctl -k output and any mounted 9p configuration details (mount options and ACLs).
- Reproduce (safely) — in a controlled lab, mount an equivalent 9p export with posixacl and default ACLs and execute mkdir to reproduce the oops; this can help validate whether the kernel in question is the exact vulnerable build.
- Patch — apply the vendor’s kernel update and reboot; verify the absence of the failing stack trace on subsequent tests.
- Vendor escalation — for devices where vendor kernels are used (appliances, OEM images), escalate to the vendor and request timeline for backport or updated firmware.
Cross‑verification and transparency
Independent sources corroborate the same technical narrative: the NVD entry documents the symptom and affected path, major distributions’ security pages (Ubuntu, Debian, SUSE) describe the exact call frames and the fix rationale, and the linux‑cve‑announce message lists the upstream commit IDs that introduced and later remedied the regression. Cross‑referencing these materials allows operators to validate both the root cause and the exact fixes to look for in patched kernels. Where possible, verify the presence of the upstream stable commit in your kernel packages’ changelogs before declaring a host remediated. Caveat about commit‑level verification: while the mailing‑list CVE announcement lists the regression commit and the stable fix commit IDs, direct retrieval of those commits from git.kernel.org may sometimes be blocked by requester network conditions or require fetching from mirror sites. If a commit link cannot be fetched immediately, rely on the vendor’s changelog mapping or ask your distribution/vendor to confirm the backport presence. The mailing list and vendor advisories remain authoritative for mapping.Practical checklist for system administrators
- Inventory: find hosts using 9p. (findmnt -t 9p; lsmod | grep 9p)
- Log check: search kernel logs for v9fs stack traces.
- Patch mapping: consult your vendor security tracker for the CVE and the package that contains the stable fix.
- Deploy and verify: install the updated kernel, reboot, and re‑run a controlled mkdir test against a safe 9p mount to ensure the crash no longer occurs.
- Compensate if needed: blacklist 9p modules on hosts that do not require them, and restrict mount privileges for untrusted users until a patch is applied.
Conclusion
CVE‑2025‑22070 is a textbook example of how a small sequencing or defensive‑check omission in kernel filesystem code can escalate into a serious availability problem. The fix is small and has been merged into upstream stable kernels; the practical operational work is to verify that your distribution’s kernel packages include the backport and to patch or mitigate affected hosts quickly — particularly hypervisors, multi‑tenant nodes, and CI/image ingestion servers that are most likely to encounter untrusted 9p exports. Until those updates are widely deployed, sensible mitigations (disabling or restricting 9p usage) and focused monitoring of kernel oops traces will reduce exposure while you schedule patching.Source: MSRC Security Update Guide - Microsoft Security Response Center
