CVE-2026-89557

md: do overflow check for sb->bblog_shift in super_1_load()

HIGH
7.8
CVSS Score
Published: September 11, 2026 at 07:44 PM UTC
Updated: October 19, 2026 at 09:17 AM UTC
1 product affected across 1 vendorLinux Kernel

Using Linux by Linux?

Get instant alerts when new vulnerabilities affect Linux - before attackers find them.

Real-time alertsTrack your software stackFree plan available
Severity
HIGH7.8
Exploit prediction
EPSS 0.2%
SSVC
No known exploit

Description

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

Our own answer: ranges merged, affected separated from platform-only, with confidence and review flags.

2699b67223aca6b1450fc2f72e40fada952afc853.1
Vendor states this is fixed in 0a03f9541c06fda64301dcf94f376f07ce2cc396 (fixed)
Vendor states this is fixed in 323f3a056dbccb39a642ebde642044a680f3a6d6 (fixed)
Vendor states this is fixed in 35d522bd32462afcf1981dab6da8a9256c26c1e0 (fixed)
Vendor states this is fixed in 3b097416b4cff77285c1f472fc2c4058d8a7554f (fixed)
Vendor states this is fixed in 573fb68105fdc6a127ba6069e58a0d2aff3c9f93 (fixed)
Vendor states this is fixed in 75d15738fd33a782606d0dc80cfeff47edf2ddd8 (fixed)
Vendor states this is fixed in 94c820d99a4305d4ded41a97ed37ec7d26c56e7f (fixed)
Vendor states this is fixed in df7d4d011d5ace20699ea948712f09f9ac08924f (fixed)
Vendor states this is fixed in 3.1 (unaffected)
Vendor states this is fixed in 5.10.270 (unaffected)
Vendor states this is fixed in 5.15.221 (unaffected)
Vendor states this is fixed in 6.1.188 (unaffected)
Vendor states this is fixed in 6.12.109 (unaffected)
Vendor states this is fixed in 6.18.50 (unaffected)
Vendor states this is fixed in 6.6.157 (unaffected)
Vendor states this is fixed in 7.2.4 (unaffected)
Vendor states this is fixed in 7.3 (unaffected)
Vendor states this is fixed in 7.3-rc1 (unaffected)

Remediation

No guide yet

No remediation guidance has been written for this CVE yet, and no fixed version or vendor advisory is recorded against it.

SSVC — Action Prioritization

SSVCNo known exploitNot automatableTotal impact

SSVC signals action urgency (what to patch first), separate from CVSS which measures severity.

CVSS

7.8HIGHLinux
Vector?

Quick Info

StatusRECEIVED

Get alerted

Stop reading CVE feeds looking for your own stack

Track the products you run and VulnTracker tells you when a new CVE affects them — with what is known about fixing it, and nothing about the rest.

Free plan, no card