CVE-2024-35889

What it actually does

Missing call to eth_type_trans for unknown packet types in idpf_rx_process_skb_fields leaves skb protocol unset, causing kernel panic when tcpdump processes the skb.

Why it matters to the business

Linux systems using the idpf driver can experience unexpected crashes when receiving rare packet types during traffic inspection, leading to service disruption and potential data loss on affected hosts.

How an attack unfolds

An attacker sends a network packet whose type is unknown to the idpf driver; if tcpdump or similar packet capture is active, the unset protocol field triggers a kernel panic on receive processing.

How to fix it

Apply the upstream fix in commit b4d28f7fa4dd531cf503a4fe1ca7008960cc5832 or later stable kernel versions that ensure eth_type_trans is called for every received packet.

How to confirm the fix worked

Confirm the driver source contains the eth_type_trans call for all packet paths; test by injecting unknown packet types while running tcpdump and verify no panic occurs.

Typical attack path

1. Send crafted or unusual network packet to target interface
2. Ensure tcpdump or equivalent skb consumer is running on the receiving host
3. Trigger idpf_rx_process_skb_fields path for unknown packet type
4. Observe kernel panic due to missing eth_type_trans call

How to detect it

Review kernel logs for oops/panic entries mentioning idpf_rx_process_skb_fields or eth_type_trans; correlate with tcpdump activity and unknown ethertype values in captured traffic.

What your security team should do

• Prioritize kernel update on systems using idpf driver
• Monitor for kernel oops or panic logs related to idpf receive path
• Disable unnecessary packet capture in production until patched