{"id":"CVE-2026-99164","kind":"vulnerability","aliases":["CVE-2026-99164"],"related":[],"title":"Linux kernel: i.MX SPI DMA buffers undersized, corrupting slab memory","description":"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µs +/-2µs from its kref_get to kref_put. In\nthe error case the same sequence took about 215µs +/-10µs. 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.","summary":"The i.MX SPI driver allocates its DMA bounce buffers smaller than the length it maps, so DMA operations run past the end of the allocation. On a reported i.MX8MP system this corrupted kernel memory and eventually caused crashes; the sources do not describe remote code execution.","severity":"low","cvss":null,"epss":null,"exploited":false,"exploited_at":null,"products":[],"ecosystems":[],"tags":["embedded","imx8mp","linux-kernel","other"],"not_affected_if":["dma-mode-off","no-imx-spi"],"how_to_check":"- Run `uname -r` and compare against the fixed kernel release, which the sources do not name\n- Check whether the i.MX ECSPI driver (spi-imx) is loaded with `lsmod | grep spi_imx` and whether DMA mode is used (unknown from sources)","fix":"- Update to a Linux kernel build that includes the upstream commit fixing spi: imx DMA bounce buffer allocation (version unknown from sources)","status":"open","published_at":"2026-10-28T11:17:36+00:00","first_seen_at":"2026-10-28T11:32:36+00:00","triaged_at":"2026-10-28T11:35:43+00:00","updated_at":"2026-10-28T11:35:43+00:00","category":"other","confidence":0.6,"triage":{"at":"2026-10-28T11:35:43Z","model":"claude-haiku-5-5","output":{"fix":"- Update to a Linux kernel build that includes the upstream commit fixing spi: imx DMA bounce buffer allocation (version unknown from sources)","reach":"local","title":"Linux kernel: i.MX SPI DMA buffers undersized, corrupting slab memory","impact":"medium","summary":"The i.MX SPI driver allocates its DMA bounce buffers smaller than the length it maps, so DMA operations run past the end of the allocation. On a reported i.MX8MP system this corrupted kernel memory and eventually caused crashes; the sources do not describe remote code execution.","category":"other","nicknames":[],"who_cares":["linux-kernel","imx8mp","embedded"],"confidence":0.6,"needs_auth":"unknown","worst_case":"kernel memory corruption causes crashes; code execution not described","analyst_note":"Check the NVD entry and the upstream kernel commit for affected and fixed kernel versions and any exploitability statement.","how_to_check":"- Run `uname -r` and compare against the fixed kernel release, which the sources do not name\n- Check whether the i.MX ECSPI driver (spi-imx) is loaded with `lsmod | grep spi_imx` and whether DMA mode is used (unknown from sources)","needs_analyst":true,"not_affected_if":["no-imx-spi","dma-mode-off"],"who_is_affected":"Systems running a Linux kernel with the i.MX ECSPI driver in DMA mode, such as i.MX8MP boards with SPI peripherals under heavy DMA or RPMSG load. The sources describe a custom platform with an mcp251xfd CAN controller; the sources do not say whether other boards are affected in practice. Systems without i.MX SPI hardware can skip it.","user_interaction":"no","needs_special_setup":"yes","severity_if_unknown":"low"},"cost_usd":0.000714,"input_tokens":3924,"output_tokens":643,"severity_before":"unknown"},"analyst_status":null,"analyst_note":null,"search":"'-10':296C '-2':277C '-2026':12A,15A '-99164':13A,16A '0':196C '1':256C '11µs':276C '2':254C '200':358C '215µs':295C '30':229C,233C '4':121C 'addit':194C,265C 'align':132C,318C 'alloc':26B,46B,103C,158C,312C 'api':149C 'appli':350C 'base':298C 'beyond':153C 'bounc':29B,86C 'buffer':6A,30B,87C,108C,314C 'burst':95C 'bus':191C 'byte':122C 'cach':131C,141C,317C 'case':289C 'caus':58B 'code':66B 'commit':89C 'consist':342C 'control':171C 'corrupt':8A,53B,82C 'cover':324C 'cpu':339C 'crash':59B 'custom':164C 'cve':11A,14A 'describ':64B 'dma':5A,28B,38B,85C,99C,106C,111C,114C,130C,134C,148C,316C,320C,335C 'done':187C,274C 'driver':25B,102C 'dynam':94C 'ecspi':98C 'embed':17B 'end':43B,155C 'endpoint':248C 'error':288C 'eventu':57B 'execut':67B 'faa8e404ad8e':90C 'final':214C 'fix':80C,310C 'follow':73C 'found':268C 'free':200C,207C 'full':326C 'generic':260C 'get':282C 'handl':219C 'hardwar':239C 'heavi':173C 'hour':234C,359C 'i.e':136C 'i.mx':3A,23B 'i.mx8mp':50B,165C 'identifi':306C 'imx':79C,92C 'imx8mp':18B 'irq/155-spi2.0':263C 'kernel':2A,21B,54B,71C,220C 'kref':281C,284C 'kzalloc':110C 'lead':213C 'leak':211C 'len':112C,115C,133C,135C,319C,321C 'length':34B,96C,328C,333C 'line':142C 'linux':1A,20B,70C 'linux-kernel':19B 'llm':302C 'load':175C 'map':36B,124C,327C,344C 'mcp251xfd':169C 'memcpi':259C 'memori':10A,55B,152C,212C 'minut':230C 'mismatch':309C 'mode':100C 'normal':271C 'observ':161C 'oop':223C 'oper':39B,150C 'overwritten':252C 'page':221C 'past':41B 'patch':349C 'pi':258C 'platform':166C 'privat':105C 'problem':226C,362C 'put':285C 'ran':354C 'recv':186C,273C 'refcount':180C,192C,201C,208C,243C 'remot':65B 'report':49B 'reproduc':224C,363C 'request':222C 'resolv':77C 'result':146C 'rough':232C 'round':118C,137C 'rpmsg':174C,185C,190C,247C,272C 'run':40B 'satur':210C 'sequenc':292C 'seri':178C 'show':249C 'sinc':88C 'singl':337C 'size':143C,308C 'slab':9A,81C 'smaller':31B 'sourc':61B 'spi':4A,24B,78C,91C 'stay':341C 'struct':246C 'support':93C 'sync':125C,336C 'system':51B 'thread':264C 'took':227C,275C,293C 'trigger':183C 'tx/rx':107C 'unabl':217C 'underflow':203C 'unders':7A,84C 'unmap':127C,346C 'use':198C,205C,304C,330C 'use-after-fre':197C,204C 'virtio':189C 'vulner':74C 'warn':182C 'watchpoint':240C 'without':360C 'workload':238C,353C 'µs':278C,297C","nicknames":[],"mitigations":[],"who_affected":"Systems running a Linux kernel with the i.MX ECSPI driver in DMA mode, such as i.MX8MP boards with SPI peripherals under heavy DMA or RPMSG load. The sources describe a custom platform with an mcp251xfd CAN controller; the sources do not say whether other boards are affected in practice. Systems without i.MX SPI hardware can skip it.","tier":"C","verified":{},"analyst_revisit_at":null,"first_public_at":"2026-10-28T11:17:36+00:00","kev":null,"cvss_vector":null,"cvss_by":null,"poc_count":0,"sources":[{"source":"nvd","external_id":"CVE-2026-99164","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-99164","severity":null,"published_at":"2026-10-28T11:17:36+00:00","modified_at":"2026-10-28T11:17:36+00:00","first_seen_at":"2026-10-28T11:32:36+00:00","fetched_at":"2026-10-28T11:32:36+00:00","note":null}],"documents":[],"notice":"Free to read at a human pace. An API with keys and an MCP server are in preparation; early access: hello@infrastack.ai"}