CVE-2026-90111 in Linux
Summary
by MITRE • 09/17/2026
In the Linux kernel, the following vulnerability has been resolved:
ip6mr: do not clone dst in ip6mr_cache_report()
IPv6 input attaches a non-refcounted (NOREF) dst to skbs under RCU. When an ingress multicast packet misses MFC lookup, ip6mr_cache_unresolved() places the skb onto the unresolved queue, escaping the receive-side RCU grace period.
If the underlying route is deleted and freed, and the MFC queue is later resolved with a wrong parent interface, ip6_mr_forward() invokes ip6mr_cache_report(..., MRT6MSG_WRONGMIF), which executes dst_clone(skb_dst(pkt)) on the freed dst entry, triggering a slab use-after-free.
Report packets queued to mroute6_sk (a raw socket) and netlink notifications do not require an attached dst entry.
Fix this by: 1. Removing dst_clone() in ip6mr_cache_report() and ensuring report skbs do not hold a dst. 2. Dropping skb_dst before queuing unresolved skbs in ip6mr_cache_unresolved(), matching the fact that multicast forwarding resolves outgoing routes anew via ip6_route_output().
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/17/2026
The vulnerability identified within the Linux kernel's IPv6 multicast routing implementation, specifically affecting the ip6mr subsystem, represents a critical slab use-after-free condition. This flaw originates from improper handling of destination entry references during the processing of unresolved multicast packets. Under normal operation, when an ingress multicast packet arrives and fails to match an existing Multicast Forwarding Cache entry, the kernel places the socket buffer onto an unresolved queue via ip6mr_cache_unresolved(). During this process, a non-refcounted destination structure is attached to the socket buffer under Read-Copy-Update semantics. However, if the underlying route associated with that packet is deleted and subsequently freed by another part of the system before the unresolved queue is processed, the reference becomes dangling. When the MFC entry is eventually resolved or when a wrong parent interface triggers an error report via ip6_mr_forward(), the function ip6mr_cache_report() attempts to clone this destination structure using dst_clone(). Because the underlying memory has already been freed and potentially reallocated for other purposes, accessing it constitutes a use-after-free vulnerability. This scenario allows for potential kernel memory corruption or arbitrary code execution if an attacker can control the allocation of the freed slab cache entries.
From a technical perspective, the root cause lies in the mismatch between reference counting expectations and actual lifetime management of network destination structures. The ip6mr_cache_report() function is designed to send report packets to mroute6_sk, which is a raw socket used for multicast routing notifications, as well as generating netlink notifications. These notification mechanisms do not require an attached dst entry because they are informational messages rather than data forwarding operations that need route resolution at the time of transmission. The presence of dst_clone() in this context was unnecessary and dangerous when operating on skbs derived from unresolved queues where the original route might no longer exist. By removing the clone operation, the code ensures that report socket buffers do not hold references to potentially invalid destination structures. Furthermore, the fix addresses the upstream issue by dropping the skb_dst pointer before queuing unresolved sockets in ip6mr_cache_unresolved(). This aligns with the operational reality that multicast forwarding resolves outgoing routes anew via ip6_route_output() when processing the queue later, rendering any pre-attached dst entry obsolete and potentially hazardous.
The operational impact of this vulnerability is significant due to its potential for privilege escalation and system instability. A local attacker who can trigger specific multicast routing scenarios involving route deletion and subsequent resolution errors could exploit this use-after-free condition. Depending on kernel memory layout and timing, such an exploit might allow the attacker to read sensitive kernel memory, corrupt kernel data structures leading to a denial of service through a kernel panic, or potentially achieve arbitrary code execution with root privileges. The vulnerability is particularly insidious because it involves race conditions between route deletion events and multicast packet processing, making it difficult to trigger deterministically without precise control over network traffic patterns and routing table modifications. This aligns with CWE-416, Use After Free, where a program uses memory after it has been freed, leading to undefined behavior. In the context of attack frameworks like MITRE ATT&CK, this vulnerability could be leveraged in techniques related to Privilege Escalation or Defense Evasion by manipulating kernel state through crafted network packets and routing changes.
Mitigation strategies for this issue primarily involve applying the provided kernel patch that removes the unnecessary dst_clone() call from ip6mr_cache_report() and ensures proper cleanup of destination references before queuing unresolved skbs in ip6mr_cache_unresolved(). System administrators should ensure their Linux kernels are updated to versions containing these fixes. For environments where immediate patching is not feasible, network segmentation policies can help mitigate risk by restricting multicast traffic sources and monitoring for unusual routing table changes that might trigger the vulnerable code paths. Additionally, enabling kernel hardening features such as KASLR and stack protector mechanisms can increase the difficulty of exploiting this vulnerability successfully, although they do not eliminate the underlying memory safety flaw. Regular auditing of network configuration scripts to prevent rapid route deletion during active multicast sessions may also reduce the window of exposure.