{"dataType":"CVE_RECORD","dataVersion":"5.2","cveMetadata":{"cveId":"CVE-2026-52906","assignerOrgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","state":"PUBLISHED","assignerShortName":"Linux","dateReserved":"2026-06-09T07:44:35.366Z","datePublished":"2026-06-09T12:36:03.521Z","dateUpdated":"2026-08-05T12:31:29.381Z"},"containers":{"cna":{"providerMetadata":{"orgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","shortName":"Linux","dateUpdated":"2026-08-05T12:31:29.381Z"},"descriptions":[{"lang":"en","value":"In the Linux kernel, the following vulnerability has been resolved:\n\n9p: fix access mode flags being ORed instead of replaced\n\nSince commit 1f3e4142c0eb (\"9p: convert to the new mount API\"),\nv9fs_apply_options() applies parsed mount flags with |= onto flags\nalready set by v9fs_session_init(). For 9P2000.L, session_init sets\nV9FS_ACCESS_CLIENT as the default, so when the user mounts with\n\"access=user\", both bits end up set. Access mode checks compare\nagainst exact values, so having both bits set matches neither mode.\n\nThis causes v9fs_fid_lookup() to fall through to the default switch\ncase, using INVALID_UID (nobody/65534) instead of current_fsuid()\nfor all fid lookups. Root is then unable to chown or perform other\nprivileged operations.\n\nFix by clearing the access mask before applying the user's choice."}],"metrics":[{"cvssV3_1":{"version":"3.1","vectorString":"CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N","baseScore":7.7,"baseSeverity":"HIGH"},"scenarios":[{"lang":"en","value":"AV:L - The flaw is reached through local mount and VFS file-operation syscalls (open, read, write, setattr) on a 9p client mount, not through remote packet handling. Even when 9p uses virtio or TCP transport, exploitation requires local access to the mounted filesystem or local CAP_SYS_ADMIN to mount with the triggering options.\nAC:L - An attacker who can mount 9p with 9P2000.L and `access=user` or `access=<uid>` reliably triggers the bug on every fid lookup. On systems where virtio-9p is already mounted with those options, exploitation requires only normal filesystem access with no race or special timing.\nPR:N - Exploitation against an already-mounted vulnerable 9p share requires no elevated privileges—only local shell access to the mount point. The worst case (`access=<uid>` SINGLE mode) is meant to block all other users, yet any unprivileged local user can still obtain fids and access the share.\nUI:N - Once a vulnerable 9p filesystem is mounted, no further victim interaction is required; the attacker simply performs normal file operations. Mounting with the triggering options is attacker-controlled or a one-time administrative setup, not ongoing user interaction at exploitation time.\nS:U - Impact is confined to unauthorized access within the guest/kernel filesystem boundary (bypassing 9p access-mode isolation between local users or against a single-user mount restriction). It does not cross VM-to-host, IOMMU, or sandbox security boundaries beyond the shared 9p export itself.\nC:H - The mangled access mask forces all operations through a shared INVALID_UID attach instead of per-user attaches, breaking confidentiality guarantees of `access=user` and completely defeating `access=<uid>` SINGLE-mode isolation. Unprivileged users can read data on mounts explicitly restricted to another user.\nI:H - The same fid-lookup failure lets unauthorized users perform writes through the shared INVALID_UID attach on mounts where SINGLE or per-user modes should have prevented any access. Server-side authorization keyed to attach identity is undermined, enabling unauthorized modification of files on the export.\nA:N - The bug is a logic error in access-mode handling that misroutes fid lookups; it does not cause kernel oops, panic, hang, or repeatable denial of service. Root losing chown capability on the mount is a localized authorization failure, not system-wide availability loss."}]}],"affected":[{"product":"Linux","vendor":"Linux","defaultStatus":"unaffected","repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","programFiles":["fs/9p/v9fs.c"],"versions":[{"version":"1f3e4142c0eb178089ea0cbc97506a061470ad27","lessThan":"b8f037e87a083291190204b959cda417aaf01058","status":"affected","versionType":"git"},{"version":"1f3e4142c0eb178089ea0cbc97506a061470ad27","lessThan":"da2346a48a5a1fed86c3fe3d73c0b60e7b3027c9","status":"affected","versionType":"git"}]},{"product":"Linux","vendor":"Linux","defaultStatus":"affected","repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","programFiles":["fs/9p/v9fs.c"],"versions":[{"version":"6.19","status":"affected"},{"version":"0","lessThan":"6.19","status":"unaffected","versionType":"semver"},{"version":"7.0.4","lessThanOrEqual":"7.0.*","status":"unaffected","versionType":"semver"},{"version":"7.1","lessThanOrEqual":"*","status":"unaffected","versionType":"original_commit_for_fix"}]}],"cpeApplicability":[{"nodes":[{"operator":"OR","negate":false,"cpeMatch":[{"vulnerable":true,"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionStartIncluding":"6.19","versionEndExcluding":"7.0.4"},{"vulnerable":true,"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionStartIncluding":"6.19","versionEndExcluding":"7.1"}]}]}],"references":[{"url":"https://git.kernel.org/stable/c/b8f037e87a083291190204b959cda417aaf01058"},{"url":"https://git.kernel.org/stable/c/da2346a48a5a1fed86c3fe3d73c0b60e7b3027c9"}],"title":"9p: fix access mode flags being ORed instead of replaced","x_generator":{"engine":"bippy-1.2.0"}}}}