CVE-2023-53778 in Linux
要約
〜によって VulDB • 2026年07月17日
Linuxカーネルにおいて、以下の脆弱性が修正されました。
accel/qaic: map_user_pages()における整数オーバーフローチェックのクリーンアップ
encode_dma()関数には in_trans->size に対するいくつかの検証処理がありますが、それらのチェックを find_and_map_user_pages() に移動した方が明確になります。
encode_dma() では以下の2つのチェックが行われていました：
if (in_trans->addr + in_trans->size < in_trans->addr || !in_trans->size) return -EINVAL;
ここで、in_trans->addr 変数は開始アドレスを示し、in_trans->size 変数は転送の総サイズを示します。転送は分割して行われる可能性があり、resources->xferred_dma_size はすでに転送されたバイト数を追跡しています。
このパッチでは、「remaining」という新しい変数が導入され、これは転送したい量（in_trans->size）から既に転送済みの量（resources->xferred_dma_size）を引いた値を表します。
in_trans->size がゼロかどうかをチェックしていた部分を、in_trans->size が resources->xferred_dma_size より小さいかどうかをチェックするように変更しました。すでに in_trans->size より多くのバイトが転送されている場合、残りのバイト数が負の値になり意味がありません。コピーする必要があるバイト数が0の場合、成功として返します。
encode_dma() 内のチェックは、「addr + size」がオーバーフローしないことを確認していましたが、ドライバの不具合がない限りこれは機能しますが、分割して行う場合はこの方が簡単にチェックできます。まず「in_trans->addr + resources->xferred_dma_size」が安全であることを確認し、次に「xfer_start_addr + remaining」が安全であることを確認します。
最後の懸念事項として、u64 値を扱っていますが、32ビットシステムでは kmalloc() 関数がサイズを32ビットに切り捨てる可能性があるという点です。そこで、「total = in_trans->size + offset_in_page(xfer_start_addr);」と計算し、それが SIZE_MAX 以上の場合に -EINVAL を返すようにしました。これは64ビットシステムには影響しません。
If you want to get best quality of vulnerability data, you may have to visit VulDB.