GHSA-PRV5-G54G-RMHH
Vulnerability from github – Published: 2026-09-17 18:31 – Updated: 2026-09-18 18:31In the Linux kernel, the following vulnerability has been resolved:
libceph: validate banner payload length
When parsing the Ceph messenger v2 protocol banner, the payload_len field
is decoded from the banner prefix. If a client sends a banner with a
payload_len of 0, the kernel sets up a 0-length socket read. This
violates an invariant in the state machine, triggering a warning in
populate_in_iter():
------------[ cut here ]------------ !iov_iter_count(&con->v2.in_iter) WARNING: net/ceph/messenger_v2.c:3129 at populate_in_iter net/ceph/messenger_v2.c:3129 [inline], CPU#1: kworker/1:3/5070 WARNING: net/ceph/messenger_v2.c:3129 at ceph_con_v2_try_read+0x6634/0x6810 net/ceph/messenger_v2.c:3159, CPU#1: kworker/1:3/5070 ... Call Trace: ceph_con_workfn+0x1f5/0x14a0 net/ceph/messenger.c:1575 process_one_work kernel/workqueue.c:3322 [inline] process_scheduled_works+0xa8e/0x14e0 kernel/workqueue.c:3405 worker_thread+0xa47/0xfb0 kernel/workqueue.c:3486 kthread+0x388/0x470 kernel/kthread.c:436 ret_from_fork+0x514/0xb70 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
According to the msgr2 protocol specification, the banner payload is
expected to contain at least two 64-bit integers (server_feat and
server_req_feat). Therefore, payload_len must be at least 16 bytes.
Fix this by adding a check in process_banner_prefix() to reject a
payload_len smaller than 16 bytes. This prevents the 0-length read and
correctly aborts the connection with a protocol error.
{
"affected": [],
"aliases": [
"CVE-2026-90067"
],
"database_specific": {
"cwe_ids": [],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-09-17T17:16:55Z",
"severity": "HIGH"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nlibceph: validate banner payload length\n\nWhen parsing the Ceph messenger v2 protocol banner, the `payload_len` field\nis decoded from the banner prefix. If a client sends a banner with a\n`payload_len` of 0, the kernel sets up a 0-length socket read. This\nviolates an invariant in the state machine, triggering a warning in\n`populate_in_iter()`:\n\n------------[ cut here ]------------\n!iov_iter_count(\u0026con-\u003ev2.in_iter)\nWARNING: net/ceph/messenger_v2.c:3129 at populate_in_iter\nnet/ceph/messenger_v2.c:3129 [inline], CPU#1: kworker/1:3/5070\nWARNING: net/ceph/messenger_v2.c:3129 at ceph_con_v2_try_read+0x6634/0x6810\nnet/ceph/messenger_v2.c:3159, CPU#1: kworker/1:3/5070\n...\nCall Trace:\n \u003cTASK\u003e\n ceph_con_workfn+0x1f5/0x14a0 net/ceph/messenger.c:1575\n process_one_work kernel/workqueue.c:3322 [inline]\n process_scheduled_works+0xa8e/0x14e0 kernel/workqueue.c:3405\n worker_thread+0xa47/0xfb0 kernel/workqueue.c:3486\n kthread+0x388/0x470 kernel/kthread.c:436\n ret_from_fork+0x514/0xb70 arch/x86/kernel/process.c:158\n ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245\n \u003c/TASK\u003e\n\nAccording to the msgr2 protocol specification, the banner payload is\nexpected to contain at least two 64-bit integers (`server_feat` and\n`server_req_feat`). Therefore, `payload_len` must be at least 16 bytes.\n\nFix this by adding a check in `process_banner_prefix()` to reject a\n`payload_len` smaller than 16 bytes. This prevents the 0-length read and\ncorrectly aborts the connection with a protocol error.",
"id": "GHSA-prv5-g54g-rmhh",
"modified": "2026-09-18T18:31:26Z",
"published": "2026-09-17T18:31:49Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-90067"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/279c0852999fd2384f4a88155091a99e81f96873"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3b2e62a7655d347a845a91155610ddae11daffc6"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6cf666e47f2b51d5a887ec8a3226cde951757d27"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6d1c6f228854aa89844fd0152d7ed7ac72a55e89"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c1b937ff24b19e69aa7fb1b0f46a74d4c9668692"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c77633a9595658210a6e216a071e5a396a0835a7"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f374967fcdf04001c9b66df1c19106fa83cd91f7"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
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.
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.