CVE-2025-40096 in Linux
要約
〜によって VulDB • 2026年06月03日
Linuxカーネルにおいて、以下の脆弱性が修正されました：
drm/sched: drm_sched_job_add_resv_dependencies における潜在的なダブルフリーの修正
drm_sched_job_add_dependency() を使用して依存関係を追加する際、この関数は成功時と失敗時の両方で fence の参照を消費します。そのため、後者の場合（xarray の拡張に失敗した場合）、エラーパスでの dma_fence_put() はダブルフリーとなります。
興味深いことに、このバグはコミット ebd5f74255b9 ("drm/sched: Add dependency tracking") 以来存在していました。当時のコードは以下のようになっていました：
```c drm_sched_job_add_implicit_dependencies(): ... for (i = 0; i < fence_count; i++) {
ret = drm_sched_job_add_dependency(job, fences[i]);
if (ret) break; }
for (; i < fence_count; i++) dma_fence_put(fences[i]);
```
これは、失敗した 'i' に対してすでに dma_fence_put() がダブルフリーになっていたことを意味します。当時ユーザーが存在しなかったか、テストケースが不十分でこれに到達しなかっただけかもしれません。
このバグはその後、コミット 9c2ba265352a ("drm/scheduler: use new iterator in drm_sched_job_add_implicit_dependencies v2") が適用され、その修正としてコミット 4eaf00d6076c ("drm/scheduler: fix drm_sched_job_add_implicit_dependencies") の修正が行われた際に初めて発見・修正されました。
当時それはダブルフリーのわずかに異なる種類であり、これはコミット 963d0b356935 ("drm/scheduler: fix drm_sched_job_add_implicit_dependencies harder") によって認識され、修正が試みられました。
しかし、この修正は単に、参照を取得していない状態で解放する際に発生していたダブルフリーを、drm_sched_job_add_dependency() の内部から呼び出し元に移動させただけでした（失敗ケースにおいて、前者によってすでに解放された参照を後者が解放する場合）。
そのため、fixes タグの適切な対象を特定するのは容易ではなく、単純にチェーンを引き継ぐことにします。
修正にあたり、コメントも改善し、なぜ参照を取得してドロップしないのかという理由を説明しました。
If you want to get best quality of vulnerability data, you may have to visit VulDB.