CVE-2026-45847

What it actually does

This is a local Linux kernel availability flaw triggered when a sufficiently long network forwarding path, made more reachable by IPIP tunnel support, reaches a kernel WARN_ON_ONCE condition while accessing the forward-path array. On systems configured to panic on kernel warnings, or where repeated warning-triggered paths destabilize networking/kernel behavior, a low-privileged local attacker with the ability to influence tunnel or network namespace configuration can cause a denial of service. The issue does not provide confidentiality or integrity impact and is not described as enabling code execution or privilege escalation.

Why it matters to the business

Successful exploitation can crash or destabilize affected Linux systems, interrupting workloads, network services, containers, or virtualized environments that rely on kernel networking. Risk is highest on multi-user systems, container hosts, development platforms, and environments where unprivileged users can create network namespaces or otherwise obtain limited network-administration capabilities. The vulnerability is not currently listed in CISA KEV, has very low EPSS, and has no known mature public exploit, so urgency is moderate; however, Linux kernel flaws can have broad operational reach because the affected component is widely deployed.

How an attack unfolds

An attacker first needs local access to an affected Linux system and some ability to manipulate networking constructs, commonly through delegated CAP_NET_ADMIN, container or namespace features, or permissive user namespace settings. The attacker then builds an unusually long forwarding path using network devices and tunnel constructs such as IPIP. When the kernel evaluates that forwarding path, it reaches a WARN_ON_ONCE condition while accessing the forward-path array. If the host is configured to treat kernel warnings as fatal, the warning can trigger a kernel panic and immediate denial of service. Even without panic-on-warn, the condition can generate kernel warnings and may disrupt network behavior or system stability depending on configuration and workload.

How to fix it

Upgrade the Linux kernel to a vendor-supported release that includes the upstream fix removing the unsafe WARN_ON_ONCE behavior in the network forwarding-path handling. No exact fixed package versions were provided in the input, so use the relevant distribution or appliance vendor advisory for the corrected kernel build and reboot into the patched kernel after installation. As interim mitigations, restrict local users and containers from obtaining CAP_NET_ADMIN unless required, disable or limit unneeded user namespaces where operationally feasible, avoid allowing untrusted users to create IPIP or other tunnel interfaces, remove or block unneeded tunnel modules, and review whether kernel.panic_on_warn is intentionally enabled because it can turn warning conditions into full host crashes.

How to confirm the fix worked

Confirm that systems are running a kernel build that contains the vendor fix by checking the active kernel version after reboot, not only the installed package version. Validate that package management shows the corrected kernel installed and that old vulnerable kernels are not the default boot entry. Review sysctl settings such as kernel.panic_on_warn to understand residual denial-of-service exposure. Where safe, test representative tunnel and forwarding configurations in a non-production environment to ensure no kernel warnings are emitted. Also verify that untrusted users or containers cannot create IPIP tunnels, network namespaces, or virtual network forwarding chains unless explicitly intended.

Typical attack path

1. Gain local shell or code execution as a low-privileged user on an affected Linux host.
2. Obtain or abuse the ability to create network namespaces, virtual interfaces, or tunnel devices, such as through CAP_NET_ADMIN inside a namespace or container.
3. Construct a sufficiently long network forwarding path, potentially involving IPIP tunnel interfaces and stacked virtual networking components.
4. Trigger kernel forwarding-path evaluation by configuring or exercising the crafted path.
5. Cause the vulnerable kernel WARN_ON_ONCE path to execute.
6. Induce a denial of service, especially on systems where kernel.panic_on_warn is enabled.

How to detect it

Look for evidence of prior exploitation in kernel logs, system journals, audit logs, and container/runtime logs. Key sources include dmesg output, /var/log/kern.log, /var/log/messages, systemd-journald kernel facility logs, auditd records for network administration commands, and shell/process accounting where available. Investigate kernel warnings that coincide with creation of IPIP tunnels, virtual interfaces, network namespaces, veth pairs, bridges, or unusual interface stacking. Pay particular attention to WARN_ON_ONCE or WARNING traces followed by reboot, kernel panic, node not-ready events, service interruption, or container host instability. If auditd or EDR telemetry is available, search for local users or containers executing commands such as ip tunnel add, ip link add, modprobe ipip, unshare --net, or nsenter with network namespace operations shortly before a kernel warning or crash. There are no known public threat actors or campaigns tied to this issue in the provided data.

• WARNING: CPU:
• WARN_ON_ONCE
• kernel.panic_on_warn
• dev_fill_forward_path
• ipip
• modprobe ipip
• ip tunnel add
• ip link add
• unshare --net
• CAP_NET_ADMIN
• Call Trace:
• Kernel panic - not syncing

What your security team should do

• Inventory Linux systems where local users, containers, CI jobs, or sandboxed workloads can create network namespaces or tunnel devices.
• Prioritize patching multi-tenant Linux hosts, container platforms, bastion/developer systems, and hosts with kernel.panic_on_warn enabled.
• Upgrade to the vendor-fixed kernel and reboot; verify the running kernel is the patched version.
• Restrict CAP_NET_ADMIN and tunnel creation privileges for untrusted users and workloads.
• Review and harden user namespace policy, container runtime capabilities, and seccomp/AppArmor/SELinux controls around network administration operations.
• Monitor kernel logs for WARN_ON_ONCE, forwarding-path, and IPIP-related warning activity until all affected systems are patched.
• Because EPSS is very low and there is no known KEV listing or mature exploit, treat this as a controlled remediation item unless affected systems are multi-user or exposed to untrusted local workloads.