CVE-2026-64177: Linux Kernel Race Condition Vulnerability

CVE-2026-64177 Overview

CVE-2026-64177 is a Linux kernel vulnerability in the Phonet protocol's Packet Encapsulation Protocol (PEP) implementation. The flaw exists in pep_do_rcv() where the forwarded sk_receive_skb() call acquires a child socket lock without disabling bottom halves (BH). This creates an inconsistent lock state between the process context path and the softirq context path.

Lockdep flags the condition as a SOFTIRQ-ON-W versus IN-SOFTIRQ-W inconsistency. The bug can escalate to a self-deadlock when a softirq on the same CPU attempts to receive on the same child socket while its slock is held in the BH-enabled path.

Critical Impact
Local attackers with the ability to open Phonet sockets can trigger kernel self-deadlocks, causing denial of service on affected systems.

Affected Products

Linux kernel Phonet/PEP subsystem (net/phonet/pep.c)
linux-6.1.y stable branch (confirmed via syzbot ext ID 44f0626dd6284f02663c)
Multiple upstream branches fixed across eight backported commits

Discovery Timeline

2026-07-19 - CVE-2026-64177 published to NVD
2026-07-19 - Last updated in NVD database

Technical Details for CVE-2026-64177

Vulnerability Analysis

The Linux networking receive path typically runs from softirq context. Protocols that take the socket lock may queue packets in the backlog for later processing from process context. During release_sock(), the kernel calls __release_sock(), which drops the socket lock with spin_unlock_bh() and then invokes sk->sk_backlog_rcv() with bottom halves enabled.

Most sk_backlog_rcv handlers process the socket whose backlog is being drained. The pep_do_rcv() handler behaves differently. When an inbound skb targets an existing PEP pipe, it forwards the skb to a different child socket via sk_receive_skb().

The sk_receive_skb() helper acquires the child socket lock using bh_lock_sock_nested(), which is a spin_lock_nested() call assuming BH is already disabled. This produces two conflicting acquisition paths for the same child slock.

Root Cause

The child socket lock is acquired in two inconsistent states. In the process context path, release_sock() on the listener drops the lock via spin_unlock_bh(), then calls pep_do_rcv() with BH enabled before entering sk_receive_skb() on the child. In the softirq context path, __netif_receive_skb() invokes phonet_rcv() and reaches the same code with BH already disabled. Lockdep detects the inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage on slock-AF_PHONET/1.

Attack Vector

A local user with permission to create Phonet sockets and PEP pipes can drive both code paths concurrently. Crafted packet reception combined with pep_sock_accept() operations can reach the vulnerable transition. The issue was discovered via in-house syzkaller fuzzing and reproduced under KASAN, LOCKDEP, and PROVE_LOCKING configurations. The patch wraps the forwarded sk_receive_skb() in local_bh_disable() and local_bh_enable() so the child slock is always acquired with BH off.

Detection Methods for CVE-2026-64177

Indicators of Compromise

Kernel log entries containing WARNING: inconsistent lock state referencing slock-AF_PHONET/1
Lockdep splats mentioning __sk_receive_skb, pep_do_rcv, or pep_sock_accept in the call trace
Soft lockup or watchdog messages on CPUs handling Phonet traffic
Unexpected kernel hangs when Phonet/PEP sockets are actively used

Detection Strategies

Enable CONFIG_PROVE_LOCKING and CONFIG_LOCKDEP in test environments to surface the inconsistent lock state before it deadlocks
Monitor dmesg and /var/log/kern.log for Phonet-related lockdep warnings
Audit running kernel versions against the fixed commits in net/phonet/pep.c
Track socket family usage to identify systems creating AF_PHONET sockets when the protocol is not required

Monitoring Recommendations

Forward kernel logs to a centralized SIEM for correlation across fleet nodes
Alert on repeated soft lockup or CPU stall events tied to network softirq handlers
Baseline expected Phonet usage since it is legacy telephony functionality rarely needed on server workloads
Track kernel package versions across the environment to confirm patch deployment

How to Mitigate CVE-2026-64177

Immediate Actions Required

Apply the upstream fix from the referenced kernel.org commits to affected branches
Update to a kernel release that includes the phonet/pep: disable BH around forwarded sk_receive_skb() patch
Disable or blacklist the phonet kernel module on systems that do not require the protocol
Restrict local user account creation and shell access to trusted principals only

Patch Information

The fix wraps the forwarded sk_receive_skb() call inside local_bh_disable() / local_bh_enable() so the child slock is always acquired with bottom halves off. local_bh_disable() nests safely on the softirq path. The patch is available across multiple stable branches via the following commits: Kernel Git Commit 02c04df, Kernel Git Commit 8420aa4, Kernel Git Commit 84bc87b, Kernel Git Commit a3fc8f2, Kernel Git Commit b2606c3, Kernel Git Commit bd795f1, Kernel Git Commit dbc8160, and Kernel Git Commit f08c450.

Workarounds

Blacklist the Phonet module by adding blacklist phonet to /etc/modprobe.d/blacklist-phonet.conf on systems that do not need the protocol
Remove or unload the phonet module at runtime with modprobe -r phonet where safe
Use seccomp or LSM policies to block socket(AF_PHONET, ...) calls for untrusted workloads
Limit local access on multi-tenant systems until the patched kernel is deployed

bash

# Configuration example
echo 'blacklist phonet' | sudo tee /etc/modprobe.d/blacklist-phonet.conf
sudo modprobe -r phonet 2>/dev/null || true
lsmod | grep phonet