Bug 2492328 (CVE-2026-52955)

Summary: CVE-2026-52955 kernel: libceph: Fix potential out-of-bounds access in crush_decode()
Product: [Other] Security Response Reporter: OSIDB Bzimport <bzimport>
Component: vulnerabilityAssignee: Product Security <prodsec-ir-bot>
Status: NEW --- QA Contact:
Severity: high Docs Contact:
Priority: high    
Version: unspecifiedCC: rhel-process-autobot, watson-tool-maintainers
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: ---
Doc Text:
A flaw was found in the `libceph` component of the Linux kernel. A remote attacker could send a specially crafted `CEPH_MSG_OSD_MAP` message where two internal fields, `alg` and `b->alg`, contain differing bucket algorithm values. This discrepancy can lead to an out-of-bounds memory access during processing or memory deallocation, potentially causing a system crash and resulting in a Denial of Service (DoS).
 Story Points: ---
Clone Of: Environment:
Last Closed: Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description OSIDB Bzimport 2026-06-24 18:06:03 UTC 
In the Linux kernel, the following vulnerability has been resolved:

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

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().
Comment 1 Keith Grant 2026-06-25 18:30:09 UTC 
Upstream advisory:
https://lore.kernel.org/linux-cve-announce/2026062435-CVE-2026-52955-77f4@gregkh/T