CVE-2026-52906 (GCVE-0-2026-52906)
Vulnerability from cvelistv5
Published
2026-06-09 12:36
Modified
2026-08-05 12:31
Severity ?
7.7 (High) - CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N
Summary
In the Linux kernel, the following vulnerability has been resolved: 9p: fix access mode flags being ORed instead of replaced Since commit 1f3e4142c0eb ("9p: convert to the new mount API"), v9fs_apply_options() applies parsed mount flags with |= onto flags already set by v9fs_session_init(). For 9P2000.L, session_init sets V9FS_ACCESS_CLIENT as the default, so when the user mounts with "access=user", both bits end up set. Access mode checks compare against exact values, so having both bits set matches neither mode. This causes v9fs_fid_lookup() to fall through to the default switch case, using INVALID_UID (nobody/65534) instead of current_fsuid() for all fid lookups. Root is then unable to chown or perform other privileged operations. Fix by clearing the access mask before applying the user's choice.
References
Impacted products
Vendor Product Version
Linux Linux Version: 1f3e4142c0eb178089ea0cbc97506a061470ad27
Version: 1f3e4142c0eb178089ea0cbc97506a061470ad27
 Create a notification for this product.
Show details on NVD website

To clipboard 

{
  "containers": {
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "product": "Linux",
          "programFiles": [
            "fs/9p/v9fs.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "lessThan": "b8f037e87a083291190204b959cda417aaf01058",
              "status": "affected",
              "version": "1f3e4142c0eb178089ea0cbc97506a061470ad27",
              "versionType": "git"
            },
            {
              "lessThan": "da2346a48a5a1fed86c3fe3d73c0b60e7b3027c9",
              "status": "affected",
              "version": "1f3e4142c0eb178089ea0cbc97506a061470ad27",
              "versionType": "git"
            }
          ]
        },
        {
          "defaultStatus": "affected",
          "product": "Linux",
          "programFiles": [
            "fs/9p/v9fs.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "status": "affected",
              "version": "6.19"
            },
            {
              "lessThan": "6.19",
              "status": "unaffected",
              "version": "0",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "7.0.*",
              "status": "unaffected",
              "version": "7.0.4",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "*",
              "status": "unaffected",
              "version": "7.1",
              "versionType": "original_commit_for_fix"
            }
          ]
        }
      ],
      "cpeApplicability": [
        {
          "nodes": [
            {
              "cpeMatch": [
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "7.0.4",
                  "versionStartIncluding": "6.19",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "7.1",
                  "versionStartIncluding": "6.19",
                  "vulnerable": true
                }
              ],
              "negate": false,
              "operator": "OR"
            }
          ]
        }
      ],
      "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\u0027s choice."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "baseScore": 7.7,
            "baseSeverity": "HIGH",
            "vectorString": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N",
            "version": "3.1"
          },
          "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=\u003cuid\u003e` 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\u2014only local shell access to the mount point. The worst case (`access=\u003cuid\u003e` 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=\u003cuid\u003e` 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."
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-08-05T12:31:29.381Z",
        "orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "shortName": "Linux"
      },
      "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"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
    "assignerShortName": "Linux",
    "cveId": "CVE-2026-52906",
    "datePublished": "2026-06-09T12:36:03.521Z",
    "dateReserved": "2026-06-09T07:44:35.366Z",
    "dateUpdated": "2026-08-05T12:31:29.381Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.




Sightings

Author Source Type Date

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
  • Confirmed: The vulnerability is confirmed from an analyst perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
  • Patched: This vulnerability was successfully patched by the user reporting the sighting.
  • Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
  • Not confirmed: The user expresses doubt about the veracity of the vulnerability.
  • Not patched: This vulnerability was not successfully patched by the user reporting the sighting.