CVE-2026-43304

What it actually does

This is a Linux kernel memory-safety flaw in libceph, the kernel client code used to communicate with Ceph clusters. During authentication completion, process_auth_done() decoded key material without enforcing a maximum key length before copying it into a fixed-size buffer. A malicious or compromised Ceph peer could return an oversized authentication key and trigger a buffer overflow in kernel context. Depending on kernel build, memory layout, and exploitability conditions, the result may range from a kernel crash to corruption of kernel memory with potential remote code execution and full system compromise.

Why it matters to the business

Systems that use the Linux kernel Ceph client for CephFS, RBD, or other Ceph-backed storage may be exposed if they connect to an untrusted, malicious, or compromised Ceph cluster endpoint. Successful exploitation could disrupt storage access, crash affected Linux hosts, corrupt data paths, or allow an attacker to gain control of the affected system. Although the CVSS score is critical, EPSS is currently low and there is no known KEV listing or public exploit maturity reported, so priority should be highest for environments actively using kernel-based Ceph connectivity or connecting to Ceph services across less-trusted networks.

How an attack unfolds

An attacker first needs to be in a position to influence the Ceph authentication exchange, typically by operating a malicious Ceph monitor/service endpoint, compromising an existing Ceph cluster component, poisoning configuration so a client connects to an attacker-controlled endpoint, or performing a network-level interception where Ceph traffic is not adequately protected. When an affected Linux host initiates a Ceph connection, the attacker responds during authentication with a crafted message containing key material whose encoded length exceeds the fixed-size buffer expected by libceph. The vulnerable kernel code decodes the key in process_auth_done() without enforcing the new CEPH_MAX_KEY_LEN boundary and copies excessive data into kernel memory. This may crash the kernel immediately or corrupt adjacent memory, potentially enabling further control-flow manipulation. The attack requires no local access to the victim host and no user interaction, but it is most relevant where the victim uses the in-kernel Ceph client and can be made to communicate with attacker-controlled or compromised Ceph infrastructure.

How to fix it

Apply the Linux kernel update from the relevant distribution or kernel vendor that includes the libceph fix enforcing CEPH_MAX_KEY_LEN in process_auth_done(). No exact fixed package versions were provided in the input, so remediation should be based on vendor advisories, distribution security errata, or upstream kernel backports for CVE-2026-43304. Reboot into the updated kernel after patching; merely installing the package is not sufficient if the vulnerable kernel remains running. Where immediate patching is not possible, reduce exposure by disabling or unloading the ceph kernel module if unused, removing unneeded Ceph mounts and RBD mappings, restricting outbound and inbound Ceph traffic to trusted cluster endpoints, preventing clients from connecting to untrusted monitors, and ensuring Ceph network paths are protected from interception or redirection.

How to confirm the fix worked

Confirm that affected hosts are running a patched kernel, not just that an updated kernel package is installed. Validate with the active kernel version and the vendor advisory or changelog showing the CEPH_MAX_KEY_LEN/libceph fix. Check for Ceph usage by reviewing loaded modules, CephFS mounts, RBD mappings, storage configuration, and network connections to Ceph monitor or OSD ports. Confirm that any ceph kernel module present comes from the patched kernel build. For high-assurance validation, inspect the kernel source/package changelog for enforcement of CEPH_MAX_KEY_LEN during key decoding in libceph process_auth_done(). Also verify that firewall rules or network policy limit Ceph connectivity to trusted cluster addresses only.

Typical attack path

1. Identify Linux systems using the in-kernel Ceph client for CephFS, RBD, or other Ceph-backed storage.
2. Gain control over a Ceph endpoint the client will contact, compromise a legitimate Ceph monitor/service, or redirect the client to a malicious endpoint.
3. Wait for or trigger the affected client to initiate Ceph authentication.
4. Send a crafted authentication completion response containing oversized key material.
5. Trigger the unchecked decode/copy path in libceph process_auth_done().
6. Cause kernel memory corruption, resulting in denial of service or possible kernel-level code execution.
7. Use any achieved control to persist, access mounted storage, tamper with data, or pivot further.

How to detect it

Look for evidence that affected hosts communicated with unexpected or newly introduced Ceph endpoints, followed by kernel instability, crashes, or memory-corruption messages. Relevant sources include kernel logs from dmesg, journald, /var/log/kern.log, /var/log/messages, crash dumps, kdump/vmcore data, Ceph client logs where present, endpoint network telemetry, DNS logs, firewall logs, and configuration management history. Search for kernel stack traces involving libceph authentication paths, especially process_auth_done(), ceph authentication handling, or crypto/key decode routines. Correlate any kernel panic, KASAN report, slab/out-of-bounds warning, general protection fault, or oops with outbound connections to Ceph monitor ports such as 3300 or 6789, or broader Ceph OSD port ranges. Investigate unauthorized changes to ceph.conf, monitor addresses, mount units, fstab entries, RBD mapping configuration, and orchestration manifests that could redirect clients to attacker-controlled Ceph services. Because exploitation may only leave a crash or memory-corruption artifact, absence of a clean application-level log entry does not rule out attempted exploitation.

• process_auth_done
• libceph
• CEPH_MAX_KEY_LEN
• ceph_auth_handle_reply
• ceph: auth
• KASAN: slab-out-of-bounds
• KASAN: out-of-bounds
• BUG: unable to handle kernel paging request
• general protection fault
• kernel NULL pointer dereference
• Kernel panic - not syncing
• Oops:
• /etc/ceph/ceph.conf
• /proc/mounts
• /sys/bus/rbd/devices
• tcp/3300
• tcp/6789
• tcp/6800

What your security team should do

• Inventory Linux hosts using kernel Ceph functionality, including CephFS mounts, RBD mappings, hypervisor storage backends, Kubernetes nodes, and storage gateways.
• Prioritize patching and rebooting hosts that actively connect to Ceph clusters, especially across shared, untrusted, or segmented networks.
• Confirm vendor-fixed kernel availability and track remediation by active running kernel version rather than installed package version alone.
• Restrict Ceph monitor and OSD connectivity to approved cluster IPs and block unexpected Ceph traffic on common ports such as 3300 and 6789.
• Review Ceph configuration management for unauthorized monitor endpoints, DNS changes, or configuration drift that could redirect clients to malicious services.
• If Ceph is not required, disable the kernel Ceph client module and remove unused Ceph-related packages, mounts, and autostart configuration.
• Monitor kernel logs and crash telemetry for libceph, process_auth_done, KASAN, general protection fault, or kernel panic events on systems with Ceph connectivity.
• Treat unexplained kernel crashes during Ceph authentication or mount attempts as potentially security-relevant until patched and investigated.