CVE-2026-64177

What it actually does

This is a Linux kernel race/locking flaw in the Phonet PEP receive path. When queued socket backlog is drained from process context, bottom halves can be enabled while pep_do_rcv() forwards a packet to a child socket through sk_receive_skb(). The child socket lock may then be acquired once with bottom halves enabled and elsewhere from softirq context with bottom halves disabled, creating inconsistent locking and a possible same-CPU self-deadlock. The practical technical impact is kernel lockup or denial of service in systems with the affected Phonet/PEP code enabled and reachable by an attacker able to exercise that protocol path.

Why it matters to the business

Successful exploitation can hang or destabilize affected Linux systems, causing service outages, failed workloads, or node reboots if watchdogs or cluster health checks intervene. The risk is lower than many remotely exploitable kernel bugs because public exploit maturity is listed as none, EPSS is low, it is not in CISA KEV, and Phonet is uncommon in many server deployments; however, organizations using kernels with Phonet enabled should still treat it as an availability risk, especially for appliances, embedded Linux, telecom, modem-related, or custom kernel environments.

How an attack unfolds

An attacker first needs access to a path that can generate or influence Phonet PEP socket traffic on an affected kernel. They then cause traffic to be queued on a listener socket so that backlog processing happens later from process context, such as during accept or socket release handling. During backlog drain, pep_do_rcv() forwards an inbound skb to an existing child PEP socket. Because bottom halves are enabled on this path, sk_receive_skb() takes the child socket lock in a state that conflicts with the normal softirq receive path. If a softirq on the same CPU concurrently attempts to receive to the same child socket while that lock is held, the kernel can self-deadlock. The likely attacker outcome is denial of service rather than privilege escalation or data theft.

How to fix it

Apply the vendor kernel update that includes the fix for net/phonet/pep.c, where the forwarded sk_receive_skb() call is wrapped with local_bh_disable() and local_bh_enable(). If no fixed package version is listed by the platform vendor, track the relevant distribution, appliance, or kernel-stable advisory and upgrade to the first kernel build containing this patch. As interim mitigation, disable or remove Phonet support where it is not required, avoid loading Phonet-related modules, build kernels without CONFIG_PHONET where feasible, and restrict untrusted local users or containers from accessing uncommon networking protocol families if platform controls allow it. For embedded or custom kernels, backport the upstream patch and rebuild, then deploy through the normal kernel rollout process.

How to confirm the fix worked

Confirm the running kernel is a vendor-fixed build or that the source tree contains the Phonet PEP change adding local_bh_disable()/local_bh_enable() around the forwarded sk_receive_skb() call in net/phonet/pep.c. Verify whether Phonet support is present by checking kernel configuration for CONFIG_PHONET and whether Phonet-related modules are loaded. After patching, reboot into the fixed kernel and confirm the active kernel version matches the updated package, not only the installed package. In non-production only, regression testing may include reproducing the previously reported syzkaller-style workload and confirming that LOCKDEP no longer reports inconsistent SOFTIRQ lock state for AF_PHONET socket locks.

Typical attack path

1. Identify or reach a Linux system running an affected kernel with Phonet/PEP support enabled.
2. Create or interact with AF_PHONET/PEP sockets, or otherwise deliver traffic that exercises the Phonet PEP receive path.
3. Cause packets to be stored in a listener socket backlog and later processed from process context.
4. Trigger forwarding from pep_do_rcv() to a child socket via sk_receive_skb().
5. Race that path with softirq receive processing for the same child socket on the same CPU.
6. Induce inconsistent socket-lock state and potentially deadlock the kernel, causing a hang or service outage.

How to detect it

This flaw is primarily a denial-of-service race condition, so post-exploitation evidence is likely to appear as kernel warnings, lockdep reports, soft lockups, hung tasks, watchdog resets, or unexplained reboots rather than files written to disk or persistent artifacts. Review kernel logs from journald, dmesg, syslog, crash dumps, netconsole, serial console output, and centralized log collectors for AF_PHONET, PEP, socket-lock, and SOFTIRQ lock-state messages. Look for stack traces involving pep_do_rcv(), sk_receive_skb(), __sk_receive_skb(), __release_sock(), release_sock(), and pep_sock_accept(). Correlate any such events with system hangs, watchdog reboots, local user activity, container workloads, modem/telephony services, or unusual Phonet socket activity. Absence of these logs does not prove non-exploitation because a hard deadlock may prevent log flushing.

• WARNING: inconsistent lock state
• inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage
• slock-AF_PHONET
• __sk_receive_skb
• sk_receive_skb
• pep_do_rcv
• pep_sock_accept
• __release_sock
• release_sock
• net/phonet/pep.c
• SOFTIRQ-ON-W
• IN-SOFTIRQ-W
• BUG: soft lockup
• INFO: task hung
• kernel watchdog

What your security team should do

• Prioritize patching systems that use custom kernels, telecom/modem functionality, embedded Linux networking, or have Phonet enabled.
• Inventory Linux kernels for CONFIG_PHONET support and loaded Phonet-related modules; deprioritize systems where the code is not built or cannot be reached.
• Apply vendor kernel updates and reboot affected systems into the fixed kernel.
• Where patching is delayed, disable Phonet support or prevent module loading if the protocol is not operationally required.
• Monitor kernel logs for lockdep, soft lockup, hung task, or AF_PHONET-related warnings until the fleet is remediated.
• Because this is not KEV-listed, has low EPSS, and has no known mature exploit, handle it as an availability hardening issue unless Phonet is exposed in a high-criticality environment.