Linux Kernel CVE-2026-43407

Victim Linux system must be actively configured to use Ceph distributed storage with libceph kernel module loaded and communicating with Ceph monitors. Exploitation requires either: (1) attacker operates malicious Ceph monitor accessible to victim system, achievable via man-in-the-middle position on network path between client and legitimate monitor, or DNS/routing manipulation to redirect monitor connections, or (2) attacker compromises existing legitimate Ceph monitor in the victim's storage cluster and modifies its authentication response handling. Attack is remote (AV:N) with no authentication required (PR:N) from network perspective, but practical exploitation is limited by necessity of victim-monitor communication relationship. Default Ceph deployments communicating only with trusted, isolated monitors on dedicated storage networks significantly reduce attack surface. Systems with libceph compiled into kernel but not actively mounting Ceph filesystems or using RBD devices are not exploitable despite running vulnerable code. No special user interaction (UI:N) needed once client-monitor connection is established.

While CVSS 9.1 (Critical) with vector AV:N/AC:L/PR:N/UI:N suggests severe risk, real-world exploitability is constrained by deployment context. The EPSS score of 0.02% (7th percentile) indicates very low observed exploitation probability in the wild, and no CISA KEV listing confirms this is not actively exploited against production systems. However, technical impact assessment reveals genuine risk: successful exploitation allows remote unauthenticated attackers to trigger kernel memory corruption without user interaction. The attack complexity is low (AC:L) and requires no privileges (PR:N), but critically depends on the victim system actively communicating with a malicious or compromised Ceph monitor. This significantly limits the attack surface compared to typical network services. Organizations using Ceph storage clusters (object storage, RBD block devices, or CephFS) face moderate priority for patching, especially if monitors are not fully trusted or network-isolated. Systems not using Ceph are completely unaffected despite running vulnerable kernel versions. The SSVC framework suggests 'scheduled' priority: exploitation is not automatable at scale (requires specific victim-monitor relationship), technical impact is significant (kernel memory corruption), but no evidence of active exploitation exists. Priority increases for Ceph deployments in multi-tenant environments or where monitors are exposed to untrusted networks. Vulnerability has existed since initial Ceph integration (commit 1da177e4c3f4, Linux 2.6.12-rc2, 2005), affecting nearly 20 years of kernel releases, yet absence of exploitation suggests attackers either haven't identified value in targeting Ceph monitor protocols or the deployment-specific prerequisites limit practical exploitation.

An attacker compromises or operates a rogue Ceph monitor server on a network segment accessible to victim Linux systems running Ceph clients. When the victim's kernel libceph module initiates authentication with the malicious monitor, the attacker sends a crafted CEPH_MSG_AUTH_REPLY message with payload_len field set to 0xFFFFFFFF (4,294,967,295), causing integer overflow to negative value in the kernel's signed int variable. The ceph_handle_auth_reply() function then decrements the message pointer by this underflowed value and attempts memory access, triggering out-of-bounds read. This can leak sensitive kernel memory contents to the attacker or crash the system kernel panic. No proof-of-concept code is publicly identified at time of analysis, but exploitation is straightforward for attackers with network protocol manipulation capability.