CVE-2024-42145

What it actually does

Unbounded growth of the receive list for MAD packets in ib_umad allows memory consumption to increase without limit when incoming packet rate exceeds user-space extraction rate.

Why it matters to the business

Linux systems handling InfiniBand traffic may experience memory exhaustion or degraded performance under sustained high-volume MAD packet traffic, affecting availability of dependent services.

How an attack unfolds

An attacker generates a high rate of MAD packets toward a vulnerable kernel; when user-space processing lags, the receive list grows without bound until memory pressure causes system impact or packet drops.

How to fix it

Upgrade the Linux kernel to a version containing commit 1288cf1cceb0e6df276e182f5412370fb4169bcb or later; apply vendor backports if using distribution kernels.

How to confirm the fix worked

Confirm kernel source contains the 200k list-size limit in ib_umad; test by replaying high-rate MAD traffic and verifying drops occur only after the limit rather than unbounded growth.

Typical attack path

1. Identify InfiniBand-enabled Linux targets
2. Send MAD packets at rates exceeding typical user-space handling (e.g., >100k/s)
3. Sustain traffic for longer than the 1-second retry window to trigger list growth
4. Monitor for memory exhaustion or service degradation on target

How to detect it

Review kernel logs for ib_umad list-related warnings or drops; correlate with InfiniBand interface traffic spikes and memory usage metrics on systems running older kernels.

What your security team should do

• Prioritize kernel upgrades on any systems exposing InfiniBand interfaces
• Monitor EPSS and KEV status for changes given the 805-day publication age and stable low EPSS
• Review InfiniBand configurations and limit exposure where possible