{
  "cveId": "CVE-2026-90133",
  "url": "https://patchblox.com/security/cve/CVE-2026-90133",
  "summary": "CVE-2026-90133 is fixed in linux on 1 platform by DEBIAN-CVE-2026-90133 (version 7.2.6-1), released September 23, 2026. It is not reported as exploited. Patch Radar priority: High.",
  "title": "linux: In the Linux kernel, the following vulnerability has been resolved:  ntfs: Fix index_root heap OOB write in ntfs_ir_t...",
  "description": "In the Linux kernel, the following vulnerability has been resolved:  ntfs: Fix index_root heap OOB write in ntfs_ir_to_ib()  ntfs_ir_to_ib copies all entries from index_root into a freshly allocated index_block_size-byte buffer without verifying that the entries fit in the available space. The entries in index_root may be larger than the usable entry space in the index block.  This can cause OOB writes past the end of the allocation.  The validator ntfs_index_root_inconsistent() checks that entries are self-consistent within the IR value, but never cross-checks them against index_block_size. There is no bounds check in ntfs_ir_to_ib() before the memcpy.  Fixing this at the sink in ntfs_ir_to_ib() since ntfs_index_root_inconsistent() validates the logical consistency of index_root as a structure and a root with large entries is a structurally valid root. The bug is a size conflict of ntfs_ir_to_ib(). Also, the validator is called once per inode load in ntfs_read_locked_inode() while ntfs_ir_to_ib() is only called during a reparent, a check there adds no overhead to the common path. Moreover, even a future call path that bypasses the validator would still be protected.  With NULL as first parameter of ntfs_error(), the volume error flag is never set by this call, so the device name will be absent from the error message. In any case, that the caller, ntfs_ir_reparent(), prints an error message that includes the device name on NULL returns. I think this is the best solution available without adding \u0027struct super_block *sb\u0027 as a parameter to ntfs_ir_to_ib().  This heap out-of-bounds write is triggered by a crafted filesystem image, which is not in the kernel threat model, anyway, fixing memory errors would be nice to keep  things secure.",
  "published": "2026-09-17T17:17:05Z",
  "severity": "high",
  "cvss": 7.8,
  "cvssVector": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
  "epss": 0.00205,
  "epssPercentile": 0.10496,
  "priority": "High",
  "priorityTier": 3,
  "exploited": false,
  "vendorExploited": false,
  "disclosed": false,
  "fixes": [
    {
      "platform": "linux",
      "product": "linux",
      "release": "Debian 14",
      "fixedVersion": "7.2.6-1",
      "fix": "DEBIAN-CVE-2026-90133",
      "url": "https://patchblox.com/security/fix/linux/debian-cve-2026-90133",
      "released": "2026-09-23T19:19:02Z"
    }
  ],
  "noFixYet": [],
  "dataAsOf": "2026-11-08T06:59:42Z",
  "attribution": {
    "text": "Data: Patchblox Patch Radar",
    "url": "https://patchblox.com/security/patch-radar",
    "terms": "https://patchblox.com/security/patch-radar/use-the-data"
  }
}