CVE-2026-52979

What it actually does

This is a race condition in the Linux kernel PSP networking code. A socket association path can obtain a temporary PSP device reference, then drop that reference before confirming under the device lock that the device is still registered. If device unregistration completes in that timing window, subsequent association creation may operate on cleared or no-longer-valid device state. Depending on kernel configuration and memory layout, the likely technical outcomes are kernel crash, warning/oops, use-after-free-like behavior, or other memory-safety side effects in kernel context. No public exploit maturity is currently indicated and EPSS is very low, but kernel race conditions can be difficult to assess until more operational details emerge.

Why it matters to the business

Systems running affected Linux kernel versions with the relevant PSP networking functionality exposed may be vulnerable to local or network-adjacent denial of service if an attacker can trigger association creation while device unregistration is occurring. The most likely business consequence is host instability, service interruption, or node reboot, which can affect workloads running on bare metal, virtualized infrastructure, appliances, or container hosts that inherit the vulnerable kernel. Because this is not in the CISA KEV catalog, is not known to be used in ransomware campaigns, has no known public exploit maturity, and has a low EPSS score, it should be prioritized through normal kernel maintenance unless the affected functionality is enabled on critical systems or exposed to untrusted users.

How an attack unfolds

An attacker would need a way to cause or influence PSP association creation while also causing the associated PSP device to unregister or transition out of service. The attacker repeatedly exercises the association creation path so that psp_assoc_device_get_locked() obtains a PSP device reference through psp_dev_get_for_sock(), but the underlying device unregisters before the device lock is acquired and before liveness is revalidated. If the timing is won, the kernel may continue using state that was cleared during psp_dev_unregister(), causing a crash, oops, or potentially unsafe memory access. Practical exploitation is expected to require precise timing, local privileges or access to relevant networking/device controls, and a kernel build/configuration where this PSP code path is reachable.

How to fix it

Apply a vendor kernel update that includes the fix adding a registration/liveness check when creating PSP associations after acquiring the device lock. Because no specific affected product list or fixed package versions were provided, track the fix through the Linux kernel stable trees and your OS, appliance, cloud image, or distribution vendor advisories. Reboot into the updated kernel after patching; simply installing the package is not sufficient if the running kernel remains old. Where immediate patching is not possible, reduce exposure by disabling unused PSP networking functionality if supported, limiting untrusted local access, restricting administrative access to device/network teardown operations, and scheduling maintenance windows for critical systems that rely on the affected kernel component.

How to confirm the fix worked

Confirm that the running kernel, not just the installed kernel package, includes the upstream fix for the PSP association device liveness check. Validate with vendor advisory metadata, package changelogs, kernel source references, or by confirming the patched code path checks that the PSP device is still registered after the lock is acquired. After patching and rebooting, verify the active kernel version with standard OS tooling and confirm there are no recurring kernel oops, panic, KASAN, or PSP-related warnings during device registration/unregistration testing. If source validation is possible, verify that the association creation path calls or otherwise enforces psp_dev_is_registered() while protected by the device lock before using device state.

Typical attack path

1. Identify a Linux system running an affected kernel with PSP networking support enabled or reachable.
2. Obtain the ability to create sockets or traffic that reaches the PSP association creation path.
3. Trigger PSP association creation repeatedly to increase the race window.
4. Concurrently trigger or wait for PSP device unregistration or teardown activity.
5. Win the race between reference acquisition, lock acquisition, and device unregistration.
6. Cause the kernel to access cleared or invalid PSP device state, resulting in a crash, oops, or related kernel fault.

How to detect it

Look for evidence of prior exploitation primarily through kernel stability artifacts rather than definitive attacker indicators. Review kernel logs, journald, syslog, dmesg archives, crash dumps, kdump/vmcore files, hypervisor reset records, and EDR kernel telemetry for oops, panic, general protection fault, NULL pointer dereference, use-after-free, KASAN, or lockdep reports that mention PSP association or unregister functions. Correlate crashes with bursts of socket creation, device teardown, interface reconfiguration, module unload/reload activity, container or namespace churn, or privileged user actions. Because no public exploit signature is known, absence of these artifacts does not prove absence of exploitation, and presence of a crash is not proof of malicious activity; focus on suspicious timing, repeated triggering, and untrusted users or workloads near the event.

• psp_assoc_device_get_locked
• psp_dev_get_for_sock
• psp_dev_tryget
• psp_dev_unregister
• psp_dev_is_registered
• KASAN: use-after-free
• BUG: kernel NULL pointer dereference
• general protection fault
• kernel panic
• Oops:
• INFO: rcu
• WARNING: CPU:

What your security team should do

• Inventory Linux systems and appliances running kernels that include PSP networking support, with priority on internet-facing infrastructure, multi-user systems, container hosts, and critical service nodes.
• Monitor vendor advisories for your Linux distribution, appliance, or cloud image and apply the first kernel update that includes the fix.
• Reboot patched systems into the fixed kernel and verify the active runtime version after maintenance.
• If patching is delayed, restrict untrusted shell access and administrative operations that can manipulate relevant networking devices or trigger teardown paths.
• Enable or review kernel crash collection, kdump, journald, syslog, and EDR telemetry for kernel oops or panic events involving PSP functions.
• Treat unexplained kernel crashes involving PSP association or device unregister functions as potentially security-relevant until ruled out.
• Because this is not KEV-listed and has very low EPSS with no known exploit maturity, prioritize remediation based on exposure and operational criticality rather than emergency internet-wide response.