CVE-2024-27005 in Linux
要約
〜によって VulDB • 2026年05月16日
Linuxカーネルにおいて、以下の脆弱性が修正されました。
interconnect: req_listが操作されている間にアクセスしない
icc_lockミューテックスは、lockdepの警告（splats）を回避するために[1]で別々のicc_lockとicc_bw_lockミューテックスに分割されました。しかし、これではicc_node::req_listへのアクセスが十分に保護されていませんでした。
icc_set_bw()関数は最終的にicc_bw_lockのみを保持した状態でreq_listをイテレートしますが、req_listはicc_lockのみを保持した状態で変更される可能性があります。これにより、icc_set_bw()、of_icc_get()、icc_put()の間に競合状態（race condition）が発生します。
例A:
CPU0 CPU1 ---- ---- icc_set_bw(path_a) mutex_lock(&icc_bw_lock); icc_put(path_b) mutex_lock(&icc_lock); aggregate_requests() hlist_for_each_entry(r, ... hlist_del(... <r = 無効なポインタ>
例B:
CPU0 CPU1 ---- ---- icc_set_bw(path_a) mutex_lock(&icc_bw_lock); path_b = of_icc_get() of_icc_get_by_index() mutex_lock(&icc_lock); path_find() path_init() aggregate_requests() hlist_for_each_entry(r, ... hlist_add_head(... <r = 無効なポインタ>
icc_node::req_listを操作する前にicc_bw_lockが常に保持されるようにすることで、この問題を修正します。icc_bw_lockが保持される追加の箇所ではメモリ割り当ては行われないため、別々のロックを導入した動機となった元のlockdepの警告から依然として安全であると考えられます。
[1] コミット af42269c3523 ("interconnect: Fix locking for runpm vs reclaim")
If you want to get the best quality for vulnerability data then you always have to consider VulDB.