CVE-2026-52979: Linux Kernel PSP Device Unregister Race Condition Denial of Service

Technical summary

The vulnerability exists in psp_assoc_device_get_locked() within the Linux kernel's PSP network handling. The function acquires a device reference via RCU-protected psp_dev_tryget(), then takes a spinlock (psd->lock) on the device. However, between releasing the initial reference and acquiring the lock, psp_dev_unregister() can complete its cleanup sequence—clearing state and dropping its registration reference—without the association code detecting this state change. The fix adds a call to the existing but unused psp_dev_is_registered() check after the lock is acquired, ensuring the device remains valid before proceeding. This is a classic "upgrading a reference" concurrency issue similar to netdev handling patterns.

Business impact

On systems using PSP-based network security features, this vulnerability can be exploited by a local unprivileged user to trigger a kernel panic or hang, effectively denying service to legitimate users and applications. The disruption requires a reboot to recover. For organizations relying on PSP for network isolation or encrypted communication, successful exploitation undermines availability guarantees and may trigger incident response workflows.

Affected systems

Linux kernel systems with PSP (Platform Security Processor) networking support enabled. This affects distributions and embedded systems that compile the PSP subsystem into their kernel. The vulnerability is present in kernel versions prior to the fix; consumers should verify their specific kernel version against vendor advisories, as PSP is not universally enabled in all Linux builds.

Exploitability

Exploitation requires local access and unprivileged user privileges (PR:L in the CVSS vector), making this a lower-bar attack than remote exploits. An attacker can trigger the race condition by timing device unregistration against association creation, causing a kernel panic. No network access or special capabilities are needed. The attack is relatively straightforward to trigger once an attacker has local shell access, though the precise timing window may require some experimentation.

Remediation

Apply the Linux kernel patch that adds the psp_dev_is_registered() check in psp_assoc_device_get_locked(). The fix is minimal and defensive: after acquiring the lock, verify the device is still registered before using it. Verify the patched kernel version against your distribution's security advisory to confirm the exact version containing this fix.

Patch guidance

Update your Linux kernel to a version that includes the PSP device-unregister check fix. Contact your Linux distribution vendor for the specific patched kernel version (e.g., Red Hat, Canonical, SUSE). If running a custom or embedded kernel, apply the upstream kernel patch directly. Test the patched kernel in a staging environment before deploying to production to ensure no regressions with your PSP configuration.

Detection guidance

Monitor kernel logs for PSP-related errors or unexpected panics, particularly if they correlate with network association creation or device management events. Use tools like `journalctl` or `/var/log/kern.log` to capture panic backtraces. If PSP is in use, inspect kernel configuration (`/boot/config-*` or `uname -a`) to confirm PSP subsystem presence. Check for repeated device unregister or association errors in kernel debug logs if available.

Why prioritize this

This vulnerability merits prompt but measured attention: it is locally exploitable with unprivileged access, causing denial of service on affected systems. However, the CVSS score of 5.5 (MEDIUM) reflects that it does not enable privilege escalation, data theft, or remote attacks. Prioritize patching PSP-enabled systems in high-availability environments or systems exposed to untrusted local users. Standard server deployments without PSP are not affected.

Risk score, explained

CVSS 5.5 (MEDIUM) reflects: local attack vector (AV:L), low complexity (AC:L), low privilege requirement (PR:L), no user interaction (UI:N), system scope unchanged (S:U), zero confidentiality/integrity impact (C:N/I:N), but high availability impact (A:H) from kernel panic. The score appropriately captures a denial-of-service threat that does not compromise system integrity or confidentiality.

Frequently asked questions