CVE-2026-46119

What it actually does

This vulnerability affects the Linux kernel Ceph client authentication path in libceph. A malformed CEPH_MSG_AUTH_REPLY message with a positive result value can be incorrectly treated as an error value and later reused as the length of an outbound authentication message front segment. If that value is larger than the allocated front-buffer size, the kernel reads beyond the allocated slab buffer and sends adjacent kernel memory contents to the peer. The primary impact is kernel memory disclosure over the network, with potential kernel instability or denial of service depending on allocator state, hardening features, and error handling.

Why it matters to the business

Systems that use the in-kernel Ceph client for CephFS, RBD, or related Ceph-backed storage could leak sensitive kernel memory to a malicious or compromised Ceph endpoint. Exposed data may include secrets, credentials, cryptographic material, file-system metadata, or other tenant/application-adjacent memory depending on workload and memory layout. Because the flaw is remotely reachable in the storage authentication path and requires no local user interaction, affected storage clients should be treated as high priority even though public exploitation is not currently reported and the CVE is not listed in CISA KEV.

How an attack unfolds

An attacker positions themselves as a Ceph monitor or other endpoint involved in the client authentication exchange, compromises a legitimate Ceph service, or intercepts and manipulates traffic before authentication completes. When a vulnerable Linux kernel Ceph client initiates authentication, the attacker returns a crafted CEPH_MSG_AUTH_REPLY containing a positive result field that exceeds the size of the preallocated authentication message front buffer. The vulnerable client mishandles that positive value, treats it as a length for a subsequent outbound CEPH_MSG_AUTH message, reads past the end of the allocated slab buffer, and transmits memory beyond the intended authentication buffer back to the attacker-controlled peer. The attacker collects the leaked bytes and may repeat the exchange to harvest additional kernel memory. In some cases, malformed exchanges may also trigger kernel warnings, crashes, or client-side storage disruption.

How to fix it

Upgrade affected Linux kernels to a version containing the libceph fix for auth message processing. Use distribution-vendor kernel advisories and package repositories as the source of truth because fixed versions vary by distribution and kernel branch; no exact fixed package versions were provided in the input. After patching, reboot or live-patch where supported to ensure the running kernel includes the fix. As compensating controls, restrict Ceph monitor and storage network access to trusted hosts only, isolate Ceph traffic on dedicated networks, block untrusted access to Ceph monitor ports, validate Ceph monitor endpoints and configurations, and remove or disable unused CephFS/RBD kernel-client usage on systems that do not require it.

How to confirm the fix worked

Confirm that the running kernel, not only the installed package, includes the vendor fix for libceph authentication handling. Validate with package manager metadata, distribution security advisories, and the active kernel version reported by the system. Inventory systems for in-kernel Ceph client usage by checking for CephFS mounts, mapped RBD devices, loaded Ceph-related kernel modules, and active connections to Ceph monitor ports. Where practical, test in a non-production environment that malformed or abnormal Ceph authentication replies no longer result in kernel slab out-of-bounds reports, unexpected authentication message lengths, or client crashes. Confirm network controls limit Ceph monitor access to authorized storage clients and cluster nodes only.

Typical attack path

1. Identify Linux systems using the in-kernel Ceph client, such as CephFS mounts, RBD mappings, or kernel-based Ceph storage integrations.
2. Gain the ability to act as, compromise, spoof, or intercept a Ceph monitor/authentication endpoint reachable by the client.
3. Wait for or trigger a Ceph client authentication attempt.
4. Send a crafted CEPH_MSG_AUTH_REPLY with a positive result field larger than the allocated authentication front-buffer length.
5. Receive the client's follow-up CEPH_MSG_AUTH message containing unintended kernel memory beyond the allocated buffer.
6. Repeat the authentication manipulation to collect more leaked memory or induce instability in the client.

How to detect it

Post-exploitation evidence may be limited because the main effect is unintended memory being sent during Ceph authentication, which may not be logged by default. Review kernel logs, system journals, Ceph client logs, Ceph monitor logs, network telemetry, and packet captures around Ceph authentication failures or reconnect storms. Look for kernel warnings or crashes involving libceph, auth reply handling, slab-out-of-bounds reads, KASAN reports, BUG/Oops messages, or unusual authentication message sizes. On the network, investigate Ceph monitor traffic to unexpected IPs, unexpected use of TCP ports 3300 or 6789, repeated failed authentication handshakes, or connections to Ceph endpoints not present in approved cluster configuration. If packet capture is available, inspect authentication exchanges for CEPH_MSG_AUTH_REPLY messages with anomalous positive result values followed by oversized CEPH_MSG_AUTH client messages. If a malicious or compromised Ceph endpoint is suspected, preserve client kernel logs, Ceph monitor logs, firewall flow logs, DNS logs, routing changes, and packet captures, then rotate credentials and secrets that may have been resident in kernel memory.

• KASAN: slab-out-of-bounds
• BUG: KASAN: slab-out-of-bounds
• slab-out-of-bounds
• ceph_handle_auth_reply
• handle_auth_reply
• __send_prepared_auth_request
• CEPH_MSG_AUTH_REPLY
• CEPH_MSG_AUTH
• libceph
• front_alloc_len
• kernel BUG
• Oops:
• ceph-mon
• mount.ceph
• rbd-nbd
• tcp/3300
• tcp/6789

What your security team should do

• Prioritize patching Linux systems that use CephFS, RBD, or other in-kernel Ceph client functionality, especially those connected to shared, multi-tenant, or less-trusted storage networks.
• Identify all systems with loaded Ceph kernel components, active CephFS mounts, mapped RBD devices, or outbound connections to Ceph monitor ports 3300 and 6789.
• Restrict Ceph monitor and storage-plane connectivity with host firewalls, security groups, ACLs, or network segmentation so only approved clients can communicate with Ceph services.
• Review Ceph monitor endpoint configuration for unexpected hosts, DNS changes, routing changes, or signs of traffic interception.
• Monitor kernel logs for slab out-of-bounds, KASAN, BUG, Oops, or panic messages referencing libceph authentication functions.
• If suspicious malformed authentication activity is found, treat the affected client as potentially having leaked kernel memory and rotate exposed secrets that may have resided in memory.
• Because EPSS is currently low and the vulnerability is not in KEV, prioritize based on actual Ceph client exposure rather than internet-wide risk; still treat exposed storage clients as high impact due to CVSS 9.1 confidentiality and availability impact.