CVE-2026-68158

What it actually does

This flaw is an integer multiplication overflow in the Linux kernel libceph OSD map decoder. A crafted CEPH_MSG_OSD_MAP message can provide a large length value that overflows the calculated size used for bounds checking in decode_new_up_state_weight(). Because the bounds check can be made incorrect, the kernel may perform out-of-bounds reads while decoding the corrupted OSD map. The most likely technical outcomes are kernel memory access faults, client instability, or denial of service; the advisory does not establish reliable remote code execution. Exploitation requires a vulnerable Linux kernel Ceph client to process a malicious or corrupted OSD map, typically from a compromised, malicious, or impersonated Ceph component able to send Ceph protocol messages to the client.

Why it matters to the business

Systems using the Linux kernel Ceph client could crash, hang, or lose access to Ceph-backed storage if they process a malicious OSD map. This can disrupt applications that depend on Ceph block, file, or object storage and may cause workload downtime or data access interruptions. The issue is newly published, is not currently listed in CISA KEV, has no known mature public exploit reported in the provided data, and is not flagged as ransomware-used; however, kernel-level storage client flaws should still be prioritized where Ceph is used in production because a storage outage can have broad operational impact.

How an attack unfolds

An attacker first needs a path to influence or deliver Ceph OSD map traffic to a vulnerable Linux kernel Ceph client. In realistic scenarios, this could involve compromising a Ceph monitor or other trusted Ceph infrastructure component, positioning as a man-in-the-middle where Ceph transport protections are weak or absent, or otherwise causing the client to accept a malformed CEPH_MSG_OSD_MAP message. The attacker crafts the OSD map so that the length field used for the new_state portion triggers a multiplication overflow during decoding. The vulnerable bounds calculation then underestimates or misvalidates the buffer area, and decode_new_up_state_weight() reads beyond the intended message bounds. Depending on surrounding memory layout and kernel behavior, this can result in a kernel fault, client crash, storage disconnect, or potentially exposure of unintended memory during processing. There are no provided indicators of active exploitation or named threat actors for this vulnerability.

How to fix it

Update affected Linux kernels to a vendor release that includes the upstream libceph fix for decode_new_up_state_weight(), specifically the change that uses checked multiplication, such as check_mul_overflow(), and rejects malformed OSD maps when the size calculation overflows. Because no exact fixed product versions were provided, use distribution advisories from the relevant OS vendor and confirm the kernel package includes the patch titled similar to "libceph: Fix multiplication overflow in decode_new_up_state_weight()". Reboot into the fixed kernel after installation. Where immediate patching is not possible, reduce exposure by restricting Ceph monitor/OSD/client traffic to trusted storage networks, enforcing Ceph authentication and secure messenger configuration where available, preventing untrusted hosts from reaching Ceph service ports, and disabling or unmounting kernel Ceph clients on systems that do not require them. Treat compromised Ceph infrastructure as high risk, because clients trust OSD map data from the cluster control plane.

How to confirm the fix worked

Confirm exposure by inventorying systems that use the Linux kernel Ceph client, including mounted CephFS filesystems and RBD devices using kernel modules. Verify the running kernel, not only the installed package, has been updated to a build containing the libceph overflow fix. Validation methods include checking the OS vendor advisory, inspecting kernel changelogs for "libceph: Fix multiplication overflow in decode_new_up_state_weight()", or confirming the source package uses checked multiplication in decode_new_up_state_weight(). After patching, reboot and verify the active kernel version with standard host inventory tools. Operationally, confirm Ceph mounts and RBD mappings still function normally and that vulnerable pre-patch kernels are no longer running on Ceph client systems.

Typical attack path

1. Identify Linux systems using the in-kernel Ceph client, such as CephFS or RBD mounts handled by the kernel.
2. Gain the ability to send or influence Ceph OSD map messages accepted by those clients, usually by compromising trusted Ceph infrastructure, abusing weak network segmentation, or intercepting unprotected Ceph traffic.
3. Craft a CEPH_MSG_OSD_MAP message with a corrupted OSD map whose length value causes multiplication overflow in the new_state size calculation.
4. Deliver the malformed OSD map to the vulnerable client.
5. Trigger out-of-bounds reads during decode_new_up_state_weight() in libceph.
6. Cause client instability, kernel crash, storage access interruption, or related denial-of-service effects.

How to detect it

There are no reliable, CVE-specific indicators of compromise in the provided advisory. Detection should focus on evidence that vulnerable Ceph clients processed malformed OSD map traffic or experienced kernel faults around Ceph message handling. Review kernel logs, system journals, crash dumps, Ceph client logs, and storage-network telemetry for kernel oops or panic events involving libceph, decode_new_up_state_weight(), OSD map decoding, or CEPH_MSG_OSD_MAP processing. Investigate unexplained CephFS/RBD disconnects, repeated client remounts, sudden storage I/O errors, or crashes occurring shortly after OSD map updates. Network teams should look for anomalous Ceph messenger traffic from unexpected hosts to monitor/OSD ports, especially unauthorized systems sending traffic to TCP 3300, 6789, or the OSD service range commonly used by Ceph. If a crash dump is available, confirm whether the stack trace includes libceph OSD map decoding functions. Also investigate the integrity of Ceph monitors and other control-plane nodes, because practical exploitation may require the attacker to influence trusted OSD map messages.

What your security team should do

• Prioritize identifying Linux hosts that use the in-kernel Ceph client for CephFS or RBD, especially production systems with critical storage dependencies.
• Patch and reboot Ceph client systems to a kernel build containing the libceph decode_new_up_state_weight() overflow fix as soon as vendor packages are available.
• Restrict Ceph protocol access to trusted storage networks and block untrusted access to Ceph monitor and OSD ports at network boundaries.
• Review Ceph authentication and messenger security settings to reduce the chance that a malicious or impersonated component can deliver trusted OSD maps.
• Monitor for kernel oops, panic, Ceph client disconnects, and abnormal OSD map processing errors on Ceph client hosts until patching is complete.
• Treat any suspected compromise of Ceph monitors or storage control-plane nodes as a potential client-impacting incident and investigate dependent clients for crashes or anomalous behavior.
• Do not rely on KEV status or exploit maturity alone for prioritization; storage-client kernel crashes can create high-impact outages even without public exploit code.