Answer in brief
CVE-2024-47678 records a Unknown severity vulnerability in icmp: change the order of rate limits. The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
A CVSS score is not reported in the current record. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=4cdf507d54525842dfd9f6313fdafba039084046 <997ba8889611891f91e8ad83583466aeab6239a3 || >=4cdf507d54525842dfd9f6313fdafba039084046 <662ec52260cc07b9ae53ecd3925183c29d34288b || >=4cdf507d54525842dfd9f6313fdafba039084046 <a7722921adb046e3836eb84372241f32584bdb07 || >=4cdf507d54525842dfd9f6313fdafba039084046 <483397b4ba280813e4a9c161a0a85172ddb43d19 || >=4cdf507d54525842dfd9f6313fdafba039084046 <8c2bd38b95f75f3d2a08c93e35303e26d480d24e | 997ba8889611891f91e8ad83583466aeab6239a3, 662ec52260cc07b9ae53ecd3925183c29d34288b, a7722921adb046e3836eb84372241f32584bdb07, 483397b4ba280813e4a9c161a0a85172ddb43d19, 8c2bd38b95f75f3d2a08c93e35303e26d480d24e |
| Linux/Linuxgeneric | 3.18 | Not reported |
Published upstream
Oct 21, 2024
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Aug 5, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Aug 5, 2026
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.
Quoted source text, attributed separately from HOL analysis.
Answer in brief
CVE-2024-47678 records a Unknown severity vulnerability in icmp: change the order of rate limits. The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
A CVSS score is not reported in the current record. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=4cdf507d54525842dfd9f6313fdafba039084046 <997ba8889611891f91e8ad83583466aeab6239a3 || >=4cdf507d54525842dfd9f6313fdafba039084046 <662ec52260cc07b9ae53ecd3925183c29d34288b || >=4cdf507d54525842dfd9f6313fdafba039084046 <a7722921adb046e3836eb84372241f32584bdb07 || >=4cdf507d54525842dfd9f6313fdafba039084046 <483397b4ba280813e4a9c161a0a85172ddb43d19 || >=4cdf507d54525842dfd9f6313fdafba039084046 <8c2bd38b95f75f3d2a08c93e35303e26d480d24e | 997ba8889611891f91e8ad83583466aeab6239a3, 662ec52260cc07b9ae53ecd3925183c29d34288b, a7722921adb046e3836eb84372241f32584bdb07, 483397b4ba280813e4a9c161a0a85172ddb43d19, 8c2bd38b95f75f3d2a08c93e35303e26d480d24e |
| Linux/Linuxgeneric | 3.18 | Not reported |
Published upstream
Oct 21, 2024
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Aug 5, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Aug 5, 2026
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.
Quoted source text, attributed separately from HOL analysis.