Metrics
Affected Vendors & Products
Wed, 23 Oct 2024 18:15:00 +0000
Type | Values Removed | Values Added |
---|---|---|
First Time appeared |
Linux
Linux linux Kernel |
|
Weaknesses | CWE-203 | |
CPEs | cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* | |
Vendors & Products |
Linux
Linux linux Kernel |
|
Metrics |
cvssV3_1
|
cvssV3_1
|
Tue, 22 Oct 2024 01:30:00 +0000
Type | Values Removed | Values Added |
---|---|---|
References |
| |
Metrics |
threat_severity
|
cvssV3_1
|
Mon, 21 Oct 2024 13:15:00 +0000
Type | Values Removed | Values Added |
---|---|---|
Metrics |
ssvc
|
Mon, 21 Oct 2024 12:00:00 +0000
Type | Values Removed | Values Added |
---|---|---|
Description | 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. | |
Title | icmp: change the order of rate limits | |
References |
|
|
Status: PUBLISHED
Assigner: Linux
Published: 2024-10-21T11:53:21.814Z
Updated: 2024-12-19T09:25:44.135Z
Reserved: 2024-09-30T16:00:12.939Z
Link: CVE-2024-47678
Updated: 2024-10-21T13:07:45.359Z
Status : Analyzed
Published: 2024-10-21T12:15:04.837
Modified: 2024-10-23T17:58:08.720
Link: CVE-2024-47678