CVE-2026-31504

What it actually does

CVE-2026-31504 is a Linux kernel use-after-free race in AF_PACKET fanout socket teardown. During packet_release(), a concurrent NETDEV_UP notification can re-register a socket into a packet fanout group's member array after release processing has begun. Because the re-registration does not correctly maintain the fanout socket reference count, the fanout array can retain a dangling pointer to a freed socket. A local attacker with the ability to create AF_PACKET sockets can potentially trigger the race to corrupt kernel memory, leading to local privilege escalation, kernel code execution, information disclosure, or denial of service.

Why it matters to the business

Successful exploitation could allow a low-privileged local user or compromised workload on a Linux system to gain kernel-level control, potentially exposing sensitive data, disabling security controls, or taking over the host. The issue is not currently listed in CISA KEV, has very low EPSS, no known mature public exploit, and is not known to be used in ransomware campaigns, but kernel privilege-escalation flaws should still be prioritized on multi-user systems, container hosts, build servers, and internet-facing services where attackers may first gain limited code execution.

How an attack unfolds

An attacker first obtains local code execution with low privileges on an affected Linux system. They create AF_PACKET sockets configured for packet fanout and bind them to a network interface. They then repeatedly race socket release against network interface up events so that packet_release() progresses while packet_notifier(NETDEV_UP) still observes the socket as eligible for re-registration. In the vulnerable path, the socket can be inserted back into the fanout group's array without a corresponding socket reference. Once the socket is freed, the fanout group may still hold a pointer to freed memory. The attacker attempts to reclaim or shape that freed kernel memory with controlled objects and then trigger packet fanout processing to dereference the stale pointer. Depending on heap layout and exploit reliability, this may crash the kernel or be developed into arbitrary kernel memory read/write and local privilege escalation.

How to fix it

Upgrade to a Linux kernel version that includes the fix for this issue. The corrected behavior sets po->num to zero while bind_lock is held in packet_release(), preventing NETDEV_UP from re-linking the socket during teardown. Because no exact fixed versions were provided, obtain patched kernels from the applicable Linux distribution or kernel vendor and verify the vendor advisory references this CVE or the packet_release()/NETDEV_UP fanout UAF fix. If immediate patching is not possible, reduce exposure by restricting unprivileged access to AF_PACKET sockets where feasible, disabling unprivileged user namespaces if they increase local attack surface, limiting shell or workload access on shared systems, enforcing least privilege for container workloads, and monitoring or controlling capabilities such as CAP_NET_RAW and CAP_NET_ADMIN. Reboot systems after kernel updates so the patched kernel is actually running.

How to confirm the fix worked

Confirm the running kernel, not only the installed package, has been updated to a vendor build containing the fix. On Linux systems, compare uname -r with the patched kernel package version and the distribution security advisory. Review kernel changelogs for the packet_release(), NETDEV_UP, AF_PACKET fanout, or po->num bind_lock fix. Validate that systems requiring mitigation have restricted unprivileged AF_PACKET usage and that containers or services do not unnecessarily run with CAP_NET_RAW or CAP_NET_ADMIN. Where source validation is possible, confirm packet_release() clears po->num while bind_lock is held. After patching, reboot and verify the running kernel changed. There is no reliable remote scanner for exploitation because this is a local kernel race condition; exposure validation should focus on kernel version, local user access, and network-related capabilities.

Typical attack path

1. Gain local execution on an affected Linux host as an unprivileged or low-privileged user.
2. Create AF_PACKET sockets and configure packet fanout behavior.
3. Bind the sockets to a network interface whose state can be toggled or raced with NETDEV_UP notifications.
4. Trigger packet_release() while concurrently causing NETDEV_UP processing to re-register the socket into the fanout group.
5. Leave a stale socket pointer in the fanout member array after the underlying socket object is released.
6. Manipulate kernel heap allocations to reclaim the freed memory with attacker-influenced data.
7. Trigger packet processing through the fanout path to dereference the dangling pointer.
8. Use the resulting memory corruption for kernel crash, information disclosure, or privilege escalation.

How to detect it

There are no known public, stable, grep-able exploitation indicators for this vulnerability and no KEV listing at this time. Detection should focus on signs of attempted local kernel exploitation rather than a unique signature. Review kernel logs, audit logs, EDR telemetry, and container runtime logs for kernel oops or panic events around AF_PACKET, packet fanout, socket release, or network interface up/down activity. Hunt for unusual local processes creating large numbers of packet sockets, using PACKET_FANOUT, repeatedly toggling network interfaces, or running with CAP_NET_RAW/CAP_NET_ADMIN without an expected operational reason. On container hosts, review privileged container launches and capability additions shortly before crashes or privilege changes. Investigate unexpected transitions to root, new setuid binaries, suspicious kernel module loads, disabled security agents, or unexplained host reboots following local user or workload activity. Because exploitation is a race condition, failed attempts may appear only as kernel instability or general protection faults rather than a clean application log entry.

What your security team should do

• Inventory Linux systems and identify those running affected kernels, prioritizing multi-user hosts, container nodes, CI/CD runners, bastion hosts, and systems that allow untrusted local code execution.
• Apply vendor kernel updates that include the AF_PACKET fanout packet_release()/NETDEV_UP race fix, then reboot into the patched kernel.
• Prioritize remediation on systems where users or workloads can create AF_PACKET sockets, use CAP_NET_RAW, use CAP_NET_ADMIN, or run inside privileged containers.
• Temporarily reduce attack surface by removing unnecessary Linux capabilities from containers and services, disabling privileged containers where possible, and limiting unprivileged user namespaces if operationally acceptable.
• Monitor for suspicious local privilege-escalation behavior, kernel crashes, unusual AF_PACKET socket usage, and rapid network interface state changes by non-administrative processes.
• Because EPSS is low and no public exploit maturity is reported, schedule patching according to kernel privilege-escalation risk rather than emergency internet-facing remote-code-execution procedures, unless the environment hosts untrusted users or workloads.