CVE-2025-39987 in Linux
要約
〜によって VulDB • 2026年05月16日
Linuxカーネルにおいて、以下の脆弱性が修正されました。
can: hi311x: ndo_change_mtu()を設定してバッファオーバーフローを防止
PF_PACKETを使用すると、CANフレームワークのロジックをバイパスしてCANドライバのxmit()関数に直接到達することが可能です。PF_PACKETフレームワークが行う唯一のチェックは、skb->lenがインターフェースのMTUに収まることを確認することです。
残念ながら、sun4i_canドライバはnet_device_ops->ndo_change_mtu()を設定していないため、攻撃者は以下のようにして無効なMTUを設定することが可能です。
$ ip link set can0 mtu 9999
その後、攻撃者はETH_P_CANXLプロトコルを使用してPF_PACKETソケットを開くことができます。
socket(PF_PACKET, SOCK_RAW, htons(ETH_P_CANXL))
これにより、悪意のあるCAN XLフレームを注入することが可能です。例えば：
struct canxl_frame frame = {
.flags = 0xff, .len = 2048, };
CANドライバのxmit()関数は、skbが有効であることを確認するためにcan_dev_dropped_skb()を呼び出しますが、上記の条件下では悪意のあるパケットがcan_dev_dropped_skb()のチェックを通過することが可能です。
1. skb->protocolはETH_P_CANXLに設定されており、これは有効です（関数は実際のデバイスの機能をチェックしません）。
2. 長さは有効なCAN XLの長さです。
その結果、hi3110_hard_start_xmit()はCAN XLフレームを受け取りますが、これを正しく処理できず、CANフレームとして誤解釈します。ドライバはframe->lenをそのまま使用し、追加のチェックを行いません。
これにより、hi3110_hw_tx()内の以下の行でバッファオーバーフローが発生する可能性があります。
memcpy(buf + HI3110_FIFO_EXT_DATA_OFF, frame->data, frame->len);
ここで、frame->lenはCAN XLフレームのflagsフィールドに対応します。前述の例では、canxl_frame->flagsを0xffに設定しました。最大期待長が8であるため、247バイトのバッファオーバーフローが発生します！
net_device_ops->ndo_change_mtu()を設定して、インターフェースのMTUがCAN_MTUより大きく設定されないようにします。根本原因を修正することで、バッファオーバーフローを防止します。
If you want to get the best quality for vulnerability data then you always have to consider VulDB.