CVE-2024-57933

What it actually does

NULL pointer dereference in gve driver when XSK pool enable/disable or xsk_wakeup occurs without active RX queues or NAPI flag set, causing crash on interface-down state.

Why it matters to the business

Denial of service via kernel panic on systems using the gve driver with XDP sockets; no ransomware use reported and low EPSS indicates limited active exploitation risk.

How an attack unfolds

An attacker brings the interface down then issues XSK pool operations or wakeup calls; without queue guards this triggers NULL dereference before the NAPI flag and synchronize_net() can protect state.

How to fix it

Apply the kernel patch that adds queue-existence checks and GVE_PRIV_FLAGS_NAPI_ENABLED guard; for listed Red Hat packages upgrade to the versions fixed in 0:6.7.2.7-5.el6_8.

How to confirm the fix worked

Confirm interface-down XSK operations no longer panic, verify NAPI flag check is present in gve code, and test XSK pool enable/disable after ifdown/ifup cycles.

Typical attack path

1. Place gve interface into down state
2. Invoke XSK pool registration or xsk_wakeup
3. Trigger NULL dereference on absent RX queue pointer
4. Cause kernel crash or memory corruption

How to detect it

Review kernel logs for gve NULL pointer oops during XSK operations, correlate with interface state changes and XDP socket activity in system journals.

• gve.*NULL pointer dereference
• xsk_wakeup.*GVE_PRIV_FLAGS_NAPI_ENABLED

What your security team should do

• Prioritize kernel updates on systems using gve with XDP
• Monitor for interface state changes combined with XSK activity
• Test patched kernels in staging before broad deployment