KernelScan.io

HIGH Introduced in 5.3

rbd ObjectMap Panic

CVE-2026-68131

CVSS 7.5 / 10.0 NVD

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

KernelScan AI7.5HIGH

01

In the Linux kernel, the following vulnerability has been resolved: rbd: Reset positive result codes to zero in object map update path In a reply message to an RBD request, a positive result code indicates a data payload, which is not allowed for writes. While rbd_osd_req_callback() already resets a positive result code for writes to zero, rbd_object_map_callback() does not. This allows a corrupted reply to an object map update to trigger the rbd_assert(*result < 0) in __rbd_obj_handle_request(). This happens, because rbd_object_map_callback() calls rbd_obj_handle_request() -> __rbd_obj_handle_request() and passes this positive result code. From __rbd_obj_handle_request(), rbd_obj_advance_write() is called, which leaves the positive result code unchanged and returns true. Therefore, the if(done && *result) branch is executed in __rbd_obj_handle_request() and the assertion triggers. This patch fixes the issue by adjusting the logic in the rbd_object_map_callback() path. A positive result code for an object map update is now reset to zero (similar to rbd_osd_req_callback()), and the message is subsequently handled the same way as if the result code was zero from the beginning. Additionally, a WARN_ON_ONCE() is added for this case.

02

Engine v0.6.0

Risk summary

A compromised or malicious Ceph OSD can send a corrupted reply to an RBD object map update request, causing a kernel assertion failure and system panic on the RBD client host. This affects any system using the kernel RBD client with object-map enabled (introduced in kernel 5.3). The impact is denial of service with no data corruption or disclosure.

Affecteddrivers/block/rbd.c (rbd - Ceph RADOS Block Device)

Vulnerability analysis

The RBD client does not properly handle unexpected positive status values in replies from the Ceph storage cluster for object map updates. Such a malformed reply reaches an internal sanity check that expects only error conditions, triggering a kernel panic. Ordinary write handling already dropped these unexpected values, but the object map update handling did not. The fix applies the same sanitization to object map replies, resetting unexpected positive values to zero and issuing a warning, while preserving normal error handling. A compromised or impersonated storage server that can send replies on the Ceph cluster network can trigger this crash without needing any access to the target system itself.

03

BranchIntroducedFixed inPatch commit
6.15.36.1.1836f33d9d539fb
6.65.36.6.14814995c4250f0
6.125.36.12.1012419aa740810
6.185.36.18.4234f2a2f32af5
7.15.37.1.6b1a613669332
mainline5.37.2a6c4250b81bd
5.105.35.10.265cf1167292f60
5.155.35.15.216da926959bf79