External risk intelligence

Linux Kernel libceph Unsafe Decode Vulnerability

CVE advisorySeverity: CRITICAL (CVSS 9.8)

CVE-2026-80561

The vulnerability exists within the Linux kernel's Ceph client communication with OSDs. While it is network-based, Ceph storage clusters are typically deployed within private, internal backend networks. Public internet exposure of Ceph OSD/client protocol communication is uncommon and contrary to standard deployment practices.

Halo Surface Signal: 2 out of 5 — less likely to be public-facing.

External exposure likelihood

Horizon Alert

Summary of the vulnerability and why it matters

A critical vulnerability has been identified in the Linux kernel's Ceph component, specifically within the `decode_locker` function. This issue could allow a compromised storage component to trigger memory errors, potentially impacting system stability. The main concern is confirming relevance and exposure within your specific environment.

Unsafe data decoding in kernel.
Matters for internal storage integrity.
Confirm if your system uses Ceph.

Attack Path

How an attacker could exploit the issue

A malicious or compromised storage device can exploit this vulnerability by sending malformed data to a Linux kernel client. This occurs when the client requests information about storage locks, leading to memory corruption.

Requires a compromised storage device.
Triggered by requesting lock information.
Leads to memory corruption in the kernel.

Live Threat

Current exploitation, exposure, and threat context

A malicious or compromised OSD could trigger out-of-bounds reads in the Linux kernel's Ceph client when processing lock information. This could occur when the client issues lock acquisition requests, potentially affecting system stability. No specific PII or sensitive data types are indicated as at risk.

Kernel memory integrity.
Unsafe decoding operations by OSD.
Potential system instability or crashes.

Operational Fix

Recommended remediation, mitigation, and detection steps

This vulnerability in the Linux kernel's Ceph client could be exploited by a malicious or compromised OSD to read out of bounds from the kernel's memory. In a multi-tenant Ceph deployment, this could affect any kernel client issuing the `lock.get_info` class method, such as during RBD exclusive lock acquisition. The first practical step is for infrastructure and platform teams to identify Ceph deployments, determine their exposure, and locate the accountable owner for the affected kernel components before planning remediation.

Infrastructure and platform teams own resolution.
Verify Ceph deployment exposure and criticality.
Plan risk-based remediation with vendor coordination.

Supplementary metadata

CVSS vector

Validate whether this threat affects your internet-facing exposure.

Halo Threat Intelligence helps prioritize remediation with Halo Surface Signal and H/A/L/O context. Start exposure validation with a free external attack surface trial.

Free EASM Trial See How Signal Works

Frequently asked questions

What is the Linux kernel libceph component used for?

The libceph component is part of the Linux kernel that allows systems to act as clients for Ceph storage clusters. It manages the communication between the kernel and the storage environment, facilitating tasks like mounting network-attached storage and handling data consistency locks, such as those used by the RADOS Block Device (RBD).

What does the CVE-2026-80561 vulnerability mean?

This is a memory-safety issue categorized as an out-of-bounds read vulnerability. It occurs when the kernel's Ceph client improperly validates data received from a storage device. Because the code fails to verify data boundaries, a sender can trick the kernel into reading memory areas it should not access, which can lead to system instability.

How is this memory vulnerability triggered?

The flaw is triggered when a client requests lock information from a storage device, specifically via the 'lock.get_info' method. It does not trigger during normal, healthy operations where data is structured correctly. Instead, it requires a storage device to intentionally or accidentally send malformed packets that bypass existing memory checks.

Is my system at risk according to Halo Surface Signal?

Halo Surface Signal considers active exploitation unlikely for most because Ceph clusters are typically restricted to private, internal networks. You should only be concerned if your Ceph communication is incorrectly exposed to public networks, which contradicts standard, secure deployment practices.

How should I respond to this Linux kernel vulnerability?

Your first step is to confirm if your environment utilizes Ceph storage. If you identify active Ceph deployments, work with your infrastructure or platform teams to verify that cluster communication is properly isolated within internal networks. After securing the network perimeter, track official kernel updates from your distribution vendor to apply the necessary code patches.

References

Written by Nicholas Merritt

Nicholas Merritt is VP of Security Solutions at Halo Security. With more than 25 years across application security, vulnerability prioritization, and offensive security, he helps teams translate threat data into practical exposure validation and remediation focus. He authors Halo Threat Intelligence CVE advisories using Halo Surface Signal and H/A/L/O context to prioritize internet-facing risk.