FKIE_CVE-2026-23304
Vulnerability from fkie_nvd - Published: 2026-03-25 11:16 - Updated: 2026-04-18 09:16
Severity ?
Summary
In the Linux kernel, the following vulnerability has been resolved:
ipv6: fix NULL pointer deref in ip6_rt_get_dev_rcu()
l3mdev_master_dev_rcu() can return NULL when the slave device is being
un-slaved from a VRF. All other callers deal with this, but we lost
the fallback to loopback in ip6_rt_pcpu_alloc() -> ip6_rt_get_dev_rcu()
with commit 4832c30d5458 ("net: ipv6: put host and anycast routes on
device with address").
KASAN: null-ptr-deref in range [0x0000000000000108-0x000000000000010f]
RIP: 0010:ip6_rt_pcpu_alloc (net/ipv6/route.c:1418)
Call Trace:
ip6_pol_route (net/ipv6/route.c:2318)
fib6_rule_lookup (net/ipv6/fib6_rules.c:115)
ip6_route_output_flags (net/ipv6/route.c:2607)
vrf_process_v6_outbound (drivers/net/vrf.c:437)
I was tempted to rework the un-slaving code to clear the flag first
and insert synchronize_rcu() before we remove the upper. But looks like
the explicit fallback to loopback_dev is an established pattern.
And I guess avoiding the synchronize_rcu() is nice, too.
References
Impacted products
| Vendor | Product | Version |
|---|
{
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nipv6: fix NULL pointer deref in ip6_rt_get_dev_rcu()\n\nl3mdev_master_dev_rcu() can return NULL when the slave device is being\nun-slaved from a VRF. All other callers deal with this, but we lost\nthe fallback to loopback in ip6_rt_pcpu_alloc() -\u003e ip6_rt_get_dev_rcu()\nwith commit 4832c30d5458 (\"net: ipv6: put host and anycast routes on\ndevice with address\").\n\n KASAN: null-ptr-deref in range [0x0000000000000108-0x000000000000010f]\n RIP: 0010:ip6_rt_pcpu_alloc (net/ipv6/route.c:1418)\n Call Trace:\n ip6_pol_route (net/ipv6/route.c:2318)\n fib6_rule_lookup (net/ipv6/fib6_rules.c:115)\n ip6_route_output_flags (net/ipv6/route.c:2607)\n vrf_process_v6_outbound (drivers/net/vrf.c:437)\n\nI was tempted to rework the un-slaving code to clear the flag first\nand insert synchronize_rcu() before we remove the upper. But looks like\nthe explicit fallback to loopback_dev is an established pattern.\nAnd I guess avoiding the synchronize_rcu() is nice, too."
},
{
"lang": "es",
"value": "En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:\n\nipv6: correcci\u00f3n de desreferencia de puntero NULL en ip6_rt_get_dev_rcu()\n\nl3mdev_master_dev_rcu() puede devolver NULL cuando el dispositivo esclavo est\u00e1 siendo desasociado de un VRF. Todos los dem\u00e1s llamadores manejan esto, pero perdimos la alternativa a loopback en ip6_rt_pcpu_alloc() -\u0026gt; ip6_rt_get_dev_rcu() con el commit 4832c30d5458 (\u0027net: ipv6: put host and anycast routes on device with address\u0027).\n\n KASAN: desreferencia de puntero nulo en el rango [0x0000000000000108-0x000000000000010f]\n RIP: 0010:ip6_rt_pcpu_alloc (net/ipv6/route.c:1418)\n Traza de Llamadas:\n ip6_pol_route (net/ipv6/route.c:2318)\n fib6_rule_lookup (net/ipv6/fib6_rules.c:115)\n ip6_route_output_flags (net/ipv6/route.c:2607)\n vrf_process_v6_outbound (drivers/net/vrf.c:437)\n\nMe sent\u00ed tentado a reelaborar el c\u00f3digo de desasociaci\u00f3n para borrar la bandera primero e insertar synchronize_rcu() antes de que eliminemos el superior. Pero parece que la alternativa expl\u00edcita a loopback_dev es un patr\u00f3n establecido. Y supongo que evitar el synchronize_rcu() tambi\u00e9n es bueno."
}
],
"id": "CVE-2026-23304",
"lastModified": "2026-04-18T09:16:18.170",
"metrics": {},
"published": "2026-03-25T11:16:26.180",
"references": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/0b5a7826020706057cc5a9d9009e667027f221ee"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/2ffb4f5c2ccb2fa1c049dd11899aee7967deef5a"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/3310fc11fc47387d1dd4759b0bc961643ea11c7f"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/4a48fe59f29f673a3d042d679f26629a9c3e29d4"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/581800298313c9fd75e94985e6d37d21b7e35d34"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/a73fe9f4ae84a239d5b2686f47a58c158aee2eb4"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/ae88c8256547b63980770a9ea7be73a15900d27e"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/d542e2ac7f9e288d49735be0775611547ca4e0ee"
}
],
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"vulnStatus": "Awaiting Analysis"
}
Loading…
Loading…
Experimental. This forecast is provided for visualization only and may change without notice. Do not use it for operational decisions.
Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Loading…
Loading…