Cloudanix VulnDB

CVE-2026-68131

None

CVSS

—

EPSS

0.5%

Published

Aug 10, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A bug in handling storage device responses on Linux could let a bad reply crash the system during normal disk writes.

Exploitation
Remote Authenticated
Attacker needs
Low Privilege
Complexity
Moderate
Impact
Denial Of Service
Component
OS kernel
Class
Improper Input Validation
Remediation
Patch
Effort
Medium
Patch risk
Low

What it actually does

Failure to sanitize positive result codes from object map update replies allows a corrupted response to reach an assertion expecting a negative value, triggering a kernel-level fault in the RBD request handling path.

Why it matters to the business

Environments relying on Ceph RBD for block storage face risk of kernel instability or crashes during normal write operations, potentially causing unplanned downtime and data access interruptions.

How an attack unfolds

An attacker with the ability to intercept or influence Ceph OSD reply messages crafts a response containing a positive result code for an object map update; when the kernel processes this reply through rbd_object_map_callback, the unreset value propagates to __rbd_obj_handle_request and triggers the assertion failure.

How to fix it

Update the Linux kernel to a version containing the fix that resets positive result codes to zero inside rbd_object_map_callback and adds the accompanying WARN_ON_ONCE check; rebuild and deploy the updated kernel across all affected hosts.

How to confirm the fix worked

Confirm the patched kernel source contains the reset logic and WARN_ON_ONCE in rbd_object_map_callback; test by replaying a crafted positive-result reply and verifying the assertion no longer triggers and the request completes as a zero-result case.

Typical attack path

  1. Position to deliver or corrupt an RBD reply message from an OSD
  2. Send or replay a write-related object map update response with a positive result code
  3. Trigger rbd_object_map_callback to pass the value into rbd_obj_handle_request
  4. Cause assertion failure in __rbd_obj_handle_request when the positive code is evaluated

How to detect it

Search kernel logs for rbd_assert failures or messages referencing __rbd_obj_handle_request and rbd_object_map_callback; inspect Ceph OSD traffic for unexpected positive result codes on object map update replies.

What your security team should do

  • Prioritize kernel updates on all systems using RBD-backed storage
  • Monitor Ceph cluster health and OSD reply integrity until patches are applied
  • Review kernel logs for RBD assertion messages as a temporary detection measure

The record

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.

Affected packages

Ecosystem Package Introduced Fixed