製品・ソフトウェアに関する情報
Vulnerability Search
LinuxのLinux Kernelにおける不特定の脆弱性
Title LinuxのLinux Kernelにおける不特定の脆弱性
Summary

Linuxカーネルにおいて、以下の脆弱性が修正されました。mctp: route: mctp_flow_prepare_output()内でkey-lockを保持していない問題です。mctp_flow_prepare_output()はkey-devをチェックし、場合によってはmctp_dev_set_key()を呼び出しますが、その処理中にkey-lockを保持していません。mctp_dev_set_key()およびmctp_dev_release_key()は__must_hold(&key-lock)で注釈されており、key-devへのアクセスはkey-lockによって直列化されることが意図されています。mctp_sendmsg()の送信パスはmctp_local_output() - mctp_dst_output()を経由してmctp_flow_prepare_output()に達しますが、この間にkey-lockを保持していないため、チェックと設定のシーケンスにレースコンディションがあります。例として、以下のインターリーブが考えられます。CPU0 CPU1 ---- ---- mctp_flow_prepare_output(key, devA) if (!key-dev) // NULLと認識 mctp_flow_prepare_output( key, devB) if (!key-dev) // まだNULL mctp_dev_set_key(devB, key) mctp_dev_hold(devB) key-dev = devB mctp_dev_set_key(devA, key) mctp_dev_hold(devA) key-dev = devA // devBを上書きになります。これによりdevAとdevBの参照が両方取得されますが、最終的なkey-devの値だけが解放のために追跡されます。これによって、1つの参照が失われ、mctp_dev_release_key()が1つのdevの参照しか減らさないため、リソースリークが発生する可能性があります。解決策として、key-devのチェックおよびmctp_dev_set_key()の呼び出しの前後でkey-lockを保持するようにしました。

Possible impacts 当該ソフトウェアが扱う情報について、外部への漏えいは発生しません。 また、当該ソフトウェアが扱う情報について、書き換えは発生しません。 さらに、当該ソフトウェアが完全に停止する可能性があります。 そして、この脆弱性を悪用した攻撃の影響は、他のソフトウェアには及びません。 
Solution

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

Publication Date May 8, 2026, midnight
Registration Date May 22, 2026, 10:53 a.m.
Last Update May 22, 2026, 10:53 a.m.
CVSS3.0 : 警告
Score 5.5
Vector CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Affected System
Linux
Linux Kernel 5.16 以上 6.1.167 未満
Linux Kernel 6.13 以上 6.18.19 未満
Linux Kernel 6.19 以上 6.19.9 未満
Linux Kernel 6.2 以上 6.6.130 未満
Linux Kernel 6.7 以上 6.12.78 未満
Linux Kernel 7.0
CVE (情報セキュリティ 共通脆弱性識別子)
CWE (共通脆弱性タイプ一覧)
その他
Change Log
No Changed Details Date of change
1 [2026年05月22日]
  掲載		 May 22, 2026, 10:53 a.m.
NVD Vulnerability Information
CVE-2026-43455
Summary

In the Linux kernel, the following vulnerability has been resolved:

mctp: route: hold key->lock in mctp_flow_prepare_output()

mctp_flow_prepare_output() checks key->dev and may call
mctp_dev_set_key(), but it does not hold key->lock while doing so.

mctp_dev_set_key() and mctp_dev_release_key() are annotated with
__must_hold(&key->lock), so key->dev access is intended to be
serialized by key->lock. The mctp_sendmsg() transmit path reaches
mctp_flow_prepare_output() via mctp_local_output() -> mctp_dst_output()
without holding key->lock, so the check-and-set sequence is racy.

Example interleaving:

CPU0 CPU1
---- ----
mctp_flow_prepare_output(key, devA)
if (!key->dev) // sees NULL
mctp_flow_prepare_output(
key, devB)
if (!key->dev) // still NULL
mctp_dev_set_key(devB, key)
mctp_dev_hold(devB)
key->dev = devB
mctp_dev_set_key(devA, key)
mctp_dev_hold(devA)
key->dev = devA // overwrites devB

Now both devA and devB references were acquired, but only the final
key->dev value is tracked for release. One reference can be lost,
causing a resource leak as mctp_dev_release_key() would only decrease
the reference on one dev.

Fix by taking key->lock around the key->dev check and
mctp_dev_set_key() call.

Publication Date May 9, 2026, 12:16 a.m.
Registration Date May 9, 2026, 4:15 a.m.
Last Update May 12, 2026, 11:10 p.m.
Related information, measures and tools
Common Vulnerabilities List