Linux Kernel EUVD-2026-35415

Requires a Linux host running a kernel between commit 1f3e4142c0eb (new 9p mount API) and the fix commits b8f037e87a08 / da2346a48a5a, with the 9p/9pnet modules loaded and a 9P2000.L filesystem mounted using a non-default access= option (e.g., access=user, access=any, or access=<uid>) - the default access=client configuration does not trigger the bug. Triggering also requires that 9p mounts be reachable from the attacker (typically a VM guest using VirtFS, a WSL2 instance, or a host with user-mountable 9p entries in fstab/automount); limiting factors include that mount(2) of 9p generally needs CAP_SYS_ADMIN, that 9p is not loaded by default on many server distributions, and that the impact is scoped to operations performed over the affected 9p mount rather than arbitrary kernel memory.

The provided CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N (7.7) reflects local, unauthenticated, low-complexity access with high confidentiality and integrity impact, which is consistent with a 9p mount being a local filesystem-layer issue rather than network-reachable. However, PR:N is questionable in practice: triggering the bug requires the ability to mount a 9p filesystem with a chosen access= option, which on most systems is a privileged or otherwise gated operation (root, CAP_SYS_ADMIN in the relevant userns, or fstab/automount-controlled), so realistic exploitation almost always requires some level of privilege or a misconfigured deployment that exposes 9p mounts to unprivileged users. EPSS is 0.02% (5th percentile) and the issue is not in CISA KEV - there is no public exploit identified at time of analysis, and the practical security impact is closer to an integrity/authorization regression for legitimate root over 9p mounts than to a classic privilege escalation primitive. Net: treat as a correctness/security fix to schedule with normal stable-kernel cadence, not as an emergency.

On a vulnerable kernel, an administrator (or automount configuration) mounts a 9P2000.L share with 'access=user' expecting per-process UID mapping; instead, every fid lookup resolves to INVALID_UID/nobody, so root operations such as chown, chmod on root-owned files, or writes to root-owned paths over the mount silently fail or land as nobody, producing an integrity/authorization regression that can be leveraged to deny privileged maintenance or create files with unexpected ownership on the server side. No public exploit identified at time of analysis; the attack vector is local and complexity is low once a 9p mount with non-default access mode exists.