Look up another CVE · open CVE-2026-52955 in the interactive tracker

CVE-2026-52955

libceph: Fix potential out-of-bounds access in crush_decode()

9.8 EPSS 0.4% AV:N

Published 2026-06-24 (4 months ago) by the Linux kernel CNA. Subsystem net/ceph. Debian urgency: not yet assigned.

What to do, per Debian release

Debian's own status for CVE-2026-52955 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source

Release	Status	Version	What this means
Debian 12bookworm	fixedDLA-4665-1 · 2026-07-03 · text	6.1.176-1	Update the kernel and reboot. DLA-4665-1 shipped the fix on 2026-07-03, in 6.1.176-1. A running kernel keeps the old code until the machine restarts.
Debian 13trixie	fixed	6.12.94-1	Update the kernel and reboot. Fixed in 6.12.94-1. A running kernel keeps the old code until the machine restarts.
Debian 14forky	fixed	7.0.10-1	Update the kernel and reboot. Fixed in 7.0.10-1. A running kernel keeps the old code until the machine restarts.
Debian unstablesid	fixed	7.0.10-1	Update the kernel and reboot. Fixed in 7.0.10-1. A running kernel keeps the old code until the machine restarts.

The vulnerability

What the bug is

A message of type CEPH_MSG_OSD_MAP containing a crush map with at least one bucket has two fields holding the bucket algorithm. If the values in these two fields differ, an out-of-bounds access can occur. This is the case because the first algorithm field (alg) is used to allocate the correct amount of memory for a bucket of this type, while the second algorithm field inside the bucket (b->alg) is used in the subsequent processing. This patch fixes the issue by adding a check that compares alg and b->alg and aborts the processing in case they differ. Furthermore, b->alg is set to 0 in this case, because the destruction of the crush map also uses this field to determine the bucket type, which can again result in an out-of-bounds access when trying to free the memory pointed to by the fields of the bucket. To correctly free the memory allocated for the bucket in such a case, the corresponding call to kfree is moved from the algorithm-specific crush_destroy_bucket functions to the generic crush_destroy_bucket().

Where it lives

The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.

net/ceph/crush/crush.c
net/ceph/osdmap.c

What this is: CEPH COMMON CODE (LIBCEPH)MAINTAINERS section matched on net/ceph/ · ceph-devel@vger.kernel.org · Supported
Kernel module: libceph

Check it on the machine

grep -w CONFIG_CEPH_LIB /boot/config-$(uname -r)

Reads the booted kernel's own configuration, on the machine and nowhere else. =y is built in, =m is a module, and an is not set line means the code is not there.

lsmod | grep -w libceph

Prints a line if that module is loaded right now, and nothing if it is not. One that is not loaded can still be loaded later by anything that needs it.

Show whether Debian builds this, per release

Debian builds this as a loadable module. Every release below compiles it as a module on every flavour, so whether the code is in the running kernel depends on whether that module is loaded.

bookworm, trixie, forky, sidm

m: a loadable module on every flavour - check lsmod, can be blacklisted

Build switch: CONFIG_CEPH_LIB

From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS kbuild Makefiles Debian linux-config packages

Debian tracker CVE record NVD kernel CNA record

Signals

Published: 2026-06-24 (4 months ago)source
CVSS: 9.8 critical
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:Hsource recompute it
Attack vector: network (AV:N)source
EPSS: 0.38%, higher than 30.4% of all CVEssource
CISA KEV: not listedthe KEV catalogue
Debian urgency: not yet assignedsource
Subsystem: net/ceph

Upstream fixes

The versions the CNA records as introducing and fixing this, and the commit for each. source

Introduced	Fixed in	Commit
2.6.34	5.10.258	6e70ef53e818
2.6.34	5.15.209	ebe76d58a48a
2.6.34	6.1.175	3f42508191e1
2.6.34	6.6.141	ea0d42137f0c
2.6.34	6.12.91	cceb10023e76
2.6.34	6.18.33	0f3604cbe4df
2.6.34	7.0.10	fb176a99e4c1
2.6.34	7.1	4c79fc2d5986

Debian advisories

Advisory	Date	Shipped to	Debian
DLA-4671-1	2026-07-05	bullseye 6.1.176-1~deb11u1	tracker
DLA-4665-1	2026-07-03	bookworm 6.1.176-1	tracker
DLA-4664-1	2026-07-03	bullseye 5.10.259-1	tracker

Why the CNA scored it this way

Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source

AV:NAttack vector, network: The vulnerable CRUSH map is parsed from CEPH_MSG_OSD_MAP messages delivered over Ceph messenger network sessions from monitor or OSD peers.
AC:LAttack complexity, low: An attacker controlling a malicious or compromised Ceph peer can choose the two bucket algorithm fields and map contents directly; no race or external timing condition is required.
PR:NPrivileges required, none: The attacker needs no privileges on the vulnerable kernel client; the higher-severity reasonable scenario is a malicious or compromised remote Ceph monitor/OSD sending the map.
UI:NUser interaction, none: Once the Ceph client is mounted or an RBD client is connected, OSD map updates are processed automatically without per-attack user action.
S:UScope, unchanged: The corruption occurs in the client kernel and impacts that same kernel security authority, with no VM, IOMMU, or other scope boundary crossed.
C:HConfidentiality impact, high: The mismatch can make the parser/destructor interpret a smaller allocation as a larger bucket type, causing kernel heap out-of-bounds pointer accesses; such memory corruption is reasonably exploitable for information disclosure.
I:HIntegrity impact, high: The bug can write pointer fields beyond the allocated bucket object and later free through the wrong layout, creating kernel heap corruption with potential control-flow or data integrity compromise.
A:HAvailability impact, high: Malformed OSD maps can corrupt kernel memory or trigger invalid frees/oopses, making a kernel crash or denial of service a high-probability impact.