Look up another CVE · open CVE-2026-90067 in the interactive tracker
CVE-2026-90067
libceph: validate banner payload length
Published 2026-09-17 (31 days ago) by the Linux kernel CNA. Subsystem net/ceph. Debian urgency: not yet assigned.
What to do, per Debian release
Debian's own status for CVE-2026-90067 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source
| Release | Status | Version | What this means |
|---|---|---|---|
| Debian 12bookworm | fixedDLA-4841-1 · 2026-10-17 · text | 6.1.190-1 | Update the kernel and reboot. DLA-4841-1 shipped the fix on 2026-10-17, in 6.1.190-1. A running kernel keeps the old code until the machine restarts. |
| Debian 13trixie | fixedDSA-6528-1 · 2026-09-29 · text | 6.12.111-1 | Update the kernel and reboot. DSA-6528-1 shipped the fix on 2026-09-29, in 6.12.111-1. A running kernel keeps the old code until the machine restarts. |
| Debian 14forky | fixed | 7.2.6-1 | Update the kernel and reboot. Fixed in 7.2.6-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.2.6-1 | Update the kernel and reboot. Fixed in 7.2.6-1. A running kernel keeps the old code until the machine restarts. |
| Debian 12bookworm · linux-6.12 | fixedDLA-4817-1 · 2026-10-04 · text | 6.12.111-1~deb12u1 | Update the kernel and reboot. DLA-4817-1 shipped the fix on 2026-10-04, in 6.12.111-1~deb12u1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
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: <TASK> 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 </TASK> 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.
Where it lives
The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.
net/ceph/messenger_v2.c
- What this is
- CEPH COMMON CODE (LIBCEPH)MAINTAINERS section matched on net/ceph/ · ceph-devel@vger.kernel.org · Supported
- Kernel module
- libceph
Check it on the machine
grep -w CONFIG_CEPH_LIB /boot/config-$(uname -r)Reads the booted kernel's own configuration, on the machine and nowhere else. =y is built in, =m is a module, and an is not set line means the code is not there.
lsmod | grep -w libcephPrints a line if that module is loaded right now, and nothing if it is not. One that is not loaded can still be loaded later by anything that needs it.
Show whether Debian builds this, per release
Debian builds this as a loadable module. Every release below compiles it as a module on every flavour, so whether the code is in the running kernel depends on whether that module is loaded.
- bookworm, trixie, forky, sid, bookworm · linux-6.12m
- m
- a loadable module on every flavour - check lsmod, can be blacklisted
- Build switch
- CONFIG_CEPH_LIB
From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS kbuild Makefiles Debian linux-config packages
Signals
- Published
- 2026-09-17 (31 days ago)source
- CVSS
- 7.5 high
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:Hsource recompute it - Attack vector
- network (AV:N)source
- EPSS
- 0.67%, higher than 51.0% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- not yet assignedsource
- Subsystem
- net/ceph
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 5.11 | 5.15.221 | 279c0852999f |
| 5.11 | 6.1.188 | 6cf666e47f2b |
| 5.11 | 6.6.157 | 3b2e62a7655d |
| 5.11 | 6.12.110 | c1b937ff24b1 |
| 5.11 | 6.18.52 | 6d1c6f228854 |
| 5.11 | 7.2.6 | c77633a95956 |
| 5.11 | 7.3 | f374967fcdf0 |
Debian advisories
| Advisory | Date | Shipped to | Debian |
|---|---|---|---|
| DLA-4841-1 | 2026-10-17 | bookworm 6.1.190-1 | tracker |
| DLA-4817-1 | 2026-10-04 | bookworm 6.12.111-1~deb12u1 | tracker |
| DSA-6528-1 | 2026-09-29 | trixie 6.12.111-1 | tracker |
Why the CNA scored it this way
Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source
- AV:NAttack vector, network
- The attacker-controlled field is the 16-bit payload_len in the msgr2 banner prefix ("ceph v2\n" plus le16) that process_banner_prefix() decodes from bytes received by ceph_con_v2_try_read() on the TCP socket opened by ceph_tcp_connect() in ceph_con_v2_try_write(); a remote MON/OSD/MDS peer sends that banner over routable IP.
- AC:LAttack complexity, low
- The TCP peer fully controls the banner prefix and can set payload_len to 0, so prepare_read_banner_payload() installs a zero-length in_iter and populate_in_iter() hits WARN_ON(!iov_iter_count(&con->v2.in_iter)) on every such handshake; no race or layout outside the attacker’s control is required.
- PR:NPrivileges required, none
- process_banner_prefix() runs in CEPH_CON_S_V2_BANNER_PREFIX, before prepare_hello() and before CEPH_CON_S_V2_AUTH, so the malformed payload_len is processed prior to Cephx or any other credential check; the attacker is the remote TCP peer and needs no account on the victim host.
- UI:NUser interaction, none
- Once a kernel CephFS or RBD client is running, __open_session(), reopen_osd(), and MDS ceph_con_open() automatically TCP-reconnect and ceph_con_workfn() reads the peer banner with no further victim action; a compromised cluster daemon triggers the bug on that reconnect.
- S:UScope, unchanged
- The WARN_ON in populate_in_iter() and the resulting connection fault remain inside the victim kernel’s libceph messenger and do not cross a VM, IOMMU, or sandbox boundary.
- C:NConfidentiality impact, none
- A zero payload_len only makes populate_in_iter() WARN and return -ENODATA after prepare_read_banner_payload() sets up an empty in_iter; the path does not perform an out-of-bounds read, UAF, or other kernel-memory disclosure.
- I:NIntegrity impact, none
- prepare_read_banner_payload() with payload_len 0 never writes past an allocated buffer, and the failure path only faults the connection; attacker input does not corrupt kernel memory or hijack control flow.
- A:HAvailability impact, high
- WARN_ON(!iov_iter_count(&con->v2.in_iter)) in populate_in_iter() after a zero-length banner payload is an attacker-triggerable kernel warning that panics the host when panic_on_warn is set, and the -ENODATA return through ceph_con_v2_try_read() into con_fault() aborts every msgr2 handshake.