CVE-2026-89557
High · 7.8CVSS
7.8
EPSS
0.2%
Published
Sep 11, 2026
CISA due date
—
Cloudanix analysis
A bug in Linux storage code could let someone with local access crash the machine or gain higher privileges if they can supply a specially made disk configuration.
- Exploitation
- Local Privilege
- Attacker needs
- Low Privilege
- Complexity
- Low
- Impact
- Full Compromise
- Component
- OS kernel
- Class
- Memory Corruption
- Remediation
- Upgrade
- Effort
- Medium
- Patch risk
- Low
What it actually does
Missing overflow check on __u8 bblog_shift from on-disk superblock allows left-shift of 64-bit sector/count values to wrap, causing subsequent overflow inside _badblocks_clear when badblocks_set is invoked from super_1_load.
Why it matters to the business
Local attackers on Linux systems using md RAID can trigger memory corruption that may lead to crashes or privilege escalation when a malicious superblock is loaded; patch urgency is low given absence from KEV and flat EPSS.
How an attack unfolds
Attacker crafts an md RAID superblock containing bblog_shift greater than 63, arranges for the kernel to call super_1_load on that superblock during array assembly, and the unchecked shift produces an overflowed sector passed to badblocks_set.
How to fix it
Upgrade the Linux kernel to a version containing the overflow check for sb->bblog_shift inside super_1_load before the badblocks_set call.
How to confirm the fix worked
Confirm presence of the added range check on bblog_shift in md/super.c (or equivalent) and verify that crafted superblocks with bblog_shift >= 64 no longer cause overflow or EINVAL returns.
Typical attack path
- Create or modify an md RAID superblock with bblog_shift outside safe range
- Make the device visible to the target kernel
- Trigger array assembly or explicit superblock load
- Execute badblocks_set path with shifted overflow values
- Trigger memory corruption inside badblocks handling
How to detect it
Search kernel logs for badblocks-related warnings or oops during md array assembly; inspect RAID superblocks on disk for bblog_shift values outside 0-63.
What your security team should do
- Apply the kernel patch adding the bblog_shift bounds check at the earliest maintenance window
- Restrict unprivileged local access on systems exposing md devices to untrusted users
- Include md superblock parsing paths in future kernel fuzzing campaigns
The record
In the Linux kernel, the following vulnerability has been resolved: md: do overflow check for sb->bblog_shift in super_1_load() In super_1_load(), sb->bblog_shift is an __u8 type value loaded from on- disk superblock. It is used for badblocks API badblocks_set() by the following sequence, 1930 rdev->badblocks.shift = sb->bblog_shift; 1931 for (i = 0 ; i < (sectors << (9-3)) ; i++, bbp++) { 1932 u64 bb = le64_to_cpu(*bbp); 1933 int count = bb & (0x3ff); 1934 u64 sector = bb >> 10; 1935 sector <<= sb->bblog_shift; 1936 count <<= sb->bblog_shift; 1937 if (bb + 1 == 0) 1938 break; 1939 if (!badblocks_set(&rdev->badblocks, sector, count, 1)) 1940 return -EINVAL; 1941 } bb->bblog_shit is in range of 0-255, variable sector is 64bit width, for an invalid bb->bblog_shit, it is possible to make sector be overflowed by the following calculation, 1935 sector <<= sb->bblog_shift; Then in turn when call badblocks_set() at line 1939 with the invalid rdev->badblocks.shift set at line 1930, may result an overflow inside _badblocks_clear() in block/badblocks.c. Although there are many places to call badblocks APIs, the non-zero shift value is only used in super_1_load(), other places always use 0 as the shift value. Therefore it is unnecessary to do a general shift value overflow check inside badblock API, and just check here as the caller. This may avoid unnecessary check, make the badblocks API code more simple and elegant.
Affected packages
| Ecosystem | Package | Introduced | Fixed |
|---|