CVE-2023-44466

What it actually does

This flaw is an integer signedness error in the Linux kernel Ceph Messenger v2 implementation in net/ceph/messenger_v2.c before Linux 6.4.5. An untrusted length value parsed from a TCP packet by ceph_decode_32 can be interpreted incorrectly during processing of HELLO or AUTH frames, causing a buffer overflow in kernel context. Successful exploitation can corrupt kernel memory and may allow remote code execution with kernel privileges, or at minimum trigger a kernel crash. Because the affected code runs in the kernel networking/storage stack, compromise can affect confidentiality, integrity, and availability of the entire host.

Why it matters to the business

Systems using affected Linux kernels with Ceph kernel client functionality or exposed Ceph Messenger v2 communication paths may be vulnerable to high-impact compromise or outages. Exploitation could let an attacker disrupt storage access, crash production hosts, or potentially execute code at the operating-system kernel level. The issue is older but still important because exploit code is reported as available and the EPSS score is elevated, indicating meaningful real-world exploitation likelihood even though it is not currently listed in CISA KEV or marked as ransomware-associated.

How an attack unfolds

An attacker first needs network-level reachability to a Ceph Messenger v2 communication path involving an affected Linux kernel Ceph component and must satisfy the low-privilege conditions implied by the vulnerable protocol path, such as being able to participate in or influence Ceph communication. The attacker then sends a crafted Messenger v2 TCP frame, specifically in the HELLO or AUTH phase, containing a malicious length value. The vulnerable kernel code decodes that untrusted value with incorrect signedness handling and uses it in buffer-management logic. If the crafted value reaches the vulnerable path, memory adjacent to the intended buffer can be overwritten. Depending on kernel build, memory layout, mitigations, and attacker reliability, this may result in a denial-of-service kernel panic or controlled kernel memory corruption that can be shaped into remote code execution. After successful code execution, the attacker may gain kernel-level control of the host, tamper with storage-related operations, disable security tooling, move laterally using host credentials or network access, or destroy data.

How to fix it

Upgrade affected Linux kernels to version 6.4.5 or later, or apply the upstream fix commit a282a2f10539dce2aa619e71e1817570d557fc97 through the relevant Linux distribution kernel update. Because kernel fixes require the patched kernel to be running, schedule a reboot or live-patching workflow where supported and then verify the active kernel version, not only the installed package version. If immediate patching is not possible, restrict Ceph Messenger v2 traffic to trusted Ceph nodes and administration networks, block unnecessary inbound and lateral access to Ceph-related ports, remove untrusted systems from Ceph communication paths, and avoid connecting affected kernel clients to untrusted or unknown Ceph endpoints. Consider temporarily disabling or unloading unused Ceph kernel client functionality where operationally feasible.

How to confirm the fix worked

Confirm that running kernels are no longer vulnerable by checking the active kernel version with uname -r and validating that it includes the distribution backport for the upstream fix or is Linux 6.4.5 or later. For source-based or custom kernels, verify that commit a282a2f10539dce2aa619e71e1817570d557fc97, or an equivalent patch, is present in the kernel source used to build the running image. Validate that affected systems have been rebooted into the patched kernel or are covered by a vendor-supported live patch. Review whether the ceph or libceph kernel modules are loaded and whether Ceph Messenger v2 network paths are reachable only from trusted networks. Network validation should include confirming that Ceph-related ports such as TCP 3300 and storage-node port ranges are not exposed beyond intended peers.

Typical attack path

1. Identify Linux systems running affected kernels before 6.4.5 that use Ceph kernel client or Ceph Messenger v2 functionality.
2. Confirm network reachability to Ceph Messenger v2-related services or communication paths, commonly including Ceph monitor and storage-node traffic where applicable.
3. Establish or influence a Ceph protocol exchange that reaches the vulnerable HELLO or AUTH frame parsing code.
4. Send a crafted TCP frame containing a malicious length field that triggers the signedness error in ceph_decode_32 handling.
5. Cause kernel memory corruption in net/ceph/messenger_v2.c during frame decoding.
6. Convert the crash or corruption into denial of service or, where exploit reliability permits, kernel-level remote code execution.
7. Use kernel-level access to persist, tamper with host controls, access sensitive data, disrupt Ceph-backed workloads, or pivot to adjacent systems.

How to detect it

To determine whether exploitation may already have occurred, review host and network telemetry around systems that use Ceph kernel functionality. Key host sources include kernel logs, journald, syslog, dmesg output, kdump/vmcore artifacts, EDR telemetry, and package or reboot history. Look for unexpected kernel oops or panic events involving ceph, libceph, messenger_v2, msgr2, HELLO, AUTH, or ceph_decode_32, especially near inbound or outbound TCP connections to Ceph-related ports. Network sources should include firewall logs, flow records, Zeek, packet capture, and IDS telemetry for unusual or unauthorized connections to Ceph Messenger v2 endpoints, particularly TCP 3300 and Ceph storage-node port ranges. Because failed exploitation may only produce crashes or malformed protocol sessions, absence of a clean application log entry does not rule out attempts. If crash dumps are available, inspect stack traces for net/ceph/messenger_v2.c, ceph_decode_32, frame decoding, or authentication/hello handling. Also investigate any sudden host reboot, kernel panic, Ceph client disconnection, or storage I/O disruption that coincides with suspicious Ceph network traffic.

• ceph_decode_32
• net/ceph/messenger_v2.c
• messenger_v2.c
• libceph
• ceph messenger
• msgr2
• HELLO frame
• AUTH frame
• BUG: kernel NULL pointer dereference
• general protection fault
• kernel panic
• Oops:
• RIP:
• tcp/3300
• tcp/6789
• tcp/6800
• tcp/7300
• module ceph
• module libceph
• /sys/module/ceph
• /sys/module/libceph
• /proc/fs/ceph

What your security team should do

• Prioritize patching Linux systems that run Ceph clients, CephFS, RBD, or Ceph-related kernel modules, especially where Ceph traffic crosses shared, multi-tenant, or less-trusted networks.
• Treat exploit availability and elevated EPSS as a reason to remediate during the next urgent kernel maintenance window even though the vulnerability is not currently in CISA KEV.
• Inventory systems with loaded ceph and libceph kernel modules and correlate them with kernel versions older than 6.4.5 or missing the vendor backport.
• Restrict Ceph Messenger v2 traffic to explicitly trusted Ceph nodes using host firewalls, network ACLs, security groups, or segmentation controls.
• Search historical kernel logs, system journals, crash dumps, and network telemetry for Ceph Messenger v2 parsing anomalies, kernel oops events, and unexpected traffic to Ceph ports.
• Ensure crash dump collection and kernel log forwarding are enabled on Ceph-connected Linux hosts so exploitation attempts that cause panics are preserved for investigation.
• For custom or self-built kernels, verify inclusion of upstream commit a282a2f10539dce2aa619e71e1817570d557fc97 rather than relying on version strings alone.