GHSA-JMR9-WC6R-PJ32

Vulnerability from github – Published: 2026-08-15 15:30 – Updated: 2026-08-23 15:33
VLAI
Details

In the Linux kernel, the following vulnerability has been resolved:

scsi: scsi_debug: Fix REPORT ZONES alloc_len underflow OOB write

resp_report_zones() sizes the reply buffer from the CDB allocation length. The v3 fix rounds alloc_len up with ALIGN() before deriving the descriptor count:

rep_max_zones = (ALIGN((u64)alloc_len, RZONES_DESC_HD) -
         RZONES_DESC_HD) >> ilog2(RZONES_DESC_HD);
arr_len = (u64)RZONES_DESC_HD * (rep_max_zones + 1);

For alloc_len in 0xFFFFFFC1..0xFFFFFFFF, ALIGN() rounds up to 0x100000000, so arr_len is 4 GB. On 32-bit, kzalloc()'s size_t is 32-bit and truncates 0x100000000 to 0; kzalloc(0) returns ZERO_SIZE_PTR, which passes the !arr check, and desc = arr + 64 is then dereferenced in the loop -> out-of-bounds write / panic.

Clamp rep_max_zones to devip->nr_zones. The loop already stops at sdebug_capacity (after nr_zones zones), so a report can never hold more than nr_zones descriptors; the clamp does not change the report, it only bounds arr_len to (nr_zones + 1) * RZONES_DESC_HD, a real device property that can never reach 0x100000000.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-74470"
  ],
  "database_specific": {
    "cwe_ids": [],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-08-15T13:17:51Z",
    "severity": "HIGH"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: scsi_debug: Fix REPORT ZONES alloc_len underflow OOB write\n\nresp_report_zones() sizes the reply buffer from the CDB allocation\nlength. The v3 fix rounds alloc_len up with ALIGN() before deriving the\ndescriptor count:\n\n\trep_max_zones = (ALIGN((u64)alloc_len, RZONES_DESC_HD) -\n\t\t\t RZONES_DESC_HD) \u003e\u003e ilog2(RZONES_DESC_HD);\n\tarr_len = (u64)RZONES_DESC_HD * (rep_max_zones + 1);\n\nFor alloc_len in 0xFFFFFFC1..0xFFFFFFFF, ALIGN() rounds up to\n0x100000000, so arr_len is 4 GB. On 32-bit, kzalloc()\u0027s size_t is 32-bit\nand truncates 0x100000000 to 0; kzalloc(0) returns ZERO_SIZE_PTR, which\npasses the !arr check, and desc = arr + 64 is then dereferenced in the\nloop -\u003e out-of-bounds write / panic.\n\nClamp rep_max_zones to devip-\u003enr_zones. The loop already stops at\nsdebug_capacity (after nr_zones zones), so a report can never hold more\nthan nr_zones descriptors; the clamp does not change the report, it only\nbounds arr_len to (nr_zones + 1) * RZONES_DESC_HD, a real device\nproperty that can never reach 0x100000000.",
  "id": "GHSA-jmr9-wc6r-pj32",
  "modified": "2026-08-23T15:33:02Z",
  "published": "2026-08-15T15:30:33Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-74470"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/2047ed09bf13453b7d6f9431b112ec07984dd69b"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/495058429ca55ab7fcc21977b63b92907ad68066"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/49e5b25a0b74dbac595f122e5608fdce2918cc4e"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/5d3e1d006bbb543259f9e31824caadbfff6a5465"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/7b615fc139e35c81077046df44725c532f7e2404"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/93dde0bf2f39a0f9f57fd610aa3201ce5b753433"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/d6e6da6bc3b53231fac77ffab428da8173ee729c"
    }
  ],
  "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.


Loading…

Loading…

Loading…

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.

Loading…

Detection rules are retrieved from Rulezet.

Loading…

Loading…

Loading…