CVE-2026-43339

What it actually does

This is a local use-after-free flaw in the Linux kernel IPv6 address-configuration path, specifically in addrconf_permanent_addr(). Under certain timing conditions, the kernel can access an IPv6-related object after it may already have been deleted. Because the bug occurs in kernel memory, successful exploitation could allow a local low-privileged user to crash the system or potentially escalate privileges by corrupting or reusing freed kernel memory. The CVSS vector indicates local access is required, attack complexity is low, no user interaction is required, and successful exploitation can affect confidentiality, integrity, and availability at the kernel level.

Why it matters to the business

A successful attack could allow a user with local access to disrupt Linux systems or potentially gain elevated privileges, creating risk for shared servers, multi-user systems, developer workstations, container hosts, and environments that permit unprivileged namespace or network configuration activity. The issue is not known to be exploited in the wild, is not in CISA KEV, has no known ransomware association, and has a low EPSS score, so urgency is lower than for actively exploited internet-facing vulnerabilities; however, kernel privilege-escalation flaws should still be prioritized on systems that host untrusted users, workloads, containers, or remote shell access.

How an attack unfolds

An attacker first obtains local low-privileged access to a vulnerable Linux system. They then trigger IPv6 address-configuration activity, likely involving interface, address, or namespace lifecycle changes that cause the kernel IPv6 address-configuration helper to operate on an object near the time it is deleted. By repeatedly exercising this race or lifecycle condition, the attacker attempts to cause the kernel to dereference freed memory. A simple exploit path may result in a kernel oops or panic, causing denial of service. A more advanced exploit would attempt to reclaim the freed memory with attacker-influenced data and redirect kernel execution or modify kernel data structures to gain elevated privileges. No public exploit maturity is currently indicated, and the vulnerability requires local access rather than remote network-only reachability.

How to fix it

Upgrade to a Linux kernel version or vendor-maintained kernel package that includes the upstream fix for the IPv6 addrconf_permanent_addr() use-after-free. Because no exact fixed package versions were provided, use the relevant Linux distribution security advisory, long-term-stable kernel release notes, or vendor errata to identify the corrected kernel for each supported platform. After installation, reboot into the updated kernel and remove or de-prioritize vulnerable kernels from bootloader options where operationally feasible. If immediate patching is not possible, reduce exposure by limiting local shell access, restricting untrusted workloads, disabling or restricting unprivileged user namespaces where appropriate, limiting CAP_NET_ADMIN and network namespace creation, and disabling IPv6 only where it is operationally safe and formally approved. Mitigations should be treated as risk reduction, not a substitute for applying the fixed kernel.

How to confirm the fix worked

Confirm the running kernel, not merely the installed package, has been updated by checking uname -r after reboot and comparing it with the vendor advisory or fixed kernel package. Verify that package managers show the corrected kernel installed and that the system booted into it. Review bootloader entries to ensure older vulnerable kernels are not the default. Where available, use vulnerability scanner plugins, distribution OVAL feeds, or kernel live-patch status tools to confirm the fix is present. For higher assurance, compare the kernel source or vendor changelog for the IPv6 addrconf_permanent_addr() fix that reorders access to avoid using the IPv6 object after possible deletion.

Typical attack path

1. Obtain local low-privileged access to a vulnerable Linux system.
2. Identify that the running kernel includes the vulnerable IPv6 addrconf code path.
3. Trigger IPv6 address-configuration, interface, or network namespace lifecycle activity that reaches addrconf_permanent_addr().
4. Race or repeat object deletion and warning/logging behavior so the kernel accesses IPv6-related memory after it has been freed.
5. Use the resulting memory corruption to crash the kernel or attempt controlled kernel-memory reuse for privilege escalation.
6. If privilege escalation succeeds, execute commands with elevated kernel or root-level privileges.

How to detect it

To determine whether exploitation may have already occurred, review local kernel telemetry and system logs rather than network perimeter logs, because exploitation requires local access. Collect and search dmesg output, systemd journal kernel logs, /var/log/kern.log, /var/log/messages, /var/log/syslog, crash dumps, kdump/vmcore artifacts, audit logs, and EDR telemetry around times of unexpected reboots, kernel oopses, or privilege changes. Look for kernel warnings, panics, KASAN reports, slab corruption, general protection faults, or call traces that reference IPv6 address configuration functions, especially addrconf_permanent_addr or net/ipv6/addrconf.c. Correlate suspicious kernel faults with local user activity, namespace creation, interface manipulation, iproute2 commands, container launches, or unusual attempts to create/delete network interfaces or IPv6 addresses. Absence of these artifacts does not prove non-exploitation, because a successful privilege-escalation exploit may avoid crashes or clear logs.

• addrconf_permanent_addr
• net/ipv6/addrconf.c
• BUG: KASAN: use-after-free
• use-after-free in addrconf_permanent_addr
• RIP: addrconf_permanent_addr
• Call Trace: addrconf_permanent_addr
• general protection fault
• kernel NULL pointer dereference
• kernel BUG at net/ipv6/addrconf.c
• WARNING: CPU:
• Oops:
• Kernel panic - not syncing
• slab corruption
• IPv6: addrconf

What your security team should do

• Prioritize patching Linux systems that allow local users, SSH access, shared development, CI/CD workloads, containers, or untrusted code execution.
• Update affected systems to a vendor kernel containing the IPv6 addrconf_permanent_addr() use-after-free fix and reboot into the corrected kernel.
• Inventory systems with IPv6 enabled and systems that permit unprivileged user namespaces or network namespace creation, as these may have a more reachable trigger surface.
• Apply compensating controls until patching is complete: restrict local account access, limit CAP_NET_ADMIN, review container privileges, and consider disabling unprivileged user namespaces where compatible.
• Monitor kernel logs for oops, panic, KASAN, slab, or use-after-free messages involving IPv6 address configuration or addrconf_permanent_addr().
• Because this is not currently KEV-listed, has no known ransomware use, and has low EPSS, handle through expedited kernel maintenance rather than emergency internet-exposure response unless local multi-user or untrusted workload risk is high.