---
id: "CVE-2026-99074"
kind: "vulnerability"
aliases: ["CVE-2026-99074"]
title: "Linux kernel: IPv4 PMTU update can dereference a null nexthop pointer"
severity: "unknown"
cvss: null
epss: 0.00199
exploited: false
status: "open"
category: "infrastructure"
products: []
ecosystems: []
tags: ["infrastructure", "ipv4", "kernel", "linux", "multi-tenant-hosts", "routing"]
not_affected_if: ["no-nexthop-groups", "unprivileged-userns-disabled"]
published_at: "2026-10-23T13:17:31+00:00"
first_seen_at: "2026-10-23T21:57:34+00:00"
updated_at: "2026-10-25T12:38:50+00:00"
sources: [{"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-99074", "first_seen_at": "2026-10-23T21:57:34+00:00"}, {"source": "epss", "url": "https://api.first.org/data/v1/epss?cve=CVE-2026-99074", "first_seen_at": "2026-10-25T12:38:50+00:00"}]
---

# Linux kernel: IPv4 PMTU update can dereference a null nexthop pointer

When a nexthop group shrinks during a path MTU update, the IPv4 code can dereference a null pointer and crash the kernel. The sources describe a local crash and do not state an attacker code execution path.

_Summary, check and fix written by a model from the sources; labelled as such._

## How to check

- `uname -r` to see the running kernel version
- Check whether unprivileged user namespaces are enabled: `sysctl kernel.unprivileged_userns_clone` or `sysctl user.max_user_namespaces`
- Check your distribution's kernel advisory for whether the fixed kernel is installed

## Fix

- Update the Linux kernel to a release that includes the upstream fix (the 'stop PMTU walk when nexthop group shrinks' change); the fixed version is unknown from these sources
- Until patched, consider disabling unprivileged user namespaces if your workloads allow it

## Timeline

- 2026-10-23T21:57:34+00:00 nvd https://nvd.nist.gov/vuln/detail/CVE-2026-99074
- 2026-10-25T12:38:50+00:00 epss https://api.first.org/data/v1/epss?cve=CVE-2026-99074

## From the sources

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

ipv4: stop PMTU walk when nexthop group shrinks

Commit 7d3f3b4367f3 ("net: ipv4: Cache pmtu for all packet paths if
multipath enabled") made __ip_rt_update_pmtu() update every path.

For nexthop objects, fib_info_num_path() and fib_info_nhc()
independently load nh->nh_grp.  RCU protects each group's lifetime but
does not make the loads observe the same group.  If replacement shrinks
the group after the loop accepts an index, fib_info_nhc() returns NULL
and update_or_create_fnhe() dereferences it.

A deterministic probe only widened the existing window between the real
operations.  On v7.2, an RTM_NEWNEXTHOP replacement published a
one-member group after the PMTU reader accepted index 1 from a two-member
group, producing:

  KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
  RIP: update_or_create_fnhe+0x45/0x15b0

Stop when the indexed path is absent.  Groups are dense, so no later
index exists in that snapshot.  The same real-writer window completed
114,423 PMTU iterations without an oops with this check.  A reproducer
is available on request.

Replacement requires CAP_NET_ADMIN in the network namespace.  Where
unprivileged user namespaces are permitted, a local user can obtain it
in a new user and network namespace.

---

_Free to read at a human pace. An API with keys and an MCP server are in preparation; early access: hello@infrastack.ai_