Description

In the Linux kernel, the following vulnerability has been resolved: libceph: Avoid using invalid osd indices from primary_temp A corrupted osdmap received from a Ceph monitor or OSD may contain osd indices in its pg_temp, primary_temp, pg_upmap, and pg_upmap_items parts that don't exist, i.e., that are greater than max_osd or smaller than CEPH_HOMELESS_OSD (-1). These indices are used to create the up and acting set in ceph_pg_to_up_acting_osds(), called from calc_target(). While most of these osd indices are checked, the one from primary_temp is not. Subsequently, this may lead to calc_target() returning this (potentially invalid) index as target osd for a (linger) request. Because the osd_state, osd_weight, and osd_addr arrays only contain max_osd entries (with indices 0 to max_osd -1), this leads to out-of-bounds accesses when trying to read values from these arrays. This patch fixes the issue by adding a check to get_temp_osds(), so that only valid osd indices from primary_temp are used, and it falls back to using the primary from pg_temp or the up set if it is invalid. [ idryomov: changelog ]

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "9.8",
  "pubDate": "2026-08-26T15:17:10.530Z",
  "pubdate": "2026-08-26T15:17:10.530Z",
  "executiveSummary": "A memory safety vulnerability exists in the Linux kernel's Ceph filesystem client (libceph) due to improper validation of OSD indices provided within an OSD map.\nThe vulnerability is categorized as an Out-of-Bounds (OOB) memory access, stemming from the trust placed in OSD indices received from a Ceph monitor or peer OSD.\nAn attacker capable of influencing or spoofing the OSD map can trigger an out-of-bounds read within the kernel, potentially leading to system crashes or sensitive kernel memory disclosure.\nThe flaw resides specifically in the handling of primary_temp indices during the calculation of target OSDs for requests.\nExploitation requires the attacker to be in a position to deliver a malformed OSD map, typically via network communication with the client, posing a risk to systems where Ceph monitor/OSD authentication is compromised or not enforced.\nSuccessful exploitation results in memory corruption or process termination, impacting the availability and stability of the Linux kernel host.",
  "technicalDetails": "The root cause of this vulnerability is the insufficient validation of indices derived from the 'primary_temp' field within the Ceph OSD map (osdmap). The 'libceph' subsystem calculates OSD targets using 'calc_target()', which internally calls 'get_temp_osds()' to resolve the primary OSD for a given placement group (PG).\nIn the vulnerable state, 'get_temp_osds()' does not verify that the index retrieved from 'primary_temp' falls within the valid range of [0, max_osd - 1]. While other map components such as 'pg_temp', 'pg_upmap', and 'pg_upmap_items' undergo validation, the 'primary_temp' index is processed without bounds checking.\nThe attack flow begins when an attacker, acting as a malicious Ceph monitor or OSD, sends a crafted OSD map containing an invalid 'primary_temp' index to the Ceph client. This index may be greater than 'max_osd' or less than the defined constant 'CEPH_HOMELESS_OSD' (-1).\nWhen 'calc_target()' processes this malicious index to designate a target OSD for a request, it proceeds to access the 'osd_state', 'osd_weight', and 'osd_addr' arrays. These arrays are sized according to 'max_osd'. Providing an index outside the valid range forces these pointers to access memory addresses outside the allocated bounds of these arrays.\nStep-by-step exploitation: 1. The attacker injects a malformed OSD map into the network flow. 2. The libceph client receives and updates its local osdmap with the attacker-supplied primary_temp index. 3. A subsequent operation triggers 'calc_target()', which fetches the unverified index. 4. The kernel attempts to read OSD metadata (state, weight, address) using the out-of-bounds index. 5. The operation results in an out-of-bounds memory read, leading to a kernel panic or potential exposure of adjacent heap/data structures to the attacker-controlled request flow.\nThis vulnerability is particularly dangerous because it bypasses existing sanitization mechanisms intended to ensure data integrity during cluster state updates. The impact is primarily a denial-of-service via kernel panic, but theoretically, it could facilitate information disclosure depending on how the OOB read is leveraged by the kernel during the subsequent request processing."
}