CVE-2026-64069 (GCVE-0-2026-64069)
Vulnerability from cvelistv5
Published
2026-07-19 15:39
Modified
2026-08-05 12:38
Severity ?
9.8 (Critical) - CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Summary
In the Linux kernel, the following vulnerability has been resolved: netfs: Fix cancellation of a DIO and single read subrequests When the preparation of a new subrequest for a read fails, if the subrequest has already been added to the stream->subrequests list, it can't simply be put and abandoned as the collector may see it. Also, if it hasn't been queued yet, it has two outstanding refs that both need to be put. Both DIO read and single-read dispatch fail at this; further, both differ in the order they do things to the way buffered read works. Fix cancellation of both DIO-read and single-read subrequests that failed preparation by the following steps: (1) Harmonise all three reads (buffered, dio, single) to queue the subreq before prepping it. (2) Make all three call netfs_queue_read() to do the queuing. (3) Set NETFS_RREQ_ALL_QUEUED independently of the queuing as we don't know the length of the subreq at this point. (4) In all cases, set the error and NETFS_SREQ_FAILED flag on the subreq and then call netfs_read_subreq_terminated() to deal with it. This will pass responsibility off to the collector for dealing with it.
References
Impacted products
Vendor Product Version
Linux Linux Version: e2d46f2ec332533816417b60933954173f602121
Version: e2d46f2ec332533816417b60933954173f602121
Version: e2d46f2ec332533816417b60933954173f602121
 Create a notification for this product.
Show details on NVD website

To clipboard 

{
  "containers": {
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "product": "Linux",
          "programFiles": [
            "fs/netfs/buffered_read.c",
            "fs/netfs/direct_read.c",
            "fs/netfs/internal.h",
            "fs/netfs/read_collect.c",
            "fs/netfs/read_single.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "lessThan": "5366199be46fb53de62861721d34ba816e7e440e",
              "status": "affected",
              "version": "e2d46f2ec332533816417b60933954173f602121",
              "versionType": "git"
            },
            {
              "lessThan": "f73372a4c6900d117f8e903fe10b62692f95e6c4",
              "status": "affected",
              "version": "e2d46f2ec332533816417b60933954173f602121",
              "versionType": "git"
            },
            {
              "lessThan": "6f0f7ac1915abc0d202f0eb4b003a6548a5ba60d",
              "status": "affected",
              "version": "e2d46f2ec332533816417b60933954173f602121",
              "versionType": "git"
            }
          ]
        },
        {
          "defaultStatus": "affected",
          "product": "Linux",
          "programFiles": [
            "fs/netfs/buffered_read.c",
            "fs/netfs/direct_read.c",
            "fs/netfs/internal.h",
            "fs/netfs/read_collect.c",
            "fs/netfs/read_single.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "status": "affected",
              "version": "6.14"
            },
            {
              "lessThan": "6.14",
              "status": "unaffected",
              "version": "0",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.18.*",
              "status": "unaffected",
              "version": "6.18.34",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "7.0.*",
              "status": "unaffected",
              "version": "7.0.11",
              "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": "6.18.34",
                  "versionStartIncluding": "6.14",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "7.0.11",
                  "versionStartIncluding": "6.14",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "7.1",
                  "versionStartIncluding": "6.14",
                  "vulnerable": true
                }
              ],
              "negate": false,
              "operator": "OR"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnetfs: Fix cancellation of a DIO and single read subrequests\n\nWhen the preparation of a new subrequest for a read fails, if the\nsubrequest has already been added to the stream-\u003esubrequests list, it can\u0027t\nsimply be put and abandoned as the collector may see it.  Also, if it\nhasn\u0027t been queued yet, it has two outstanding refs that both need to be\nput.  Both DIO read and single-read dispatch fail at this; further, both\ndiffer in the order they do things to the way buffered read works.\n\nFix cancellation of both DIO-read and single-read subrequests that failed\npreparation by the following steps:\n\n (1) Harmonise all three reads (buffered, dio, single) to queue the subreq\n     before prepping it.\n\n (2) Make all three call netfs_queue_read() to do the queuing.\n\n (3) Set NETFS_RREQ_ALL_QUEUED independently of the queuing as we don\u0027t\n     know the length of the subreq at this point.\n\n (4) In all cases, set the error and NETFS_SREQ_FAILED flag on the subreq\n     and then call netfs_read_subreq_terminated() to deal with it.  This\n     will pass responsibility off to the collector for dealing with it."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "baseScore": 9.8,
            "baseSeverity": "CRITICAL",
            "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
            "version": "3.1"
          },
          "scenarios": [
            {
              "lang": "en",
              "value": "AV:N - The bug is in the netfs client read path used by CIFS/SMB, 9p, AFS, and Ceph when serving network-backed I/O; a malicious remote filesystem server can induce prepare_read failure during multi-chunk O_DIRECT reads, exercising the faulty cancellation without local shell access on the victim.\nAC:L - An attacker controlling the remote server and read parameters (O_DIRECT, read size spanning multiple subrequests) can reliably trigger prepare_read failure after partial submission, creating the stuck subrequest state; no rare memory layout or victim timing is required.\nPR:N - Exploitation requires only that some client process perform a read on a mounted network filesystem share, which needs no elevated Linux privileges; SMB authentication to the attacker-controlled server does not constitute privilege on the victim host.\nUI:N - In common enterprise deployments the CIFS/AFS/9p mount is already established, so a remote attacker can trigger the bug through normal file access over the mount without additional victim actions beyond routine use of the share.\nS:U - Impact is confined to the kernel host processing the network filesystem read; it does not cross a VM/hypervisor or IOMMU security boundary.\nC:H - Improper subrequest cancellation leaves queued objects visible to the collector with incorrect refcounting, creating a use-after-free class lifecycle bug where freed or inconsistent subrequest memory may be accessed during collection.\nI:H - The refcount/collector desynchronization can corrupt kernel heap metadata and, in the DIO path, prematurely calls inode_dio_end() while subrequests remain active, enabling memory corruption primitives beyond a simple error return.\nA:H - A failed mid-read cancellation leaves subrequests stuck with NETFS_SREQ_IN_PROGRESS set, causing netfs_wait_for_read() to sleep in TASK_UNINTERRUPTIBLE indefinitely and producing a severe kernel-level denial of service."
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-08-05T12:38:53.294Z",
        "orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "shortName": "Linux"
      },
      "references": [
        {
          "url": "https://git.kernel.org/stable/c/5366199be46fb53de62861721d34ba816e7e440e"
        },
        {
          "url": "https://git.kernel.org/stable/c/f73372a4c6900d117f8e903fe10b62692f95e6c4"
        },
        {
          "url": "https://git.kernel.org/stable/c/6f0f7ac1915abc0d202f0eb4b003a6548a5ba60d"
        }
      ],
      "title": "netfs: Fix cancellation of a DIO and single read subrequests",
      "x_generator": {
        "engine": "bippy-1.2.0"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
    "assignerShortName": "Linux",
    "cveId": "CVE-2026-64069",
    "datePublished": "2026-07-19T15:39:45.932Z",
    "dateReserved": "2026-07-19T07:54:57.030Z",
    "dateUpdated": "2026-08-05T12:38:53.294Z",
    "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.