In the Linux kernel, the following vulnerability has been resolved:
bnxt_en: Bound SW TPA IDs to prevent crashes
FW supports up to 1024 concurrent TPAs, so the FW TPA ID is in the range
0..1023 (see commit ec4d8e7cf024 ("bnxt_en: Add TPA ID mapping logic for
57500 chips.")). bnxt_alloc_agg_idx is intended to wrap the FW ID down to a
software ID which is used to index rxr->rx_tpa, and to generate a mapping
between FW IDs and the wrapped software ID.
On a 57608 with firmware version 233, the firmware advertises 32
concurrent TPAs. As of the commit under fixes, bp->max_tpa on this NIC
is set to 32.
If the software ID from bnxt_alloc_agg_idx is above 31, this results in
an invalid address being loaded on this line:
tpa_info = &rxr->rx_tpa[agg_id];
because rx_tpa is allocated with only bp->max_tpa (32) entries. Writes
to tpa_info later in the code are out of bounds.
This bug results in a crash at boot:
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
This stack trace is from a crash triggered when an out of bounds rx_tpa
is dereferenced. The invalid write mentioned above is silent in this
particular crash.
Fix this by allocating rx_tpa with bp->max_tpa rounded up to the next
power of 2 (bp->max_tpa_roundup_size) entries and masking the FW TPA ID
with that size, so the wrapped ID can never index past the end of the
array.
CVSS Vector: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H
CVSS Score: 8.1
AV:N - bnxt_tpa_start() runs from bnxt_rx_pkt()/__bnxt_poll_work() in NAPI when the NIC opens a TPA aggregation for received TCP segments, so a remote sender of TCP traffic drives the out-of-bounds rx_tpa[agg_id] access with no local access needed.
AC:H - It needs a P7 NIC (e.g. 57608) whose firmware advertises max_aggs_supported <= 32 so max_tpa stays small. The firmware, not the attacker, picks TPA_START_AGG_ID_P5; a masked ID of 32-255 then overruns rx_tpa. The attacker controls neither the hardware/firmware nor the ID choice.
PR:N - The path runs in the RX softirq on arriving TCP segments before any socket or authentication processing, so the sender needs no credentials.
UI:N - No victim action is needed; normal packet reception on the bnxt interface with hardware GRO/TPA enabled reaches bnxt_tpa_start().
S:U - The corruption is in kernel heap memory next to the kzalloc'ed rx_tpa array in the same kernel authority; no guest/host or IOMMU boundary is shown to be crossed.
C:H - bnxt_tpa_start() reads data/data_ptr/mapping from an out-of-bounds bnxt_tpa_info and posts that mapping to the RX descriptor (rx_bd_haddr), so stale heap contents get handed to the NIC and later to skb construction, exposing out-of-bounds kernel memory.
I:H - It writes buffer pointers, the DMA mapping, and packet-derived len/rss_hash/flags2/hdr_info past the end of rx_tpa, and has the NIC DMA received packet bytes to a stale mapping read from out-of-bounds memory; this is heap memory corruption.
A:H - The commit's reproduction shows a general protection fault oops in bnxt_rx_pkt in IRQ context during boot under normal RX traffic, which takes the machine down.
| Attack Vector |
Network |
Scope |
Unchanged |
| Attack Complexity |
High |
Confidentiality Impact |
High |
| Privileges Required |
None |
Integrity Impact |
High |
| User Interaction |
None |
Availability Impact |
High |
AV:N - bnxt_tpa_start() runs from bnxt_rx_pkt()/__bnxt_poll_work() in NAPI when the NIC opens a TPA aggregation for received TCP segments, so a remote sender of TCP traffic drives the out-of-bounds rx_tpa[agg_id] access with no local access needed.
AC:H - It needs a P7 NIC (e.g. 57608) whose firmware advertises max_aggs_supported <= 32 so max_tpa stays small. The firmware, not the attacker, picks TPA_START_AGG_ID_P5; a masked ID of 32-255 then overruns rx_tpa. The attacker controls neither the hardware/firmware nor the ID choice.
PR:N - The path runs in the RX softirq on arriving TCP segments before any socket or authentication processing, so the sender needs no credentials.
UI:N - No victim action is needed; normal packet reception on the bnxt interface with hardware GRO/TPA enabled reaches bnxt_tpa_start().
S:U - The corruption is in kernel heap memory next to the kzalloc'ed rx_tpa array in the same kernel authority; no guest/host or IOMMU boundary is shown to be crossed.
C:H - bnxt_tpa_start() reads data/data_ptr/mapping from an out-of-bounds bnxt_tpa_info and posts that mapping to the RX descriptor (rx_bd_haddr), so stale heap contents get handed to the NIC and later to skb construction, exposing out-of-bounds kernel memory.
I:H - It writes buffer pointers, the DMA mapping, and packet-derived len/rss_hash/flags2/hdr_info past the end of rx_tpa, and has the NIC DMA received packet bytes to a stale mapping read from out-of-bounds memory; this is heap memory corruption.
A:H - The commit's reproduction shows a general protection fault oops in bnxt_rx_pkt in IRQ context during boot under normal RX traffic, which takes the machine down.
CVSS 3.1