CVE-2024-49997

What it actually does

The lantiq_etop Ethernet driver fails to zero the buffer when applying software padding to frames on Amazon-SE and Danube MACs, resulting in uninitialized kernel memory being placed on the wire.

Why it matters to the business

Sensitive kernel memory contents may leak over the network on affected systems, creating a risk of confidential data exposure in environments that rely on this driver.

How an attack unfolds

An attacker sends or triggers Ethernet frames requiring padding on vulnerable hardware; the driver expands the buffer without zeroing, and the attacker captures the resulting frames on the wire to read kernel memory contents.

How to fix it

Upgrade the Linux kernel to commit 905f06a34f960676e7dc77bea00f2f8fe18177ad or later; the patch replaces manual padding with skb_put_padto() which zeroes the expanded buffer and silently drops un-paddable packets.

How to confirm the fix worked

Confirm the driver source calls skb_put_padto() and that frames requiring padding are zero-filled before transmission; test by forcing padding conditions and inspecting resulting wire data.

Typical attack path

1. Identify hosts running the lantiq_etop driver on Amazon-SE or Danube hardware
2. Trigger transmission of frames that require software padding
3. Capture network traffic and inspect padded portions for uninitialized data

How to detect it

Review network packet captures for padded Ethernet frames containing unexpected non-zero or patterned data; examine driver logs for silent packet drops related to padding failures.

What your security team should do

• Apply the referenced kernel commit or distribution update as soon as possible
• Audit systems for use of the lantiq_etop driver and restrict network exposure where feasible
• Monitor upstream stable branches for backported fixes