Linuxカーネルにおいて、以下の脆弱性が修正されました。cnicのcnic_delete_taskにおけるuse-after-freeバグを修正しました。元のコードでは、cnic_cm_stop_bnx2x_hw()内でcancel_delayed_work()が使用されており、遅延ワークアイテムである'delete_task'がすでに実行中の場合、その完了が保証されていませんでした。さらに、その遅延ワークアイテムは周期的であり、cnic_cm_stop_bnx2x_hw()内のflush_workqueue()は呼び出し前にキューに入れられたワークアイテムのみを待機します。flush_workqueue()呼び出し後にキューに追加されたワークアイテムは待機対象に含まれません。つまり、周期的なワークアイテムの実行が終了した後でも、workqueueに遅延ワークアイテムが存在する可能性があります。これにより、cnic_free_dev()によってcnic_devが解放された後でもdelete_taskがアクティブなままでcnic_delete_task()内でcnic_devを参照しようとしてuse-after-freeの状況が発生します。典型的な競合状態は以下の通りです。CPU0（クリーンアップ）ではcnic_netdev_event() - cnic_stop_hw() - cnic_cm_stop_bnx2x_hw() - cancel_delayed_work() - flush_workqueue() - cnic_free_dev(dev)が実行され、cnic_devが解放されます。一方、CPU1（遅延ワークコールバック）ではcnic_delete_task()がflush_workqueue()の後にqueue_delayed_work()を実行し、新しいdelete_taskインスタンスがdevを使用します。cancel_delayed_work()をcancel_delayed_work_sync()に置き換えることで、周期的な遅延ワークアイテムが適切にキャンセルされ、ワークアイテムの実行が完了するまで待機した後にcnic_devが解放されるようになりました。さらにcancel_delayed_work_sync()は__flush_work(work, true)を使用して現在実行中のワークアイテムの完了を同期的に待つため、flush_workqueue()は冗長となり削除されるべきです。このバグは静的解析により特定されました。再現および修正検証のために、QEMU上でcnic PCIデバイスをシミュレートし、cnic_delete_task()内にssleep()を挿入するなど意図的な遅延を加えてバグ発生の可能性を高めました。

リリース情報、またはパッチ情報が公開されています。参考情報を参照して適切な対策を実施してください。