CVE-2026-68131 in Linux
Summary
by MITRE • 08/10/2026
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.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 08/10/2026
The vulnerability described represents a critical flaw in the Linux kernel's RBD (Remote Block Device) implementation that could potentially lead to system instability and denial of service conditions. This issue specifically affects the object map update path within the RBD subsystem where improper handling of result codes creates a scenario for assertion failures and system crashes. The vulnerability stems from inconsistent behavior between different callback functions in the RBD request processing pipeline, creating a potential attack vector that could be exploited to disrupt normal system operations.
The technical root cause lies in the differential handling of result codes between two distinct callback functions within the RBD subsystem. While rbd_osd_req_callback() correctly resets positive result codes to zero for write operations, the rbd_object_map_callback() function fails to perform this critical validation step. This inconsistency allows malicious or corrupted network replies during object map updates to carry positive result codes that should never be present in write operations. The positive result codes indicate data payloads which are explicitly forbidden for write requests according to the RBD protocol specification.
When processing object map update requests, the system flow passes through multiple function calls including rbd_object_map_callback() -> rbd_obj_handle_request() -> __rbd_obj_handle_request(). During this sequence, the positive result code from the callback is directly passed to the core handling function without proper sanitization. The __rbd_obj_handle_request() function contains an assertion check rbd_assert(*result < 0) that validates the result code should never be positive for write operations. However, due to the failure in rbd_object_map_callback() to reset the positive result code to zero, this assertion triggers and causes system termination.
This vulnerability directly relates to CWE-248, Uncaught Exception, and CWE-755, Improper Handling of Exceptional Conditions, as it represents an unhandled exceptional condition that leads to system instability. The flaw also maps to ATT&CK technique T1499.001, Endpoint Denial of Service, where the improper handling of result codes creates a vector for denial of service attacks against storage subsystems. The inconsistency in result code handling creates a predictable failure mode that could be exploited by attackers with network access to the RBD storage infrastructure.
The fix implemented addresses this vulnerability by synchronizing the behavior between callback functions to ensure consistent result code handling. The patch modifies rbd_object_map_callback() to reset positive result codes to zero before passing them to subsequent processing functions, matching the behavior already present in rbd_osd_req_callback(). This normalization ensures that object map update operations maintain the same validation logic as other RBD write operations. Additionally, the implementation includes a WARN_ON_ONCE() mechanism that logs occurrences of this condition for monitoring purposes, providing visibility into potential security issues or data corruption scenarios.
The operational impact of this vulnerability extends beyond simple system crashes to potentially affect storage reliability and availability in enterprise environments. Organizations using RBD-based storage solutions could experience unexpected service interruptions when processing object map updates, particularly under high load conditions or when dealing with corrupted network traffic. The fix ensures that the RBD subsystem maintains proper state validation and prevents assertion failures that could lead to kernel panics or forced system reboots, thereby improving overall system stability and reliability for storage-intensive applications.
The mitigation strategy implemented through this patch represents a defensive programming approach that enforces consistent result code validation across all RBD request processing paths. This change aligns with security best practices for kernel module development and demonstrates proper error handling mechanisms that prevent invalid states from propagating through the system. The solution maintains backward compatibility while strengthening the overall robustness of the RBD implementation against malformed network responses that could otherwise cause system instability during critical storage operations.