GHSA-233M-C5R9-WQ53

Vulnerability from github – Published: 2026-09-11 21:31 – Updated: 2026-09-14 15:32
VLAI
Details

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.

Severity
7.8 (High)
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "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"
    }
  ]
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.




Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.

Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

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.
Vulnerability timeline

Sightings and recorded dates, grouped by day · UTC

JSON
How durations are calculated

Following the VTEM framework (Black Hat USA 2015), time to patch starts when the vendor or a coordinator was informed, total time to patch at discovery, and disclosure to patch at public disclosure; vendor response time runs from the report to its acknowledgement. Time to exploit and time unpatched start at the earliest discovery or report, falling back to public disclosure. Unpatched time ends at the first recorded patch, or the calculation time when no patch is recorded. Exploitation to patch shows the interval between those two events; a published proof of concept is a public exploit, not exploitation.

Each result shows its source dates. A negative interval means the end event came first; when date-only inputs leave the order open, the result says so. Date-only inputs are approximate. The earliest evidence wins: KEV report dates and sightings are labelled as such. Records describing another vulnerability are listed but never calculated from, and a PoC alone does not establish exploitation. Missing patch evidence does not prove that no patch exists. Filters below change the event list only.

Loading timeline…




    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.