CVE-2026-53157

What it actually does

This is a Linux kernel use-after-free in the Phonet networking subsystem. A phonet_device object is removed from a per-network-namespace device list using RCU list deletion, but the object is freed immediately instead of after an RCU grace period. Concurrent RCU readers can therefore continue to access freed kernel heap memory, causing memory corruption. The most likely impact is a kernel crash or denial of service; in some circumstances, a reliable exploit could potentially turn the kernel memory corruption into local privilege escalation.

Why it matters to the business

Systems running affected Linux kernels may be exposed to local kernel crashes and possible privilege escalation if the Phonet subsystem is enabled or reachable through installed kernel functionality. The current public exploitation signal is low: EPSS is 0.126%, it is not listed in CISA KEV, it is not associated with ransomware use, and no mature public exploit is indicated. Even so, kernel memory-corruption flaws should be prioritized on multi-user systems, container hosts, build runners, shared compute platforms, and systems where untrusted users can exercise network namespace or network device operations.

How an attack unfolds

An attacker first needs code execution or interactive access on a vulnerable Linux system, or access to a workload that can trigger the relevant Phonet networking code paths. The attacker then causes a Phonet device object to be removed while another kernel path is still traversing the same per-network device list under RCU. Because the object is freed immediately rather than after the RCU grace period, the reader can dereference stale kernel memory. A simple exploitation attempt may only panic the kernel, producing a denial of service. A more advanced exploit would attempt to shape kernel heap allocations so the freed object is replaced with attacker-influenced data before the stale pointer is reused, potentially allowing controlled memory corruption and privilege escalation. There is currently no indication that this issue is exploited in the wild or used by named threat actors.

How to fix it

Apply the Linux kernel update from the operating system or appliance vendor that includes the fix changing the phonet_device lifetime handling to use RCU-safe freeing. No product-specific fixed versions were provided in the input, so rely on the relevant distribution, kernel tree, or appliance advisory for exact package versions. If immediate patching is not possible, reduce exposure by disabling or avoiding use of the Phonet subsystem where feasible, removing unused kernel modules if the platform supports doing so, restricting untrusted local shell access, limiting container privileges, disabling untrusted creation of network namespaces where operationally acceptable, and preventing untrusted workloads from performing network device administration. Reboot into the patched kernel after installation; installing kernel packages without rebooting usually does not remove exposure.

How to confirm the fix worked

Confirm the running kernel, not merely the installed kernel package, has been updated to a build containing the RCU-safe phonet_device fix. Use vendor advisories, changelogs, or source package references to verify the patch is present. Check whether Phonet support is enabled using kernel configuration sources such as /boot/config-$(uname -r) or /proc/config.gz for CONFIG_PHONET. Review whether the phonet module is loaded, if built as a module, and whether the environment permits untrusted users or containers to create network namespaces or administer network devices. After remediation, reboot and confirm uname -r reports the intended patched kernel. For high-assurance validation, run vendor-provided regression tests or inspect the kernel source/build metadata for use of kfree_rcu() in the affected Phonet device destruction path.

Typical attack path

1. Gain local code execution, shell access, or control of a workload on a vulnerable Linux system.
2. Determine whether the kernel includes the Phonet subsystem and whether relevant network namespace or device-management operations are permitted.
3. Trigger Phonet device creation, deletion, or address/device lifecycle activity while concurrent readers traverse the Phonet per-network device list.
4. Race the immediate free of the phonet_device object against RCU readers that may still hold a pointer to it.
5. Cause a kernel oops or panic for denial of service, or attempt heap grooming to turn the use-after-free into controlled kernel memory corruption.
6. If successful beyond denial of service, escalate privileges or execute code in kernel context.

How to detect it

To assess possible prior exploitation, review kernel logs and crash artifacts for slab use-after-free, general protection faults, kernel oopses, panics, or KASAN reports mentioning Phonet, phonet_device, RCU list traversal, or net/phonet code paths. Relevant sources include journald, syslog, kern.log, dmesg archives, crash dumps, kdump/vmcore files, hypervisor reset records, and endpoint telemetry that records kernel panics or abnormal reboots. Correlate crashes with local user sessions, container starts, namespace creation, network device administration, or unusual activity by workloads granted elevated network capabilities. Also review audit logs for repeated use of privileged network administration tooling by non-administrative users or untrusted workloads. Absence of these artifacts does not prove non-exploitation, because successful kernel exploitation may leave minimal logs, but repeated kernel memory faults around Phonet are suspicious.

• BUG: KASAN: slab-use-after-free
• slab-use-after-free
• use-after-free in phonet
• phonet_device_destroy
• phonet_device
• net/phonet
• Phonet
• CONFIG_PHONET
• AF_PHONET
• PF_PHONET
• general protection fault
• kernel BUG
• Oops:
• Kernel panic
• RCU
• list_del_rcu

What your security team should do

• Prioritize patching shared, multi-user, container-hosting, CI/CD, research, and internet-facing management systems where local privilege escalation or host denial of service would have high impact.
• Track the relevant Linux distribution or appliance vendor advisory for exact fixed kernel package versions and ensure systems are rebooted into the fixed kernel.
• Inventory systems with CONFIG_PHONET enabled or the phonet module available, and treat those as the primary exposure set.
• Where patching is delayed, restrict untrusted local access, privileged containers, CAP_NET_ADMIN-like capabilities, and untrusted network namespace creation where feasible.
• Monitor kernel logs for use-after-free, slab corruption, kernel oops, or panic events involving Phonet, especially on systems with untrusted local workloads.
• Because EPSS is currently low and there is no KEV listing or known mature exploit, schedule remediation according to kernel memory-corruption risk, but escalate if exploit code, weaponization, or vendor severity guidance changes.