CVE-2024-50274

What it actually does

Use-after-free in idpf_get_link_ksettings when a reset releases the vport lock and pointer; monitoring tools then dereference the freed vport, causing kernel memory corruption or crashes.

Why it matters to the business

Unexpected system crashes, potential kernel-level compromise, and service disruption on Linux hosts using the idpf network driver, especially during control-plane resets.

How an attack unfolds

An attacker or automated monitoring process issues a link-settings query while the driver is recovering from a reset triggered by control-plane removal or reboot; the query hits the error path that has already freed the vport, resulting in a use-after-free.

How to fix it

Upgrade the Linux kernel to a version containing the fix that relocates link_speed_mbps into netdev_priv and uses netif_carrier_ok for link status; apply all available distribution kernel updates.

How to confirm the fix worked

Confirm the running kernel contains the commit that moves link_speed_mbps out of vport and replaces vport-based link checks; verify no vport dereference remains in idpf_get_link_ksettings.

Typical attack path

1. Cause or wait for idpf driver reset (control-plane removal or platform reboot)
2. Driver enters error path and releases vport lock and pointer
3. Trigger link-settings query via ethtool or monitoring tools
4. Kernel dereferences released vport pointer, triggering UAF

How to detect it

Search kernel logs and crash dumps for oops/panic entries referencing idpf_get_link_ksettings, vport pointer dereference after release, or use-after-free in the idpf driver during reset handling.

• idpf_get_link_ksettings
• vport pointer access after release
• kernel trace with Use After Free in idpf

What your security team should do

• Prioritize kernel updates on all systems exposing idpf interfaces
• Monitor kernel logs for idpf reset and UAF traces
• Temporarily restrict ethtool or monitoring access during known reset windows if patches cannot be applied immediately