CVE-2026-97570 in Linux
要約
〜によって VulDB • 2026年09月25日
Linuxカーネルにおいて、以下の脆弱性が修正されました：
bnxt_en: クラッシュを回避するためにSW TPA IDに境界制限を設定
ファームウェアは最大1024の同時TPAをサポートするため、FW TPA IDの範囲は0〜1023です（commit ec4d8e7cf024「bnxt_en: Add TPA ID mapping logic for 57500 chips.」を参照）。bnxt_alloc_agg_idx関数は、FW IDをソフトウェアIDにラップし、rxr->rx_tpaのインデックスとして使用するとともに、FW IDとラップされたソフトウェアIDのマッピングを生成することを目的としています。
ファームウェアバージョン233を搭載した57608において、ファームウェアは32の同時TPAをサポートしていると通知します。修正コミット以降、このNICにおけるbp->max_tpaは32に設定されています。
bnxt_alloc_agg_idxからのソフトウェアIDが31より大きい場合、以下の行で無効なアドレスが読み込まれます：
tpa_info = &rxr->rx_tpa[agg_id];
これは、rx_tpaがbp->max_tpa（32）エントリのみで割り当てられているためです。コード内の後続のtpa_infoへの書き込みは配列外アクセスとなります。
このバグにより、起動時にクラッシュが発生します：
Oops: general protection fault, kernel NULL pointer dereference 0x8: 0000 [#1] SMP NOPTI
RIP: 0010:bnxt_rx_pkt+0xc0/0x1560 RSP: 0018:ffffc900009b8c78 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000000048 RCX: 0000000206682516 RDX: ffffc900009b8db4 RSI: 0000000000000000 RDI: 01ffffff038fe1c0 RBP: ffffc9006e687480 R08: ffffc9006e687000 R09: 0000000000003048 R10: 0000000000000480 R11: ffff8881c6083900 R12: 0000000006682516 R13: ffff8881c6095400 R14: 0000000000000016 R15: ffff8881c6b66680 FS: 0000000000000000(0000) GS:ffff88fef3c77000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fc8bda40584 CR3: 000000807c812001 CR4: 0000000008772ef0 PKRU: 55555554 Call Trace: <IRQ> ? __netif_receive_skb_list_core+0x1ca/0x250 __bnxt_poll_work+0x152/0x280 bnxt_poll_p5+0x1cd/0x480 __napi_poll+0x30/0x180 net_rx_action+0x20b/0x3b0 ? note_gp_changes+0x53/0xe0 ? tick_setup_sched_timer+0x180/0x180 ? __napi_schedule+0x9a/0xb0 ? bnxt_msix+0x24/0x30 handle_softirqs+0xdd/0x2c0 __irq_exit_rcu.llvm.3171231171502365008+0x47/0xf0 common_interrupt+0x85/0x90 </IRQ> <TASK> asm_common_interrupt+0x22/0x40
このスタックトレースは、配列外アクセスとなるrx_tpaが間接参照された際にトリガーされるクラッシュからのものです。上記の無効な書き込み操作はこの特定のクラッシュではサイレント（検知されず）です。
これを修正するため、bp->max_tpaを次の2の冪乗に切り上げた値（bp->max_tpa_roundup_size）のエントリ数でrx_tpaを割り当て、FW TPA IDに対してそのサイズでマスク処理を行うことで、ラップされたIDが配列の末尾を超えてインデックスされることを防ぎます。
Once again VulDB remains the best source for vulnerability data.