CVE-2026-43407

What it actually does

This flaw is an out-of-bounds read in the Linux kernel libceph authentication reply handler. A crafted CEPH_MSG_AUTH_REPLY message can set payload_len to a value greater than INT_MAX; because the vulnerable code stores that length in a signed int, the value can wrap negative and cause pointer arithmetic to move backward before subsequent parsing. The added bounds checks in the fix prevent payload_len and result_msg_len from exceeding the containing message segment. Practical impact is kernel memory corruption behavior in the Ceph client path, most notably kernel crash or panic and potential disclosure of kernel memory contents; the CVSS vector indicates network reachability, no privileges, no user interaction, high confidentiality impact, and high availability impact, with no expected integrity impact.

Why it matters to the business

Systems using the Linux kernel Ceph client stack, including CephFS or RBD consumers, may be crashed or exposed to kernel memory disclosure if they process a malicious authentication reply from a hostile, spoofed, compromised, or man-in-the-middle Ceph monitor endpoint. This can disrupt storage-backed workloads, cause service outages, and potentially expose sensitive data resident in kernel memory. Although this issue is not currently listed in CISA KEV, is not marked as ransomware-used, has low EPSS, and has no known public exploit maturity in the provided data, the high CVSS score and unauthenticated network attack characteristics make timely kernel remediation important for Ceph-connected environments.

How an attack unfolds

An attacker first needs a path to deliver a malicious Ceph authentication reply to a vulnerable kernel Ceph client. This is most plausible where the attacker controls a Ceph monitor endpoint, compromises a legitimate monitor, poisons or redirects monitor connectivity, or performs a network man-in-the-middle attack during Ceph client authentication. The attacker sends a CEPH_MSG_AUTH_REPLY message with a payload_len value larger than INT_MAX and inconsistent length fields. On vulnerable kernels, libceph stores the oversized length in a signed integer, causing integer overflow and negative length interpretation. The parsing logic then computes an invalid pointer location and may read outside the intended slab allocation when ceph_decode_need() evaluates the bounds. The resulting behavior can include a KASAN slab-out-of-bounds report, kernel oops, panic, or other Ceph client instability; depending on surrounding conditions, the out-of-bounds read may also expose kernel memory contents.

How to fix it

Upgrade to a Linux kernel build that contains the libceph fix for ceph_handle_auth_reply(), specifically the change that stores payload_len and result_msg_len as unsigned 32-bit values and validates those lengths against the overall segment length before parsing. Because no exact fixed package versions were provided, obtain the patched kernel from the relevant Linux distribution, vendor kernel stream, or upstream stable branch once available for the deployed release. Reboot systems after installing the fixed kernel, because the vulnerable code resides in kernel space. If immediate patching is not possible, reduce exposure by restricting Ceph monitor connectivity to trusted networks, preventing untrusted systems from acting as Ceph monitors, enforcing network segmentation and authentication around storage networks, disabling unused CephFS/RBD clients, and monitoring for unexpected Ceph monitor endpoint changes or authentication failures. These mitigations reduce exploitability but do not replace the kernel fix.

How to confirm the fix worked

Confirm remediation by verifying that affected systems are running a kernel package or image that includes the libceph bounds-checking fix for ceph_handle_auth_reply(). Validate through vendor advisories, kernel changelogs, package metadata, or source inspection showing payload_len and result_msg_len are handled as u32 and checked against the segment length. After reboot, confirm the active kernel version with standard OS tooling and verify Ceph workloads reconnect normally. To detect remaining exposure, inventory systems with loaded or available Ceph client components, active CephFS mounts, RBD mappings, or libceph module usage. Review whether any vulnerable kernels remain in bootloader entries, golden images, container hosts, hypervisors, or storage clients. Where packet inspection is available, test controls by alerting on CEPH_MSG_AUTH_REPLY messages with implausibly large payload_len values, especially values above 0x7fffffff.

Typical attack path

1. Identify systems that use the Linux kernel Ceph client stack, such as CephFS mounts or RBD mappings.
2. Gain the ability to send traffic that the client treats as coming from a Ceph monitor, by controlling a monitor, compromising one, redirecting client configuration, spoofing traffic, or intercepting the network path.
3. Wait for or trigger Ceph client authentication or reconnection activity.
4. Send a crafted CEPH_MSG_AUTH_REPLY message with payload_len greater than INT_MAX and malformed segment length relationships.
5. Trigger integer overflow in ceph_handle_auth_reply() when the oversized length is stored as a signed int.
6. Cause pointer miscalculation and an out-of-bounds read in libceph message parsing.
7. Achieve denial of service through kernel crash or instability, and potentially expose kernel memory contents.

How to detect it

Look for evidence of prior exploitation in kernel logs, system journals, crash dumps, KASAN reports, and Ceph client logs. High-signal artifacts include kernel oops or panic events with stack traces referencing libceph and ceph_handle_auth_reply(), especially during Ceph authentication, monitor reconnects, or mount/RBD mapping operations. Review /var/log/kern.log, /var/log/messages, /var/log/syslog, journalctl -k output, kdump/vmcore data, and centralized EDR/SIEM telemetry for slab-out-of-bounds reports and Ceph messenger workqueue failures. Correlate any such crashes with network logs showing Ceph monitor connections, unexpected monitor IPs, authentication reply traffic, or repeated disconnect/reconnect activity. If packet captures, Zeek, Suricata, or custom protocol parsers are available, inspect Ceph authentication reply messages for payload_len or result_msg_len values that exceed the containing segment or payload_len values greater than 0x7fffffff. Also investigate any recent changes to Ceph monitor DNS records, client configuration, routing, or certificates/keys that could indicate redirection to a malicious monitor. Named threat actor activity was not provided, and the vulnerability is not currently flagged as KEV or ransomware-used, so detections should focus on exploit artifacts rather than actor-specific infrastructure.

• KASAN: slab-out-of-bounds in ceph_handle_auth_reply
• ceph_handle_auth_reply+0x642/0x7a0 [libceph]
• BUG: KASAN: slab-out-of-bounds
• Read of size 4 at addr
• Workqueue: ceph-msgr ceph_con_workfn [libceph]
• mon_dispatch+0x973/0x23d0 [libceph]
• ceph_con_process_message+0x1f1/0x650 [libceph]
• process_message+0x1e/0x450 [libceph]
• ceph_con_v2_try_read+0x2e48/0x6c80 [libceph]
• ceph_con_workfn+0x248/0x10c0 [libceph]
• CEPH_MSG_AUTH_REPLY
• payload_len > 0x7fffffff
• result_msg_len greater than segment length
• libceph
• ceph-msgr

What your security team should do

• Prioritize patching Linux systems that use CephFS, RBD, or other kernel libceph functionality, especially those on shared, untrusted, or routable networks.
• Inventory active Ceph client usage by checking for mounted CephFS filesystems, mapped RBD devices, loaded ceph/libceph modules, and configured monitor endpoints.
• Restrict Ceph monitor communication to trusted storage networks and enforce firewall rules so clients only connect to authorized monitor addresses.
• Review Ceph monitor configuration and DNS/service-discovery mechanisms for unauthorized or unexpected monitor endpoints.
• Add SOC detections for kernel oops, panic, KASAN, or libceph stack traces involving ceph_handle_auth_reply(), mon_dispatch(), ceph_con_process_message(), or ceph_con_workfn().
• Hunt historical logs for Ceph authentication failures, sudden client disconnect/reconnect loops, and crashes correlated with Ceph monitor traffic.
• Because the issue is 95 days past publication and has high technical severity despite low EPSS and no KEV listing, include it in the next urgent kernel maintenance cycle for Ceph-connected systems.
• If patching is delayed, isolate Ceph clients and monitors from untrusted networks and consider temporarily disabling nonessential Ceph client usage.