Linux/Unix ホストには、ベンダーが提供するパッチが利用できない脆弱性の影響を受ける複数のパッケージがインストールされています。

  - can: hi311xndo_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 ソケット
    socketPF_PACKET、SOCK_RAW、htonsETH_P_CANXLがあり、悪意のある CAN XL フレームを注入します。例: struct canxl_frame frame = { .flags = 0xff, .len = 2048, }; CAN ドライバーの xmit() 関数は、can_dev_dropped_skb() を呼び出して、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 フレームのフラグフィールドに相当します。前の例では、canxl_frame->flags を 0xff に設定していました。想定される最大長は 8 であるため、247 バイトのバッファオーバーフローが発生しますnet_device_ops->ndo_change_mtu() を実装し、インターフェイスの MTU が CAN_MTU より大きいものに設定されないようにします。根本原因を修正することで、バッファオーバーフローを防ぎます。CVE-2025-39987

Nessus は、ベンダーによって報告されたパッケージの存在に依存していることに注意してください。

検出

Linux Distros のパッチ未適用の脆弱性: CVE-2025-39987

high Nessus プラグイン ID 271542

バージョン 1.22