CVE-2026-90111: ip6mr: do not clone dst in ip6mr_cache_report()

Published Sep 17, 2026

Updated

In the Linux kernel, the following vulnerability has been resolved:

ip6mr: do not clone dst in ip6mrcachereport()

IPv6 input attaches a non-refcounted (NOREF) dst to skbs under RCU. When an ingress multicast packet misses MFC lookup, ip6mrcacheunresolved() 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, ip6mrforward() invokes ip6mrcachereport(..., MRT6MSGWRONGMIF), which executes dstclone(skbdst(pkt)) on the freed dst entry, triggering a slab use-after-free.

Report packets queued to mroute6sk (a raw socket) and netlink notifications do not require an attached dst entry.

Fix this by: 1. Removing dstclone() in ip6mrcachereport() and ensuring report skbs do not hold a dst. 2. Dropping skbdst before queuing unresolved skbs in ip6mrcacheunresolved(), matching the fact that multicast forwarding resolves outgoing routes anew via ip6routeoutput().

Affected Software

1 affected component

Linux Kernel

Event History

Sep 17, 2026

CVE Published

via MITRE·04:06 PM

Data Sourced

via MITRE·04:06 PM

Description

Frequently Asked Questions

What conditions are needed to trigger the use-after-free?

An ingress IPv6 multicast packet must miss the multicast forwarding cache and be queued as unresolved. The underlying route must then be deleted and freed before the queue is resolved with a wrong parent interface, causing a wrong-MIF report path to access the stale destination entry.

Which systems are realistically exposed?

Systems using Linux kernel IPv6 multicast routing are exposed when they can receive multicast traffic that enters the unresolved MFC queue. The described trigger also requires multicast forwarding processing to later resolve the queued packet with an incorrect parent interface.

How can administrators tell whether the vulnerable path may have been exercised?

The described symptom is a slab use-after-free when the wrong-MIF reporting path calls dst_clone on a freed destination entry. This occurs in the sequence involving an unresolved IPv6 multicast forwarding-cache entry, route deletion, and later wrong-parent-interface resolution.

What does the fix change?

The fix removes destination cloning from ip6mr_cache_report() and ensures report packets have no attached destination entry. It also drops the skb destination before unresolved multicast packets are queued, while multicast forwarding resolves outgoing routes again through ip6_route_output().

CVE-2026-90111: ip6mr: do not clone dst in ip6mr_cache_report()

Affected Software

Event History

Frequently Asked Questions

What conditions are needed to trigger the use-after-free?

Which systems are realistically exposed?

How can administrators tell whether the vulnerable path may have been exercised?

What does the fix change?

Company

Resources

Contact

Frequently Asked Questions

What conditions are needed to trigger the use-after-free?

Which systems are realistically exposed?

How can administrators tell whether the vulnerable path may have been exercised?

What does the fix change?