GHSA-233M-C5R9-WQ53
Vulnerability from github – Published: 2026-09-11 21:31 – Updated: 2026-09-14 15:32In 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": [],
"aliases": [
"CVE-2026-89557"
],
"database_specific": {
"cwe_ids": [],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-09-11T20:19:39Z",
"severity": "HIGH"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nmd: do overflow check for sb-\u003ebblog_shift in super_1_load()\n\nIn super_1_load(), sb-\u003ebblog_shift is an __u8 type value loaded from on-\ndisk superblock. It is used for badblocks API badblocks_set() by the\nfollowing sequence,\n\n 1930 rdev-\u003ebadblocks.shift = sb-\u003ebblog_shift;\n 1931 for (i = 0 ; i \u003c (sectors \u003c\u003c (9-3)) ; i++, bbp++) {\n 1932 u64 bb = le64_to_cpu(*bbp);\n 1933 int count = bb \u0026 (0x3ff);\n 1934 u64 sector = bb \u003e\u003e 10;\n 1935 sector \u003c\u003c= sb-\u003ebblog_shift;\n 1936 count \u003c\u003c= sb-\u003ebblog_shift;\n 1937 if (bb + 1 == 0)\n 1938 break;\n 1939 if (!badblocks_set(\u0026rdev-\u003ebadblocks, sector, count, 1))\n 1940 return -EINVAL;\n 1941 }\n\nbb-\u003ebblog_shit is in range of 0-255, variable sector is 64bit width, for\nan invalid bb-\u003ebblog_shit, it is possible to make sector be overflowed\nby the following calculation,\n 1935 sector \u003c\u003c= sb-\u003ebblog_shift;\nThen in turn when call badblocks_set() at line 1939 with the invalid\nrdev-\u003ebadblocks.shift set at line 1930, may result an overflow inside\n_badblocks_clear() in block/badblocks.c.\n\nAlthough there are many places to call badblocks APIs, the non-zero\nshift value is only used in super_1_load(), other places always use 0 as\nthe shift value. Therefore it is unnecessary to do a general shift value\noverflow check inside badblock API, and just check here as the caller.\n\nThis may avoid unnecessary check, make the badblocks API code more simple\nand elegant.",
"id": "GHSA-233m-c5r9-wq53",
"modified": "2026-09-14T15:32:29Z",
"published": "2026-09-11T21:31:32Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-89557"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0a03f9541c06fda64301dcf94f376f07ce2cc396"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/323f3a056dbccb39a642ebde642044a680f3a6d6"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/35d522bd32462afcf1981dab6da8a9256c26c1e0"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3b097416b4cff77285c1f472fc2c4058d8a7554f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/573fb68105fdc6a127ba6069e58a0d2aff3c9f93"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/75d15738fd33a782606d0dc80cfeff47edf2ddd8"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/94c820d99a4305d4ded41a97ed37ec7d26c56e7f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/df7d4d011d5ace20699ea948712f09f9ac08924f"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.