CVE-2026-89557
massLinux kernel md RAID: unchecked bblog_shift in super_1_load() enables kernel memory corruption
The Linux kernel's md (software RAID) driver fails to validate sb->bblog_shift, an 8-bit field read from an on-disk RAID superblock (version 1.x) in super_1_load(). An attacker with local access and write permission to a block device can plant a crafted superblock whose shift value causes a 64-bit sector calculation to overflow, which in turn triggers an overflow inside the kernel badblocks handling code (_badblocks_clear() in block/badblocks.c). Successful exploitation of this memory corruption could allow privilege escalation or a kernel crash, consistent with the CVSS 7.8 rating (local vector, low privileges required). Any Linux system that assembles md RAID arrays with superblock version 1 from disks an attacker could have written to is potentially affected. No public proof of concept is known and the flaw is not listed in the CISA KEV catalog.
What to do: Apply distribution kernel updates that include the upstream fix adding the bblog_shift overflow check in super_1_load() and reboot into the patched kernel. Restrict write access to raw block devices and disk devices being added to md arrays, and treat second-hand or untrusted disks as hostile: inspect or wipe their superblocks (e.g., mdadm --zero-superblock) before assembly. Check whether hosts auto-assemble arrays at boot from removable or untrusted media, since that is the most realistic path to a malicious superblock being parsed.
| Linux kernel (md raid1/raid456/etc. superblock v1 handling, super_1_load) | — |
Order-of-magnitude estimate by the model from install counts, market share and public scan data it knows; verify before quoting.
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 > 10; 1935 sector bblog_shift; 1936 count 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 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.
- Vector
- CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
In the news0 stories
No ingested article mentions this CVE yet.