{ "schema_version": "1.6.1", "id": "RPI-CVE-2024-40970", "modified": "2026-10-09T11:39:44Z", "upstream": [ "CVE-2024-40970" ], "published": "2024-07-12T12:32:42Z", "summary": "Avoid hw_desc array overrun in dw-axi-dmac", "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nAvoid hw_desc array overrun in dw-axi-dmac\n\nI have a use case where nr_buffers = 3 and in which each descriptor is composed by 3\nsegments, resulting in the DMA channel descs_allocated to be 9. Since axi_desc_put()\nhandles the hw_desc considering the descs_allocated, this scenario would result in a\nkernel panic (hw_desc array will be overrun).\n\nTo fix this, the proposal is to add a new member to the axi_dma_desc structure,\nwhere we keep the number of allocated hw_descs (axi_desc_alloc()) and use it in\naxi_desc_put() to handle the hw_desc array correctly.\n\nAdditionally I propose to remove the axi_chan_start_first_queued() call after completing\nthe transfer, since it was identified that unbalance can occur (started descriptors can\nbe interrupted and transfer ignored due to DMA channel not being enabled).", "severity": [ { "type": "CVSS_V3", "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H" } ], "affected": [ { "package": { "ecosystem": "Raspberry Pi OS:12", "name": "linux" }, "versions": [ "1:6.1.47-1+rpt4", "1:6.1.54-1+rpt2", "1:6.1.58-1+rpt2", "1:6.1.63-1+rpt1", "1:6.1.73-1+rpt1", "1:6.6.20-1+rpt1", "1:6.6.28-1+rpt1", "1:6.6.31-1+rpt1" ], "ecosystem_specific": { "binaries": [ { "binary_name": "linux-image-6.1.0-rpi3-rpi-2712", "binary_version": "1:6.1.47-1+rpt4" }, { "binary_name": "linux-image-6.1.0-rpi3-rpi-v6", "binary_version": "1:6.1.47-1+rpt4" }, { "binary_name": "linux-image-6.1.0-rpi3-rpi-v7", "binary_version": "1:6.1.47-1+rpt4" }, { "binary_name": "linux-image-6.1.0-rpi3-rpi-v7l", "binary_version": "1:6.1.47-1+rpt4" }, { "binary_name": "linux-image-6.1.0-rpi3-rpi-v8", "binary_version": "1:6.1.47-1+rpt4" }, { "binary_name": "linux-image-6.1.0-rpi4-rpi-2712", "binary_version": "1:6.1.54-1+rpt2" }, { "binary_name": "linux-image-6.1.0-rpi4-rpi-v8", "binary_version": "1:6.1.54-1+rpt2" }, { "binary_name": "linux-image-6.1.0-rpi6-rpi-2712", "binary_version": "1:6.1.58-1+rpt2" }, { "binary_name": "linux-image-6.1.0-rpi6-rpi-v8", "binary_version": "1:6.1.58-1+rpt2" }, { "binary_name": "linux-image-6.1.0-rpi7-rpi-2712", "binary_version": "1:6.1.63-1+rpt1" }, { "binary_name": "linux-image-6.1.0-rpi7-rpi-v8", "binary_version": "1:6.1.63-1+rpt1" }, { "binary_name": "linux-image-6.1.0-rpi8-rpi-2712", "binary_version": "1:6.1.73-1+rpt1" }, { "binary_name": "linux-image-6.1.0-rpi8-rpi-v8", "binary_version": "1:6.1.73-1+rpt1" }, { "binary_name": "linux-image-6.6.20+rpt-rpi-2712", "binary_version": "1:6.6.20-1+rpt1" }, { "binary_name": "linux-image-6.6.20+rpt-rpi-v8", "binary_version": "1:6.6.20-1+rpt1" }, { "binary_name": "linux-image-6.6.28+rpt-rpi-2712", "binary_version": "1:6.6.28-1+rpt1" }, { "binary_name": "linux-image-6.6.28+rpt-rpi-v8", "binary_version": "1:6.6.28-1+rpt1" }, { "binary_name": "linux-image-6.6.31+rpt-rpi-2712", "binary_version": "1:6.6.31-1+rpt1" }, { "binary_name": "linux-image-6.6.31+rpt-rpi-v8", "binary_version": "1:6.6.31-1+rpt1" } ] }, "database_specific": { "per_version": { "1:6.1.47-1+rpt4": { "linux_commit": "655fc658a15ae7a6f37103754adb39ba52a9a14e", "upstream_version": "6.1.47", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.1.96", "compiled_filter": false }, "1:6.1.54-1+rpt2": { "linux_commit": "2906f7abdc03d4a92b6b0e2e0c87ea2a9dffe8f7", "upstream_version": "6.1.54", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.1.96" }, "1:6.1.58-1+rpt2": { "linux_commit": "ccf1586ad0663fa91238ac56abf6340d6d740d18", "upstream_version": "6.1.58", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.1.96" }, "1:6.1.63-1+rpt1": { "linux_commit": null, "upstream_version": "6.1.63", "assessment": "upstream version (no usable Linux commit)", "upstream_fixed": "6.1.96" }, "1:6.1.73-1+rpt1": { "linux_commit": null, "upstream_version": "6.1.73", "assessment": "upstream version (no usable Linux commit)", "upstream_fixed": "6.1.96" }, "1:6.6.20-1+rpt1": { "linux_commit": "6f16847710cc0502450788b9f12f0a14d3429668", "upstream_version": "6.6.20", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.6.36" }, "1:6.6.28-1+rpt1": { "linux_commit": "0c341f47adc3578cd5f817aa20ee2b7f9ae6b23e", "upstream_version": "6.6.28", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.6.36" }, "1:6.6.31-1+rpt1": { "linux_commit": "c1432b4bae5b6582f4d32ba381459f33c34d1424", "upstream_version": "6.6.31", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.6.36" } } } } ], "references": [ { "type": "ADVISORY", "url": "https://www.cve.org/CVERecord?id=CVE-2024-40970" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/7c3bb96a20cd8db3b8824b2ff08b6cde4505c7e5" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/dd42570018f5962c10f215ad9c21274ed5d3541e" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/e151ae1ee065cf4b8ce4394ddb9d9c8df6370c66" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/9004784e8d68bcd1ac1376407ba296fa28f04dbe" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/333e11bf47fa8d477db90e2900b1ed3c9ae9b697" } ], "database_specific": { "source": "https://git.kernel.org/pub/scm/linux/security/vulns.git", "upstream_modified": "2026-08-05T11:52:36Z", "severity": { "source": "kernel CNA", "cvss_v3_score": 7.8, "cvss_v3_severity": "High", "scenario": "AV:L - The overrun is reached only by driving a local peripheral (audio/serial/SPI device node) whose driver queues multiple DMA descriptors on a dw-axi-dmac channel; no network- or peer-supplied data influences the descriptor accounting. Physical access is not required, so this is local.\nAC:L - The overrun is deterministic whenever two or more descriptors are outstanding on the same channel, a state the attacker arranges simply by queueing several buffers/transfers before stopping the stream. No race or unfavorable memory layout beyond the attacker's control is needed to trigger the panic.\nPR:L - A local unprivileged user with access to a device node backed by this DMA controller (e.g. /dev/snd/pcm*, tty, spidev on the affected RISC-V/ARC/Agilex5/Keem Bay platforms) can drive the prep/terminate cycle. No root or capability check guards the dmaengine client path.\nUI:N - The attacker performs the buffer queueing and stream teardown itself; no action by another user or administrator is required.\nS:U - The out-of-bounds access, the corrupted dma_pool free list, and any resulting DMA writes all occur within the kernel's own security authority. No VM, IOMMU, or sandbox boundary is crossed.\nC:H - The loop reads well past the end of the kmalloc-96 hw_desc array into adjacent slab objects, and the resulting free-list poisoning lets a later dma_pool_alloc() return an attacker-chosen address usable as a read primitive over arbitrary kernel memory. The leak is not bounded to a few bytes.\nI:H - pool_block_push() writes the dma address and next-block pointer at the out-of-bounds-derived vaddr with no validation in the non-DMAPOOL_DEBUG path, and links that address into the pool free list so the DMA engine subsequently writes hardware LLI data there. This yields an arbitrary kernel write suitable for control-flow hijacking.\nA:H - The commit explicitly documents a kernel panic from the hw_desc array overrun, and freeing a NULL/garbage vaddr into the dma pool oopses immediately. The counter underflow from atomic_sub() further corrupts channel state, so the crash is repeatable." } } }