{ "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=` 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=` 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=` 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" } } } }