Vulnerability-Lookup

GHSA-C3C4-J5V2-Q687

Vulnerability from github – Published: 2025-07-25 15:30 – Updated: 2025-11-19 18:31

Details

In the Linux kernel, the following vulnerability has been resolved:

netfs: Fix double put of request

If a netfs request finishes during the pause loop, it will have the ref that belongs to the IN_PROGRESS flag removed at that point - however, if it then goes to the final wait loop, that will also put the ref because it sees that the IN_PROGRESS flag is clear and incorrectly assumes that this happened when it called the collector.

In fact, since IN_PROGRESS is clear, we shouldn't call the collector again since it's done all the cleanup, such as calling ->ki_complete().

Fix this by making netfs_collect_in_app() just return, indicating that we're done if IN_PROGRESS is removed.

Severity

7.8 (High)


                  
                    CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2025-38411"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-415"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-07-25T14:15:32Z",
    "severity": "HIGH"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnetfs: Fix double put of request\n\nIf a netfs request finishes during the pause loop, it will have the ref\nthat belongs to the IN_PROGRESS flag removed at that point - however, if it\nthen goes to the final wait loop, that will *also* put the ref because it\nsees that the IN_PROGRESS flag is clear and incorrectly assumes that this\nhappened when it called the collector.\n\nIn fact, since IN_PROGRESS is clear, we shouldn\u0027t call the collector again\nsince it\u0027s done all the cleanup, such as calling -\u003eki_complete().\n\nFix this by making netfs_collect_in_app() just return, indicating that\nwe\u0027re done if IN_PROGRESS is removed.",
  "id": "GHSA-c3c4-j5v2-q687",
  "modified": "2025-11-19T18:31:16Z",
  "published": "2025-07-25T15:30:53Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38411"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/9df7b5ebead649b00bf9a53a798e4bf83a1318fd"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/d18facba5a5795ad44b2a00a052e3db2fa77ab12"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

CVE-2025-38411 (GCVE-0-2025-38411)

Vulnerability from cvelistv5 – Published: 2025-07-25 13:20 – Updated: 2026-08-05 12:01

Title

netfs: Fix double put of request

Summary

In the Linux kernel, the following vulnerability has been resolved: netfs: Fix double put of request If a netfs request finishes during the pause loop, it will have the ref that belongs to the IN_PROGRESS flag removed at that point - however, if it then goes to the final wait loop, that will *also* put the ref because it sees that the IN_PROGRESS flag is clear and incorrectly assumes that this happened when it called the collector. In fact, since IN_PROGRESS is clear, we shouldn't call the collector again since it's done all the cleanup, such as calling ->ki_complete(). Fix this by making netfs_collect_in_app() just return, indicating that we're done if IN_PROGRESS is removed.

Severity

9.8 (Critical)


                        
                          CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

Assigner

Linux mitre root

References

2 references

URL	Tags
https://git.kernel.org/stable/c/d18facba5a5795ad4…
https://git.kernel.org/stable/c/9df7b5ebead649b00…

Impacted products

2 products

Vendor	Product	Version
Linux	Linux	Affected: 329ba1cb402ac328224965b8fc7a554a5150908e , < d18facba5a5795ad44b2a00a052e3db2fa77ab12 (git) Affected: 2b1424cd131cfaba4cf7040473133d26cddac088 , < 9df7b5ebead649b00bf9a53a798e4bf83a1318fd (git)
Linux	Linux	Affected: 6.15.3 , < 6.15.6 (semver)

Show details on NVD website

JSON

To clipboard

{
  "containers": {
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "product": "Linux",
          "programFiles": [
            "fs/netfs/misc.c",
            "include/trace/events/netfs.h"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "lessThan": "d18facba5a5795ad44b2a00a052e3db2fa77ab12",
              "status": "affected",
              "version": "329ba1cb402ac328224965b8fc7a554a5150908e",
              "versionType": "git"
            },
            {
              "lessThan": "9df7b5ebead649b00bf9a53a798e4bf83a1318fd",
              "status": "affected",
              "version": "2b1424cd131cfaba4cf7040473133d26cddac088",
              "versionType": "git"
            }
          ]
        },
        {
          "defaultStatus": "unaffected",
          "product": "Linux",
          "programFiles": [
            "fs/netfs/misc.c",
            "include/trace/events/netfs.h"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "lessThan": "6.15.6",
              "status": "affected",
              "version": "6.15.3",
              "versionType": "semver"
            }
          ]
        }
      ],
      "cpeApplicability": [
        {
          "nodes": [
            {
              "cpeMatch": [
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.15.6",
                  "versionStartIncluding": "6.15.3",
                  "vulnerable": true
                }
              ],
              "negate": false,
              "operator": "OR"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnetfs: Fix double put of request\n\nIf a netfs request finishes during the pause loop, it will have the ref\nthat belongs to the IN_PROGRESS flag removed at that point - however, if it\nthen goes to the final wait loop, that will *also* put the ref because it\nsees that the IN_PROGRESS flag is clear and incorrectly assumes that this\nhappened when it called the collector.\n\nIn fact, since IN_PROGRESS is clear, we shouldn\u0027t call the collector again\nsince it\u0027s done all the cleanup, such as calling -\u003eki_complete().\n\nFix this by making netfs_collect_in_app() just return, indicating that\nwe\u0027re done if IN_PROGRESS is removed."
        }
      ],
      "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 pause loop is entered only when `NETFS_RREQ_PAUSE` is set, which happens in `netfs_read_subreq_terminated()`/`netfs_write_collection()` in response to subrequest errors, short reads or retry conditions produced by the remote file server (cifs/SMB, 9p, AFS, Ceph). A malicious, compromised, or MITM\u0027d server drives the entire trigger sequence over the network with no local access.\nAC:L - The remote server controls both halves of the sequence \u2014 it chooses which subrequest to fail (setting PAUSE) and when to complete the remaining subrequests, so it can reliably make the request finish while the app thread is in the pause loop. Nothing depends on conditions outside the attacker\u0027s influence, and the attempt can be repeated on every read/write until it lands.\nPR:N - The attacker is the network peer itself (the file server or an on-path attacker on an unsigned/unencrypted SMB/9p connection) and needs no account, credentials, or privileges on the victim client. All processing happens in the client\u0027s normal I/O path with no capability check between the received response and the double put.\nUI:N - Once a share is mounted \u2014 an ordinary pre-existing system configuration, not a per-attack action \u2014 any routine read, readahead, direct I/O or write-through by any process on the client triggers the path. No victim interaction is needed at exploitation time, consistent with the adjacent netfs collection-path CVEs.\nS:U - The corrupted object is a kernel heap allocation (`struct netfs_io_request`) and the impact stays within the kernel\u0027s own security authority. There is no crossing of a VM, IOMMU, or sandbox boundary.\nC:H - The double `netfs_put_request()` drives the refcount to zero while the issuing thread still dereferences the request, reading `rreq-\u003eerror`, `-\u003etransferred`, `-\u003eorigin`, `-\u003esubmitted` and `-\u003elen` out of freed slab memory. Because `netfs_io_request` comes from a dedicated mempool that can be re-filled by attacker-paced requests, the reclaimed contents can be groomed to leak arbitrary kernel data.\nI:H - The premature free yields a use-after-free write \u2014 a `refcount_dec` and a second `queue_work()` on `rreq-\u003ecleanup_work` inside an object that has been reallocated \u2014 which corrupts workqueue list pointers and gives a controllable write primitive suitable for control-flow hijack. The second collector pass additionally re-invokes `-\u003eki_complete()` and `inode_dio_end()`, double-completing an AIO/io_uring request and underflowing `i_dio_count`.\nA:H - Even without grooming, the refcount underflow, double free and use-after-free reliably produce a refcount WARN, slab corruption, or kernel oops/panic, and the double `inode_dio_end()` underflow can wedge subsequent direct I/O on the inode. A hostile server can trigger it repeatedly to keep the client down."
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-08-05T12:01:40.641Z",
        "orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "shortName": "Linux"
      },
      "references": [
        {
          "url": "https://git.kernel.org/stable/c/d18facba5a5795ad44b2a00a052e3db2fa77ab12"
        },
        {
          "url": "https://git.kernel.org/stable/c/9df7b5ebead649b00bf9a53a798e4bf83a1318fd"
        }
      ],
      "title": "netfs: Fix double put of request",
      "x_generator": {
        "engine": "bippy-1.2.0"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
    "assignerShortName": "Linux",
    "cveId": "CVE-2025-38411",
    "datePublished": "2025-07-25T13:20:15.835Z",
    "dateReserved": "2025-04-16T04:51:24.013Z",
    "dateUpdated": "2026-08-05T12:01:40.641Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

Sightings

Author	Source	Type	Date	Other

Nomenclature

Seen: The vulnerability was mentioned, discussed, or observed by the user.
Confirmed: The vulnerability has been validated from an analyst's perspective.
Published Proof of Concept: A public proof of concept is available for this vulnerability.
Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
Not confirmed: The user expressed doubt about the validity of the vulnerability.
Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.

Detection rules are retrieved from Rulezet.

The MITRE ATT&CK techniques below are AI-generated suggestions, inferred from the description of the vulnerability by the CIRCL/vulnerability-attack-technique-classification-roberta-base model, served locally by ML-Gateway. They have not been verified by an analyst and are provided for guidance only.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.

Related by attack behaviour

Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.