CVE-2024-47678: icmp: change the order of rate limits
In the Linux kernel, the following vulnerability has been resolved:
icmp: change the order of rate limits
ICMP messages are ratelimited :
After the blamed commits, the two rate limiters are applied in this order:
1) host wide ratelimit (icmp_global_allow())
2) Per destination ratelimit (inetpeer based)
In order to avoid side-channels attacks, we need to apply
the per destination check first.
This patch makes the following change :
1) icmp_global_allow() checks if the host wide limit is reached.
But credits are not yet consumed. This is deferred to 3)
2) The per destination limit is checked/updated.
This might add a new node in inetpeer tree.
3) icmp_global_consume() consumes tokens if prior operations succeeded.
This means that host wide ratelimit is still effective
in keeping inetpeer tree small even under DDOS.
As a bonus, I removed icmp_global.lock as the fast path
can use a lock-free operation.
Security readout for executives and security teams
Plain-English summary
A Linux ICMP rate-limiting flaw could expose information through a network-observable side channel because system-wide and per-destination checks occurred in the wrong order. The supplied record assigns a critical 9.4 score, but it does not explain what information can be recovered or demonstrate broader compromise.
Executive priority
Treat this as an urgent kernel-maintenance issue because of its critical supplied score and network attack vector. Prioritize externally reachable and high-value Linux systems, while recognizing that the public technical evidence does not substantiate the CVSS-stated confidentiality and integrity impact in detail.
Technical view
Affected kernel logic called the host-wide ICMP limiter before the per-destination limiter. The correction checks the global allowance without consuming credit, applies the destination-specific check, then consumes global tokens only after success. This preserves denial-of-service protections while preventing the identified side channel.
Likely exposure
Exposure is limited to Linux kernels containing the affected ICMP rate-limiting implementation. Network-reachable systems processing attacker-controlled ICMP traffic merit attention. The supplied affected-version data is ambiguous, mixing releases, a zero value, and commit identifiers, so distribution-specific package verification is necessary.
Exploitation context
CVE-2024-47678 is not listed in KEV, and no supplied source establishes active exploitation, a public proof of concept, or weaponization. Its CVSS vector describes remote, unauthenticated, low-complexity access, but the technical narrative only substantiates a side channel and leaves practical impact details incomplete.
Researcher notes
Exact vulnerable ranges cannot be reliably reconstructed from the supplied version list. Validate ancestry against the stable commits and distributor backports. Research should focus on confirming the observable side channel, affected branch boundaries, and realistic security impact without assuming the CVSS consequences are demonstrated.
Mitigation direction
Prioritize vendor-supported kernel updates incorporating the applicable cited stable fix.
Use distribution advisories and package changelogs to identify the corrected kernel for each maintained branch.
Ensure systems boot the corrected kernel after installation.
If updating is delayed, request vendor-approved compensating controls; none are established in the supplied sources.
Validation and detection
Inventory running kernel releases across managed Linux hosts.
Compare package changelogs or source histories with the five cited stable fixes.
Confirm the running kernel, not merely an installed package, contains the applicable correction.
Review the Debian LTS notice for Debian systems and obtain equivalent guidance from other distributors.
Monitor KEV and vendor advisories for any change in exploitation status.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2024-47678 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.