CVE-2024-47678
KrytyczneCVSS 9.4Prawdopodobieństwo exploitacji (EPSS)
Niskie ryzykoPercentyl 15 - wyżej niż 15% wszystkich znanych CVE
Streszczenie
W jądrze Linuxa zmieniono kolejność ograniczania szybkości dla komunikatów ICMP. Wcześniej najpierw sprawdzano globalny limit, a potem limit per destination; teraz najpierw sprawdzany jest limit per destination, a globalny limit jest sprawdzany i zużywany później. Zmiana ma na celu zapobieganie atakom przez kanały boczne.
Ocena ryzyka
Ryzyko związane z tą podatnością to możliwość wykorzystania kanałów bocznych do uzyskania informacji o ruchu sieciowym. Poprawka eliminuje tę lukę, zmieniając kolejność limitów.
Rekomendacja
Zaleca się jak najszybsze zaktualizowanie jądra Linuxa do wersji zawierającej tę poprawkę, aby zabezpieczyć system przed potencjalnymi atakami przez kanały boczne.
Oryginalny opis (angielski, źródło NVD)
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.