A flaw in the Linux Kernel found. When a router encounters an IPv6 packet too big to transmit to the next-hop, it returns an ICMP6 "Packet Too Big" (PTB) message to the sender. The sender caches this updated Maximum Transmission Unit (MTU) so it knows not to exceed this value when subsequently routing to the same host. In Linux kernels prior to 6.3, garbage collection is run on the IPv6 Destination Route Cache if the number of entries exceeds a threshold when adding the destination to the cache. This garbage collection examines every entry in the cache while holding a lock. In these affected kernel versions, a flood of the IPv6 ICMP6 PTB messages could cause high lock contention and increased CPU usage, leading to a Denial-of-Service. The fix backports the garbage collection improvements from Linux kernel 6.3 by bringing the IPv6 code closer to the IPv4 code, which does not have this issue. References: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?id=af6d10345ca76670c1b7c37799f0d5576ccef277 https://alas.aws.amazon.com/cve/html/CVE-2023-52340.html
Additional info: ICMP6 “Packet Too Big” packets force a DoS of the Linux kernel by forcing 100% CPU utilization. ICMP6 “Packet Too Big” Messages can force 100% CPU utilization in network IRQ threads within the Linux kernel on robust systems. When the ICMP6 Packet Too Big messages are received by a host, the Linux kernel will cache the destination information from the packet headers in the routing table to segment or fragment packets to a size that falls within the path MTU reported by the PTB. The Linux kernel garbage collection periodically runs to remove stale routes from the table to prevent the table from becoming oversized. During the handling of the ICMP6 Packet Too Big Messages, the routing table size can exceed the garbage collector threshold which is typically 1024. When the garbage collector threshold is exceeded, the Linux kernel will execute ip6_dst_gc(). In the event that the table exceeds the rt_max_size of 4096, the kernel will initiate the garbage collector function fib6_run_gc() with the force argument set to true. The fib6_run_gc() will obtain the spin lock, spin_lock_bh, and block the Linux kernel from writing additional details to the route table, regardless of the previous garbage collector iterations or if it is needed. In an effort to bypass the garbage collector block, the Linux kernel will raise an exception, rt6_insert_exception(), to continue to write to the route table but the function will obtain the global spin lock, spin_lock_bh(&rt6_exception_lock), which further blocks linux processes. The continue blocking behavior from the garbage collector and route table insert exception leads to a 100% CPU utilization since the queues are full during the execution of fib6_run_gc().
Created kernel tracking bugs for this issue: Affects: fedora-all [bug 2260726]
This was fixed for Fedora with the 6.3 stable kernel rebases.