CVE-2026-74581: net: ipv6: clear suppressed fib6 rule result
A use-after-free vulnerability was found in the Linux kernel's IPv6 FIB rule lookup path. In fib6rulesuppress(), when a route is suppressed and released via ip6rtputflags(), the res->rt6 pointer is not cleared. If no later rule supplies a replacement route, fib6rulelookup() returns the stale (freed) rt6info to its caller. The subsequent dstrelease() then operates on freed memory, hitting rcurefputslowpath(). A local attacker who can configure IPv6 routing/FIB rules could trigger this to cause a denial of service (kernel crash) or potentially escalate privileges.
Other sources
In the Linux kernel, the following vulnerability has been resolved:
net: ipv6: clear suppressed fib6 rule result
fib6rulesuppress() drops a suppressed route with ip6rtputflags(), but leaves res->rt6 pointing at the released rt6info.
If no later rule supplies a replacement, fib6rulelookup() still sees res.rt6 and returns that stale dst to its caller. A suppressing rule can therefore leak a released route back to rt6lookup(), and the next put hits rcurefputslowpath() from dstrelease().
Clear res->rt6 when suppressing the route so suppressed lookups fall through to the null dst instead of reusing the released one.
— MITRE
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Fixed in 6.6.152.1-1 - Configuration
Apply the kernel fix described: in fib6_rule_suppress(), when a route is suppressed and released via ip6_rt_put_flags()/dst_release(), clear res->rt6 so suppressed lookups do not return a freed rt6_info.
Linux kernel (IPv6 FIB rule lookup path) Clear res->rt6 when suppressing the route in fib6_rule_suppress() = Cleared (set res->rt6 to null)
Event History
Frequently Asked Questions
What configuration is required to trigger this issue?
The issue requires an IPv6 policy-routing rule that suppresses a route. It manifests when that suppressed route is released and no later rule provides a replacement route.
What is the observable impact of an affected lookup?
A suppressed lookup can return a stale released route to rt6_lookup() rather than falling through to the null destination. A subsequent release of that destination can reach rcuref_put_slowpath() through dst_release().
How can this be mitigated before applying the fix?
Avoid IPv6 FIB rule configurations that suppress routes, particularly where no subsequent rule supplies a replacement. This prevents the suppressed-route path described in the issue.