CVE-2026-99164 (GCVE-0-2026-99164)

Vulnerability from cvelistv5 – Published: 2026-10-28 10:35 – Updated: 2026-10-31 12:44
VLAI
Title
spi: imx: fix slab corruption from undersized DMA bounce buffers
Summary
In the Linux kernel, the following vulnerability has been resolved: spi: imx: fix slab corruption from undersized DMA bounce buffers Since commit faa8e404ad8e ("spi: imx: support dynamic burst length for ECSPI DMA mode"), the driver allocates its private DMA TX/RX buffers with kzalloc(dma_len), where dma_len is only rounded up to 4 bytes, but maps, syncs and unmaps them with DMA_CACHE_ALIGNED_LEN(dma_len), i.e. rounded up to the cache line size. As a result, the DMA API operates on memory beyond the end of the allocation. This was observed on a custom i.MX8MP platform with an mcp251xfd CAN controller under heavy RPMSG load, as a series of refcount_t warnings triggered from rpmsg_recv_done() in virtio_rpmsg_bus: refcount_t: addition on 0; use-after-free. refcount_t: underflow; use-after-free. refcount_t: saturated; leaking memory. Leading finally to an "Unable to handle kernel paging request" oops. Reproducing this problem took between 30 minutes and roughly 30 hours under the same workload. Hardware watchpoints on the refcount of a struct rpmsg_endpoint showed it was overwritten from 2 to 1 by __pi_memcpy_generic() in the irq/155-spi2.0 thread. Additionally it was found that a "normal" rpmsg_recv_done() took 11µs +/-2µs from its kref_get to kref_put. In the error case the same sequence took about 215µs +/-10µs. Based on this, an LLM was used to identify the size mismatch fixed here. Allocate the buffers with DMA_CACHE_ALIGNED_LEN(dma_len) so they cover the full mapped length, and use the same length for dma_sync_single_for_cpu() to stay consistent with map and unmap. With this patch applied, the same workload ran for more than 200 hours without the problem reproducing.
Severity
7.8 (High)
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Assigner
Linux CNA under the mitre root
CNA scorecard D 53/100 over 6637 records in the last 180 days details
References
Impacted products
Vendor Product Version CPE status
Linux Linux Affected: faa8e404ad8e686cb98c51dc507fdcacfb8020ce , < 2777f6637da02da84c9c1ff92f413ce0f0995084 (git)
Affected: faa8e404ad8e686cb98c51dc507fdcacfb8020ce , < 59eb22641f0c526dd064390b11cff99ae87c2858 (git)
guessed Create a notification for this product.
Linux Linux Affected: 7.0
Unaffected: 0 , < 7.0 (semver)
Unaffected: 7.2.13 , ≤ 7.2.* (semver)
Unaffected: 7.3 , ≤ * (original_commit_for_fix)
guessed Create a notification for this product.
Show details on NVD website
To clipboard 

{
  "containers": {
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "product": "Linux",
          "programFiles": [
            "drivers/spi/spi-imx.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "lessThan": "2777f6637da02da84c9c1ff92f413ce0f0995084",
              "status": "affected",
              "version": "faa8e404ad8e686cb98c51dc507fdcacfb8020ce",
              "versionType": "git"
            },
            {
              "lessThan": "59eb22641f0c526dd064390b11cff99ae87c2858",
              "status": "affected",
              "version": "faa8e404ad8e686cb98c51dc507fdcacfb8020ce",
              "versionType": "git"
            }
          ]
        },
        {
          "defaultStatus": "affected",
          "product": "Linux",
          "programFiles": [
            "drivers/spi/spi-imx.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "status": "affected",
              "version": "7.0"
            },
            {
              "lessThan": "7.0",
              "status": "unaffected",
              "version": "0",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "7.2.*",
              "status": "unaffected",
              "version": "7.2.13",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "*",
              "status": "unaffected",
              "version": "7.3",
              "versionType": "original_commit_for_fix"
            }
          ]
        }
      ],
      "cpeApplicability": [
        {
          "nodes": [
            {
              "cpeMatch": [
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "7.2.13",
                  "versionStartIncluding": "7.0",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "7.3",
                  "versionStartIncluding": "7.0",
                  "vulnerable": true
                }
              ],
              "negate": false,
              "operator": "OR"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nspi: imx: fix slab corruption from undersized DMA bounce buffers\n\nSince commit faa8e404ad8e (\"spi: imx: support dynamic burst length for\nECSPI DMA mode\"), the driver allocates its private DMA TX/RX buffers\nwith kzalloc(dma_len), where dma_len is only rounded up to 4 bytes, but\nmaps, syncs and unmaps them with DMA_CACHE_ALIGNED_LEN(dma_len), i.e.\nrounded up to the cache line size. As a result, the DMA API operates on\nmemory beyond the end of the allocation.\n\nThis was observed on a custom i.MX8MP platform with an mcp251xfd CAN\ncontroller under heavy RPMSG load, as a series of refcount_t warnings\ntriggered from rpmsg_recv_done() in virtio_rpmsg_bus:\n\n  refcount_t: addition on 0; use-after-free.\n  refcount_t: underflow; use-after-free.\n  refcount_t: saturated; leaking memory.\n\nLeading finally to an \"Unable to handle kernel paging request\" oops.\nReproducing this problem took between 30 minutes and roughly 30 hours\nunder the same workload.\n\nHardware watchpoints on the refcount of a struct rpmsg_endpoint showed\nit was overwritten from 2 to 1 by __pi_memcpy_generic() in the\nirq/155-spi2.0 thread. Additionally it was found that a \"normal\"\nrpmsg_recv_done() took 11\u00b5s +/-2\u00b5s from its kref_get to kref_put. In\nthe error case the same sequence took about 215\u00b5s +/-10\u00b5s. Based on\nthis, an LLM was used to identify the size mismatch fixed here.\n\nAllocate the buffers with DMA_CACHE_ALIGNED_LEN(dma_len) so they cover\nthe full mapped length, and use the same length for\ndma_sync_single_for_cpu() to stay consistent with map and unmap.\n\nWith this patch applied, the same workload ran for more than 200 hours\nwithout the problem reproducing."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "baseScore": 7.8,
            "baseSeverity": "HIGH",
            "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
            "version": "3.1"
          },
          "scenarios": [
            {
              "lang": "en",
              "value": "AV:L - A local caller can issue a 64-byte SPI_IOC_MESSAGE through spidev_ioctl()-\u003espidev_message()-\u003espi_sync()-\u003espi_transfer_one_message()-\u003espi_imx_transfer_one()-\u003espi_imx_dma_transfer()-\u003espi_imx_dma_tx_data_handle(). The faulty length is generated by spi_imx_dma_map(), not supplied by a remote CAN message.\nAC:L - spi_imx_can_dma() accepts caller-controlled transfers of at least 64 bytes; on arm64, 64 bytes deterministically makes spi_imx_dma_map() map 128 bytes after spi_imx_dma_tx_data_handle() allocated 64. The caller can repeat transfers and set word_delay to widen the corruption window without an uncontrollable hardware fault.\nPR:L - spidev_open() and spidev_ioctl() contain no capable() check, so an ordinary account with access to an existing /dev/spidev node can submit the transfer. Independently, can_create() and raw_sendmsg() let an unprivileged local user drive qualifying MCP251xFD CAN-FD SPI transfers on an already-up interface.\nUI:N - The attacker invokes spidev_ioctl() or CAN raw_sendmsg() directly, and those operations reach the faulty DMA mapping without another user mounting media, opening a file, or approving a transfer.\nS:U - spi_imx_dma_map() and spi_imx_dma_unmap() corrupt neighboring allocations in the same host kernel; the path crosses no VM, IOMMU, or other security-authority boundary.\nC:H - The oversized DMA_FROM_DEVICE cache maintenance reverted an adjacent struct rpmsg_endpoint refcount from 2 to 1, allowing __ept_release() to free an endpoint while it remained in use. This demonstrated UAF can expose reclaimed kernel-object contents.\nI:H - spi_imx_dma_unmap() invalidates cache lines beyond the undersized dma_rx_buf, demonstrably altering an adjacent rpmsg_endpoint refcount and creating a UAF. Reclaiming that freed object can convert the slab corruption into attacker-influenced writes or control-flow corruption.\nA:H - The corrupted rpmsg_endpoint refcount produced addition-on-zero, underflow, and saturation warnings and ultimately an Unable to handle kernel paging request oops, demonstrating a kernel crash."
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-10-31T12:44:24.973Z",
        "orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "shortName": "Linux"
      },
      "references": [
        {
          "url": "https://git.kernel.org/stable/c/2777f6637da02da84c9c1ff92f413ce0f0995084"
        },
        {
          "url": "https://git.kernel.org/stable/c/59eb22641f0c526dd064390b11cff99ae87c2858"
        }
      ],
      "title": "spi: imx: fix slab corruption from undersized DMA bounce buffers",
      "x_generator": {
        "engine": "bippy-1.2.0"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
    "assignerShortName": "Linux",
    "cveId": "CVE-2026-99164",
    "datePublished": "2026-10-28T10:35:16.694Z",
    "dateReserved": "2026-09-25T10:25:14.398Z",
    "dateUpdated": "2026-10-31T12:44:24.973Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2",
  "vulnerability-lookup:meta": {
    "epss": {
      "cve": "CVE-2026-99164",
      "date": "2026-11-06",
      "epss": "0.0013",
      "percentile": "0.02636"
    },
    "nvd": {
      "cve": {
        "affected": [
          {
            "affectedData": [
              {
                "defaultStatus": "unaffected",
                "product": "Linux",
                "programFiles": [
                  "drivers/spi/spi-imx.c"
                ],
                "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
                "vendor": "Linux",
                "versions": [
                  {
                    "lessThan": "2777f6637da02da84c9c1ff92f413ce0f0995084",
                    "status": "affected",
                    "version": "faa8e404ad8e686cb98c51dc507fdcacfb8020ce",
                    "versionType": "git"
                  },
                  {
                    "lessThan": "59eb22641f0c526dd064390b11cff99ae87c2858",
                    "status": "affected",
                    "version": "faa8e404ad8e686cb98c51dc507fdcacfb8020ce",
                    "versionType": "git"
                  }
                ]
              },
              {
                "defaultStatus": "affected",
                "product": "Linux",
                "programFiles": [
                  "drivers/spi/spi-imx.c"
                ],
                "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
                "vendor": "Linux",
                "versions": [
                  {
                    "status": "affected",
                    "version": "7.0"
                  },
                  {
                    "lessThan": "7.0",
                    "status": "unaffected",
                    "version": "0",
                    "versionType": "semver"
                  },
                  {
                    "lessThanOrEqual": "7.2.*",
                    "status": "unaffected",
                    "version": "7.2.13",
                    "versionType": "semver"
                  },
                  {
                    "lessThanOrEqual": "*",
                    "status": "unaffected",
                    "version": "7.3",
                    "versionType": "original_commit_for_fix"
                  }
                ]
              }
            ],
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
          }
        ],
        "cveTags": [],
        "descriptions": [
          {
            "lang": "en",
            "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nspi: imx: fix slab corruption from undersized DMA bounce buffers\n\nSince commit faa8e404ad8e (\"spi: imx: support dynamic burst length for\nECSPI DMA mode\"), the driver allocates its private DMA TX/RX buffers\nwith kzalloc(dma_len), where dma_len is only rounded up to 4 bytes, but\nmaps, syncs and unmaps them with DMA_CACHE_ALIGNED_LEN(dma_len), i.e.\nrounded up to the cache line size. As a result, the DMA API operates on\nmemory beyond the end of the allocation.\n\nThis was observed on a custom i.MX8MP platform with an mcp251xfd CAN\ncontroller under heavy RPMSG load, as a series of refcount_t warnings\ntriggered from rpmsg_recv_done() in virtio_rpmsg_bus:\n\n  refcount_t: addition on 0; use-after-free.\n  refcount_t: underflow; use-after-free.\n  refcount_t: saturated; leaking memory.\n\nLeading finally to an \"Unable to handle kernel paging request\" oops.\nReproducing this problem took between 30 minutes and roughly 30 hours\nunder the same workload.\n\nHardware watchpoints on the refcount of a struct rpmsg_endpoint showed\nit was overwritten from 2 to 1 by __pi_memcpy_generic() in the\nirq/155-spi2.0 thread. Additionally it was found that a \"normal\"\nrpmsg_recv_done() took 11\u00b5s +/-2\u00b5s from its kref_get to kref_put. In\nthe error case the same sequence took about 215\u00b5s +/-10\u00b5s. Based on\nthis, an LLM was used to identify the size mismatch fixed here.\n\nAllocate the buffers with DMA_CACHE_ALIGNED_LEN(dma_len) so they cover\nthe full mapped length, and use the same length for\ndma_sync_single_for_cpu() to stay consistent with map and unmap.\n\nWith this patch applied, the same workload ran for more than 200 hours\nwithout the problem reproducing."
          }
        ],
        "id": "CVE-2026-99164",
        "lastModified": "2026-10-31T13:17:58.290",
        "metrics": {
          "cvssMetricV31": [
            {
              "cvssData": {
                "attackComplexity": "LOW",
                "attackVector": "LOCAL",
                "availabilityImpact": "HIGH",
                "baseScore": 7.8,
                "baseSeverity": "HIGH",
                "confidentialityImpact": "HIGH",
                "integrityImpact": "HIGH",
                "privilegesRequired": "LOW",
                "scope": "UNCHANGED",
                "userInteraction": "NONE",
                "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
                "version": "3.1"
              },
              "exploitabilityScore": 1.8,
              "impactScore": 5.9,
              "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
              "type": "Secondary"
            }
          ]
        },
        "published": "2026-10-28T11:17:36.760",
        "references": [
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "url": "https://git.kernel.org/stable/c/2777f6637da02da84c9c1ff92f413ce0f0995084"
          },
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "url": "https://git.kernel.org/stable/c/59eb22641f0c526dd064390b11cff99ae87c2858"
          }
        ],
        "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "vulnStatus": "Received"
      }
    },
    "redhat_vex": {
      "aggregate_severity": "Moderate",
      "current_release_date": "2026-11-06T03:27:32+00:00",
      "cve": "CVE-2026-99164",
      "id": "CVE-2026-99164",
      "initial_release_date": "2026-10-28T10:35:16.694000+00:00",
      "product_status:known_affected": "112",
      "product_status:known_not_affected": "91",
      "source": "Red Hat CSAF VEX",
      "status": "final",
      "title": "kernel: kernel: Denial of Service via undersized DMA bounce buffers in i.MX SPI driver",
      "url": "https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-99164.json",
      "version": "3"
    },
    "suse_vex": {
      "aggregate_severity": "important",
      "current_release_date": "2026-11-03T17:34:19Z",
      "cve": "CVE-2026-99164",
      "id": "CVE-2026-99164",
      "initial_release_date": "2026-11-03T17:34:19Z",
      "product_status:known_not_affected": "348",
      "source": "SUSE CSAF VEX",
      "status": "interim",
      "title": "SUSE CVE CVE-2026-99164",
      "url": "https://ftp.suse.com/pub/projects/security/csaf-vex/2026/cve-2026-99164.json",
      "version": "2"
    }
  }
}



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.