CVE-2024-36894 in Linux
要約
〜によって VulDB • 2026年06月30日
Linuxカーネルにおいて、以下の脆弱性が修正されました：
usb: gadget: f_fs: aio_cancel()とAIOリクエスト完了処理の間の競合状態を修正する
FFSベースのアプリケーションは、UDCに送信された保留中のUSB要求を取り出すためにaio_cancel()コールバックを利用できます。ここで問題となるのは、UDCがソフトディスコネクト（soft disconnect）を処理している間に、FFSアプリケーションがAIOキャンセル呼び出しを発行するというシナリオです。DWC3ベースの実装では、以下のようなコールスタックになります：
DWC3 Gadget FFS Application dwc3_gadget_soft_disconnect() ... --> dwc3_stop_active_transfers() --> dwc3_gadget_giveback(-ESHUTDOWN) --> ffs_epfile_async_io_complete() ffs_aio_cancel() --> usb_ep_free_request() --> usb_ep_dequeue()
現在、AIO完了ハンドラとAIOキャンセルの間にはロック機構が実装されていないため、FFSアプリケーションからのAIOキャンセル呼び出しに対して、完了ルーチンが並列に実行されるとこの問題が発生します。完了呼び出しはUSB要求（io_data->req）を解放しますが、その一方でFFSアプリケーションもusb_ep_dequeue()の呼び出しのためにそれを参照しています。これにより、無効化されたポインタやハングしたポインタへのアクセスにつながる可能性があります。
コミット b566d38857fc ("usb: gadget: f_fs: use io_data->status consistently") は usb_ep_free_request() を ffs_epfile_async_io_complete() 内に移動しましたが、この問題を適切にロックによって緩和するためには、spinlockをffs_epfile_async_io_complete() に追加することはできません。なぜなら、usb_ep_dequeue()（USB要求の取り出しが成功した場合）は同じコンテキスト内で関数ドライバーの完了ハンドラを呼び出すためです。これによりデッドロックが発生します。
この問題を修正するため、usb_ep_free_request() を ffs_user_copy_worker() へ戻し、ffs->eps_lock内での解放後に io_data->req が明示的にNULLに設定されるようにしました。これにより上記の競合状態が解消されます。つまり、すでに解放された要求に対して ffs_aio_cancel() ルーチンが取出しを試み続けることや、AIOキャンセルによる参照が終わるまで ffs_user_copy_work() によってUSB要求が解放されないことが防止されます。
この修正は以下のコミットに依存しています： commit b566d38857fc ("usb: gadget: f_fs: use io_data->status consistently")
If you want to get best quality of vulnerability data, you may have to visit VulDB.