Skip to content
Heist/ feed
Back to feed
HighFix available

ceph: fix hanging __ceph_get_caps() with stale mds_wanted

Type: advisorySources: OSV

In the Linux kernel, the following vulnerability has been resolved: ceph: fix hanging __ceph_get_caps() with stale mds_wanted A reader can hang forever in __ceph_get_caps() when the client no longer holds `FILE_RD`, but local cap state still says that the capability is already wanted (via `mds_wanted`). One way to trigger this is through MDS cap revocation. If another client performs a conflicting operation, the MDS can revoke `FILE_RD` from the reader; the next read then has to reacquire `FILE_RD`. If the cap update that should request `FILE_RD` never reaches the MDS after `cap->mds_wanted` was raised, the reader is left holding only non-file caps while local `mds_wanted` still includes the file read caps. In that state, try_get_cap_refs() sees `need <= mds_wanted` and returns 0, so __ceph_get_caps() just waits on `i_cap_wq`. If the cap update that was supposed to request `FILE_RD never reaches the MDS after `cap->mds_wanted was` raised, no further request is sent and the waiter can sleep indefinitely until unrelated cap traffic happens to wake it up. The ordering issue is that `cap->mds_wanted` is updated in __prep_cap() before the `CEPH_MSG_CLIENT_CAPS message` is actually queued for send. That makes one field serve two different meanings at once: what this client wants, and what the client believes the MDS already knows it wants. A proper fix would be to split those states and track whether a cap update is actually in flight or has been observed by the MDS. However, simpl

Products
Kernel
Affected versions
Not specified
Fixed versions
5.10.266, 5.15.217, 6.1.184, 6.12.105, 6.18.46, 6.6.153, 7.1.10
CVEs
CVE-2026-80527
Confirmed fixed CVEs
Not specified
Updated in this feed
5 Nov 2026, 10:12 UTC · Revision 1

Source evidence

ceph: fix hanging __ceph_get_caps() with stale mds_wanted

core-osv · Original source

Published 26 Aug 2026, 14:37 UTC

In the Linux kernel, the following vulnerability has been resolved: ceph: fix hanging __ceph_get_caps() with stale mds_wanted A reader can hang forever in __ceph_get_caps() when the client no longer holds `FILE_RD`, but local cap state still says that the capability is already wanted (via `mds_wanted`). One way to trigger this is through MDS cap revocation. If another client performs a conflicting operation, the MDS can revoke `FILE_RD` from the reader; the next read then has to reacquire `FILE_RD`. If the cap update that should request `FILE_RD` never reaches the MDS after `cap->mds_wanted` was raised, the reader is left holding only non-file caps while local `mds_wanted` still includes the file read caps. In that state, try_get_cap_refs() sees `need <= mds_wanted` and returns 0, so __ceph_get_caps() just waits on `i_cap_wq`. If the cap update that was supposed to request `FILE_RD never reaches the MDS after `cap->mds_wanted was` raised, no further request is sent and the waiter can sleep indefinitely until unrelated cap traffic happens to wake it up. The ordering issue is that `cap->mds_wanted` is updated in __prep_cap() before the `CEPH_MSG_CLIENT_CAPS message` is actually queued for send. That makes one field serve two different meanings at once: what this client wants, and what the client believes the MDS already knows it wants. A proper fix would be to split those states and track whether a cap update is actually in flight or has been observed by the MDS. However, simpl

osv:CVE-2026-80527

Kernel

Fixed versions: 5.10.266, 5.15.217, 6.1.184, 6.6.153, 6.12.105, 6.18.46, 7.1.10

Complete source record
{
  "id": "7f6fc5d7d779bba5290df8b8ba1a9a914555449e908391b2318498ea9e31f2fa",
  "url": "https://osv.dev/vulnerability/CVE-2026-80527",
  "method": "structured",
  "payload": {
    "kind": "advisory",
    "title": "ceph: fix hanging __ceph_get_caps() with stale mds_wanted",
    "summary": "In the Linux kernel, the following vulnerability has been resolved: ceph: fix hanging __ceph_get_caps() with stale mds_wanted A reader can hang forever in __ceph_get_caps() when the client no longer holds `FILE_RD`, but local cap state still says that the capability is already wanted (via `mds_wanted`). One way to trigger this is through MDS cap revocation. If another client performs a conflicting operation, the MDS can revoke `FILE_RD` from the reader; the next read then has to reacquire `FILE_RD`. If the cap update that should request `FILE_RD` never reaches the MDS after `cap->mds_wanted` was raised, the reader is left holding only non-file caps while local `mds_wanted` still includes the file read caps. In that state, try_get_cap_refs() sees `need <= mds_wanted` and returns 0, so __ceph_get_caps() just waits on `i_cap_wq`. If the cap update that was supposed to request `FILE_RD never reaches the MDS after `cap->mds_wanted was` raised, no further request is sent and the waiter can sleep indefinitely until unrelated cap traffic happens to wake it up. The ordering issue is that `cap->mds_wanted` is updated in __prep_cap() before the `CEPH_MSG_CLIENT_CAPS message` is actually queued for send. That makes one field serve two different meanings at once: what this client wants, and what the client believes the MDS already knows it wants. A proper fix would be to split those states and track whether a cap update is actually in flight or has been observed by the MDS. However, simpl",
    "evidence": "osv:CVE-2026-80527",
    "products": [
      {
        "name": {
          "value": "Kernel",
          "evidence": "/affected/1/package/name"
        },
        "prerequisites": [],
        "fixed_versions": [
          {
            "value": "5.10.266",
            "evidence": "/affected/1/ranges"
          },
          {
            "value": "5.15.217",
            "evidence": "/affected/1/ranges"
          },
          {
            "value": "6.1.184",
            "evidence": "/affected/1/ranges"
          },
          {
            "value": "6.6.153",
            "evidence": "/affected/1/ranges"
          },
          {
            "value": "6.12.105",
            "evidence": "/affected/1/ranges"
          },
          {
            "value": "6.18.46",
            "evidence": "/affected/1/ranges"
          },
          {
            "value": "7.1.10",
            "evidence": "/affected/1/ranges"
          }
        ],
        "affected_versions": []
      }
    ],
    "severity": "high",
    "structured": {
      "id": "CVE-2026-80527",
      "aliases": [
        "CVE-2026-80527"
      ],
      "metrics": [
        {
          "type": "CVSS_V3",
          "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H"
        }
      ],
      "affected": [
        {
          "ranges": [
            {
              "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
              "type": "GIT",
              "events": [
                {
                  "introduced": "0a454bdd501ad1aa30bb72e9581efa338ad6ce5c"
                },
                {
                  "fixed": "b5661524c5a45085a866864ca9b8ae2513dfd67a"
                },
                {
                  "fixed": "5e84bc6f67e19fdd192d8b215de728acbfc12572"
                },
                {
                  "fixed": "5fedf279a1ea369d39c8b06dd4547cdc576065d0"
                },
                {
                  "fixed": "e05c315b4da0c16ea800ee4b2cb6c617f586d1b5"
                },
                {
                  "fixed": "fcce1b3be6d286aa80831e730289f4c062053ae6"
                },
                {
                  "fixed": "a3bc6b3e9ef3f5f5cb85a902a30a090c7931127c"
                },
                {
                  "fixed": "9e55fe24c548ad3163903eb58bb002d28d32a630"
                },
                {
                  "fixed": "50958bb928bad3bdba9e5d1b7ff4bbadcf6951e6"
                }
              ]
            }
          ],
          "database_specific": {
            "source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-80527.json"
          }
        },
        {
          "ranges": [
            {
              "type": "ECOSYSTEM",
              "events": [
                {
                  "introduced": "5.8.0"
                },
                {
                  "fixed": "5.10.266"
                }
              ]
            },
            {
              "type": "ECOSYSTEM",
              "events": [
                {
                  "introduced": "5.11.0"
                },
                {
                  "fixed": "5.15.217"
                }
              ]
            },
            {
              "type": "ECOSYSTEM",
              "events": [
                {
                  "introduced": "5.16.0"
                },
                {
                  "fixed": "6.1.184"
                }
              ]
            },
            {
              "type": "ECOSYSTEM",
              "events": [
                {
                  "introduced": "6.2.0"
                },
                {
                  "fixed": "6.6.153"
                }
              ]
            },
            {
              "type": "ECOSYSTEM",
              "events": [
                {
                  "introduced": "6.7.0"
                },
                {
                  "fixed": "6.12.105"
                }
              ]
            },
            {
              "type": "ECOSYSTEM",
              "events": [
                {
                  "introduced": "6.13.0"
                },
                {
                  "fixed": "6.18.46"
                }
              ]
            },
            {
              "type": "ECOSYSTEM",
              "events": [
                {
                  "introduced": "6.19.0"
                },
                {
                  "fixed": "7.1.10"
                }
              ]
            }
          ],
          "package": {
            "name": "Kernel",
            "ecosystem": "Linux"
          },
          "database_specific": {
            "source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-80527.json"
          }
        }
      ],
      "modified": "2026-10-28T02:30:43.700464473Z",
      "provider": "osv",
      "references": [
        "https://git.kernel.org/stable/c/50958bb928bad3bdba9e5d1b7ff4bbadcf6951e6",
        "https://git.kernel.org/stable/c/5e84bc6f67e19fdd192d8b215de728acbfc12572",
        "https://git.kernel.org/stable/c/5fedf279a1ea369d39c8b06dd4547cdc576065d0",
        "https://git.kernel.org/stable/c/9e55fe24c548ad3163903eb58bb002d28d32a630",
        "https://git.kernel.org/stable/c/a3bc6b3e9ef3f5f5cb85a902a30a090c7931127c",
        "https://git.kernel.org/stable/c/b5661524c5a45085a866864ca9b8ae2513dfd67a",
        "https://git.kernel.org/stable/c/e05c315b4da0c16ea800ee4b2cb6c617f586d1b5",
        "https://git.kernel.org/stable/c/fcce1b3be6d286aa80831e730289f4c062053ae6",
        "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/80xxx/CVE-2026-80527.json",
        "https://nvd.nist.gov/vuln/detail/CVE-2026-80527",
        "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git"
      ],
      "provider_metadata": {
        "cna_assigner": "Linux",
        "osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/80xxx/CVE-2026-80527.json"
      }
    },
    "related_cves": [
      {
        "value": "CVE-2026-80527",
        "evidence": "/id"
      }
    ],
    "security_relevant": true,
    "severity_evidence": "/severity/0/score"
  },
  "source_id": "core-osv",
  "document_id": 511586,
  "published_at": "2026-08-26T14:37:06.178+00:00"
}