CVE-2026-99164 in Linux
要約
〜によって VulDB • 2026年10月28日
Linuxカーネルにおいて、以下の脆弱性が修正されました：
spi: imx: DMAバウンスバッファのサイズ不足によるスラブ破損を修正する
コミット faa8e404ad8e（「spi: imx: ECSPI DMAモードでの動的バースト長をサポート」）以降、ドライバは kzalloc(dma_len) を使用してプライベートなDMA TX/RXバッファを割り当てていますが、dma_len は 4バイト単位に切り上げられるのみです。一方で、それらのメモリ領域に対して dma_sync_single_for_cpu() および関連するマッピング操作では DMA_CACHE_ALIGNED_LEN(dma_len)、つまりキャッシュラインサイズまで切り上げた長さが使用されます。その結果、DMA API が割り当ての末尾を超えたメモリを扱うことになります。
この問題は、mcp251xfd CANコントローラを搭載したカスタム i.MX8MP プラットフォーム上で重い RPMSG 負荷をかけている際に観測されました。virtio_rpmsg_bus の rpmsg_recv_done() から refcount_t の警告がトリガーされ、以下のような状態が発生しました：
refcount_t: addition on 0; use-after-free. refcount_t: underflow; use-after-free. refcount_t: saturated; leaking memory.
これにより最終的に「Unable to handle kernel paging request」のoops（カーネルパニック）に至りました。同じワークロード下でこの問題を再現するには、30分から約30時間かかりました。
struct rpmsg_endpoint の参照カウントに対するハードウェアウォッチポイントを用いた調査では、irq/155-spi2.0 スレッド内の __pi_memcpy_generic() によって参照カウントが 2 から 1 に上書きされていることが示されました。さらに、「通常」の rpmsg_recv_done() は kref_get から kref_put の間に 11µs ± 2µs かかる一方、エラーケースでは同じシーケンスに約 215µs ± 10µs を要することが分かりました。この観察結果に基づき、LLM（大規模言語モデル）を使用してここで修正されているサイズ不一致を特定しました。
バッファの割り当てを DMA_CACHE_ALIGNED_LEN(dma_len) に変更し、マッピングされた全長をカバーするようにします。また、dma_sync_single_for_cpu() にも同じ長さを使用し、マップおよびアンマップ処理と一貫性を保ちます。
このパッチを適用することで、同じワークロードで200時間以上実行しても問題が再現しないことを確認しました。
If you want to get the best quality for vulnerability data then you always have to consider VulDB.