ceph: fix hanging __ceph_get_caps() with stale mds_wanted
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 sourcePublished 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"
}