CVE-2024-47678

What it actually does

Incorrect ordering of ICMP rate limit checks (global before per-destination) allows side-channel attacks that leak information about host-wide rate limiter state via timing or response behavior.

Why it matters to the business

Attackers can silently gather reconnaissance data on network infrastructure under load, increasing risk of targeted follow-on attacks; low EPSS and no KEV listing reduce immediate urgency but the change affects all Linux distributions using the affected kernel code.

How an attack unfolds

An attacker sends sequences of ICMP messages, observes whether the global limit check consumes tokens before the per-destination check, and uses timing or acceptance differences to infer internal inetpeer tree state or rate-limiter credits without triggering obvious alerts.

How to fix it

Apply the kernel patch that reorders checks so the per-destination inetpeer limit is evaluated first, credits are consumed only on success, and the global lock is removed from the fast path; for the listed activesupport packages upgrade to one of the fixed versions 5.2.4.3 or 6.0.3.1.

How to confirm the fix worked

Confirm the running kernel contains the reordered icmp_global_allow / inetpeer check logic and that icmp_global.lock is no longer used in the fast path; test by sending ICMP bursts and verifying per-destination limits are enforced before global token consumption.

Typical attack path

1. Craft and send ICMP echo or other messages at varying rates to a target host
2. Measure response timing or drop behavior to distinguish global versus destination-specific limits
3. Correlate observations to map rate-limiter state and infer traffic patterns or presence of other flows
4. Leverage obtained side-channel data to refine subsequent reconnaissance or evasion techniques

How to detect it

Search kernel logs and network flow records for unusual volumes of ICMP messages from single sources that produce timing variations consistent with rate-limiter state probing; monitor for new inetpeer tree growth under controlled load tests.

What your security team should do

• Prioritize kernel updates on all externally reachable Linux systems within normal change windows given the side-channel nature
• Review network monitoring for anomalous ICMP patterns that could indicate probing of rate-limiter behavior
• Ensure downstream package managers reflect the activesupport 5.2.4.3 or 6.0.3.1 fixes where Ruby components interact with kernel networking