CVE-2026-46024

What it actually does

This Linux kernel libceph flaw can trigger a NULL pointer dereference during Ceph authentication reply handling. A crafted CEPH_MSG_AUTH_REPLY message with both protocol and result set to zero can cause the kernel client authentication state to set its protocol to 0 and its operations pointer to NULL, then later call ac->ops->handle_reply(), dereferencing NULL. The practical technical impact is a kernel crash or panic on systems using the Ceph kernel client or libceph-based functionality, resulting in denial of service. The issue is remotely reachable in scenarios where a vulnerable host processes attacker-controlled or malicious Ceph authentication replies.

Why it matters to the business

Systems that rely on Ceph-backed storage or kernel Ceph client functionality may be crashed by a malformed authentication response, potentially interrupting storage access, workloads, and dependent applications. Although there is no known public exploit maturity and it is not currently listed in CISA KEV, the CVSS 7.5 network-reachable denial-of-service rating means exposed or untrusted Ceph communication paths should be treated as operationally important, especially for clusters supporting production storage, virtualization, containers, or data services.

How an attack unfolds

An attacker needs a way to cause a vulnerable Linux host to process a crafted Ceph authentication reply. This is most plausible where the attacker can impersonate, compromise, or man-in-the-middle a Ceph monitor or other authentication responder, or where a client is configured to connect to an attacker-controlled Ceph endpoint. During authentication negotiation, the attacker sends a CEPH_MSG_AUTH_REPLY message whose protocol and result fields are both zero. In the vulnerable kernel code path, this malformed reply is not rejected early; instead, the authentication context may clear the selected protocol and leave the operations handler unset. The kernel then attempts to invoke the authentication reply handler through the NULL operations pointer, causing a NULL pointer dereference. Depending on kernel panic settings and workload, the result may be an immediate host crash, kernel oops with service disruption, or loss of Ceph-backed storage access.

How to fix it

Upgrade affected Linux kernels to a vendor-supported build that includes the upstream libceph fix for ceph_handle_auth_reply(). No exact fixed package versions were provided in the input, so use distribution vendor advisories and kernel changelogs to identify the first fixed kernel for each platform. Where immediate patching is not possible, reduce exposure by restricting Ceph monitor and client communication to trusted management/storage networks, blocking untrusted access to Ceph service ports, preventing clients from connecting to untrusted Ceph endpoints, and ensuring Ceph authentication and network segmentation are correctly enforced. For high-availability systems, review kernel panic and watchdog behavior because exploitation may result in host reboot or workload failover.

How to confirm the fix worked

Confirm remediation by verifying the running kernel version is a vendor build that includes the libceph ceph_handle_auth_reply() fix, not merely that an updated package is installed pending reboot. Check distribution advisories, kernel source/changelog references, or backport notes for the change that treats a zero auth protocol in CEPH_MSG_AUTH_REPLY as a bad auth protocol and avoids calling ac->ops when unset. Validate exposure by inventorying systems with Ceph kernel mounts, rbd kernel mappings, or modules such as ceph, libceph, and rbd loaded. Confirm network controls prevent untrusted systems from reaching Ceph monitor/client communication paths. After patching, review kernel logs during Ceph authentication tests for absence of NULL pointer dereference traces in ceph_handle_auth_reply().

Typical attack path

1. Identify a vulnerable Linux system using the kernel Ceph client or libceph-based Ceph connectivity.
2. Obtain a network position that can deliver Ceph authentication replies to the client, such as controlling a configured Ceph endpoint, compromising a Ceph monitor, spoofing a service in a weakly controlled network, or intercepting traffic.
3. Wait for or trigger the client to initiate Ceph authentication negotiation.
4. Send a malformed CEPH_MSG_AUTH_REPLY with protocol set to 0 and result set to 0 during the negotiation state.
5. Cause the vulnerable kernel path to set the authentication operations pointer to NULL and then dereference it.
6. Observe denial of service through kernel oops, panic, host reboot, or disrupted access to Ceph-backed storage.

How to detect it

To determine whether this was already exploited, review kernel logs, system journal, crash dumps, and monitoring alerts for kernel oops or panic events involving libceph, ceph_handle_auth_reply(), Ceph authentication, or NULL pointer dereferences. Relevant sources include /var/log/kern.log, /var/log/messages, journalctl -k output, kdump/vmcore records, hypervisor reset events, host uptime/reboot telemetry, and Ceph client logs around the time of crashes. Correlate crashes with inbound or bidirectional Ceph traffic and authentication attempts, especially connections to unexpected Ceph monitor IPs or failures during mount/rbd map operations. Network telemetry may show Ceph protocol sessions immediately before a crash, but the malformed protocol/result fields may not be visible without packet capture or protocol-aware inspection. Because successful exploitation may crash the host before detailed application logging is written, prioritize kernel crash artifacts and timing correlation with Ceph authentication activity.

• BUG: kernel NULL pointer dereference
• NULL pointer dereference
• ceph_handle_auth_reply
• libceph
• CEPH_MSG_AUTH_REPLY
• bad auth protocol
• ceph: bad auth protocol
• handle_auth_reply
• ac->ops->handle_reply
• kernel panic - not syncing
• Oops: 0000
• /var/log/kern.log
• /var/log/messages
• journalctl -k
• /proc/modules: ceph
• /proc/modules: libceph
• /proc/modules: rbd
• /sys/module/ceph
• /sys/module/libceph
• /sys/module/rbd

What your security team should do

• Prioritize patching Linux systems that use Ceph kernel mounts, kernel RBD mappings, or libceph functionality, especially production storage clients and virtualization/container hosts.
• Use vendor kernel advisories to identify fixed versions and ensure systems are rebooted into the fixed kernel after update.
• Restrict Ceph traffic to trusted storage networks and block untrusted access to Ceph monitor and related service ports at firewalls and security groups.
• Inventory loaded kernel modules and active Ceph mounts/mappings to identify exposed hosts, including transient compute nodes and storage clients.
• Monitor kernel logs and crash telemetry for NULL pointer dereferences involving ceph_handle_auth_reply, libceph, or Ceph authentication paths.
• Treat unexpected host crashes or Ceph client authentication failures as potential security events when they coincide with suspicious Ceph network activity.
• If patching is delayed, reduce risk by isolating vulnerable Ceph clients from untrusted networks and verifying they connect only to legitimate Ceph monitors.
• Review HA and recovery procedures for services depending on Ceph-backed storage because exploitation primarily affects availability.