Skip to main content

Linux Kernel EUVDEUVD-2026-55512

| CVE-2026-68131 HIGH
2026-08-10 Linux GHSA-rwc8-9546-9gw5
7.5
CVSS 3.1 · Vendor: Linux
Share

Severity by source

Vendor (Linux) PRIMARY
7.5 HIGH
AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
vuln.today AI
5.9 MEDIUM

Network vector retained, but AC:H reflects requirement for Ceph storage network access or OSD compromise to forge the malicious reply; no confidentiality or integrity impact.

3.1 AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H
4.0 AV:N/AC:H/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
SUSE
HIGH
qualitative
Red Hat
7.0 MEDIUM
qualitative

Primary rating from Vendor (Linux).

CVSS VectorVendor: Linux

Attack Vector
Network
Attack Complexity
Low
Privileges Required
None
User Interaction
None
Scope
Unchanged
Confidentiality
None
Integrity
None
Availability
High

Lifecycle Timeline

5
Analysis Generated
Aug 14, 2026 - 02:25 vuln.today
CVSS changed
Aug 13, 2026 - 23:37 NVD
7.5 (HIGH)
Patch available
Aug 10, 2026 - 14:18 EUVD
CVE Published
Aug 10, 2026 - 11:58 cve.org
UNKNOWN (no severity yet)
CVE Published
Aug 10, 2026 - 11:58 cve.org
HIGH 7.5

DescriptionCVE.org

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.

AnalysisAI

Kernel crash via assertion failure in the RBD (RADOS Block Device) subsystem of the Linux kernel allows a denial-of-service condition when a crafted or corrupted OSD reply message with a positive result code is received during an object map update. Affected kernels from 5.3 onward lack the positive-result-code reset in rbd_object_map_callback() that already exists in rbd_osd_req_callback(), causing rbd_assert(*result < 0) in __rbd_obj_handle_request() to trigger and crash the kernel. No public exploit has been identified at time of analysis, and EPSS stands at 0.18% (7th percentile), indicating low observed exploitation probability.

Technical ContextAI

The Linux kernel's RBD driver (drivers/block/rbd.c) provides a block device interface to Ceph RADOS Object Storage Daemons. In the OSD reply handling path, a positive result code on a write operation signals a data payload, which is semantically invalid. The existing rbd_osd_req_callback() defensively resets such codes to zero, but rbd_object_map_callback() - which handles Ceph object map metadata updates - lacked this guard. When a positive code propagates through the call chain rbd_object_map_callback() → rbd_obj_handle_request() → __rbd_obj_handle_request(), the function rbd_obj_advance_write() leaves the positive code unchanged and returns true, causing execution to enter the if(done && *result) branch and hit the hard assertion rbd_assert(*result < 0), panicking the kernel. The CWE is not assigned, but the root cause class is an assertion/invariant violation due to missing input normalization at a subsystem boundary. Affected CPE: cpe:2.3:a:linux:linux (versions from 5.3, introduced with commit 22e8bd51bb04).

RemediationAI

The primary fix is to upgrade to a patched stable kernel release: 6.6.148 or later on the 6.6 LTS branch, 6.12.101 or later on the 6.12 LTS branch, 6.18.42 or later on the 6.18 branch, or 7.1.6 or later on the 7.1 branch. Source patches are available at git.kernel.org/stable/c/14995c4250f04b58bf6fc00e0e973a2e1b3cfb9b, git.kernel.org/stable/c/2419aa74081007dc4d14ff5640659052dfdfd69a, git.kernel.org/stable/c/34f2a2f32af570dfcc532ad70c080629ee1c32b0, and sibling commits in the same series. As a compensating control where patching is not immediately possible, unloading or blacklisting the rbd kernel module (modprobe -r rbd, then adding blacklist rbd to /etc/modprobe.d/) eliminates the attack surface entirely but will also disable all Ceph RBD block devices - not viable in production Ceph-dependent environments. Alternatively, isolating the Ceph storage network from untrusted hosts at the firewall level reduces the ability of an attacker to inject malicious OSD replies, though this does not protect against a compromised OSD node. NVD advisory: https://nvd.nist.gov/vuln/detail/CVE-2026-68131.

Vendor StatusVendor

SUSE

Severity: Important
Product Status
SUSE Linux Enterprise Desktop 15 SP7 Affected
SUSE Linux Enterprise Desktop 15 SP7 Affected
SUSE Linux Enterprise High Availability Extension 15 SP7 Affected
SUSE Linux Enterprise High Availability Extension 15 SP7 Affected
SUSE Linux Enterprise High Availability Extension 16.0 Affected

Share

EUVD-2026-55512 vulnerability details – vuln.today

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy