CVE-2026-64234

What it actually does

This is a Linux kernel denial-of-service flaw in the pch_uart serial driver. The driver could fail to check whether dma_alloc_coherent() returned NULL, then later dereference the missing DMA buffer in dma_handle_rx(). Under memory pressure or DMA allocation failure conditions, use of the affected UART path can trigger a kernel NULL pointer dereference, causing an oops, driver crash, or potentially a system panic depending on kernel configuration.

Why it matters to the business

Systems using the affected Linux kernel driver for PCH UART/PCI serial hardware may experience unexpected crashes or loss of serial communication availability. The likely operational impact is service interruption rather than data theft or privilege escalation. EPSS is low, it is not listed in CISA KEV, and no public exploit maturity is reported, so urgency is lower than for actively exploited remote code execution issues, but kernel availability bugs should still be addressed through normal patch cycles, especially on appliances, embedded systems, industrial systems, or servers that depend on serial interfaces.

How an attack unfolds

An attacker would need a path to exercise the affected pch_uart driver while the kernel encounters a DMA coherent memory allocation failure. In a plausible scenario, a local user, workload, or attached serial/PCI device interaction contributes to memory pressure or otherwise causes dma_alloc_coherent() to fail during driver setup or operation. Because the vulnerable code did not correctly handle the failed allocation, later receive-side DMA handling can dereference a NULL buffer pointer in dma_handle_rx(). The result is typically a kernel oops or panic, producing a denial of service. There is no indication from the supplied intelligence that this vulnerability is being used in ransomware campaigns, is in CISA KEV, or has mature public exploit code.

How to fix it

Upgrade to a Linux kernel build that includes the pch_uart fix adding proper dma_alloc_coherent() failure handling and cleanup of DMA channels and PCI device references. Because no exact fixed package versions were provided, use the fixed kernel packages from the relevant Linux distribution, appliance vendor, or kernel stable branch. If immediate patching is not possible, reduce exposure by disabling or blacklisting the pch_uart driver where it is not required, removing access to affected serial hardware, limiting untrusted local workloads on systems that use this hardware, and ensuring kernel panic-on-oops behavior is configured according to availability requirements. Reboot into the patched kernel after installation; installing a kernel package alone is not sufficient if the running kernel is still vulnerable.

How to confirm the fix worked

Confirm the running kernel, not just the installed kernel package, contains the fix. Validate using distribution advisory tooling, package changelogs, or source inspection for the pch_uart change that checks dma_alloc_coherent() failure and unwinds resources via a cleanup path. Check whether the pch_uart module is present or loaded using commands such as lsmod, modinfo pch_uart, and inspection of /sys/bus/pci/drivers/. Review dmesg or journal logs after reboot to ensure the updated kernel is active and there are no recurring pch_uart, DMA allocation, NULL pointer dereference, oops, or panic messages. Where feasible, test serial functionality under the patched kernel to confirm expected device behavior remains intact.

Typical attack path

1. Identify a Linux system running a vulnerable kernel with the pch_uart serial driver enabled and relevant PCH UART/PCI serial hardware present.
2. Obtain local access, workload placement, device access, or another means to exercise the affected UART receive path.
3. Create or wait for conditions where dma_alloc_coherent() fails, such as constrained memory/DMA allocation pressure.
4. Trigger receive-side UART activity that reaches dma_handle_rx() after the failed DMA allocation.
5. Cause a kernel NULL pointer dereference, leading to an oops, panic, driver failure, or system availability loss.

How to detect it

To determine whether this issue may have already been triggered, review kernel logs and crash artifacts rather than application logs. Relevant sources include dmesg, journalctl -k, /var/log/kern.log, /var/log/messages, /var/log/syslog, netconsole output, crash dump directories such as /var/crash, kdump/vmcore storage, and monitoring alerts for unexpected reboots or kernel panics. Look for NULL pointer dereference, kernel oops, panic, or general protection fault messages involving pch_uart, dma_handle_rx(), dma_alloc_coherent(), serial receive DMA, or PCI serial device initialization. Correlate events with memory pressure indicators, OOM activity, serial device activity, module load/unload events, and unexplained service interruptions. Because the known impact is denial of service and no public exploitation is indicated, absence of these kernel-level artifacts generally means there is no evidence of exploitation from standard logs.

• pch_uart
• dma_handle_rx
• dma_alloc_coherent
• NULL pointer dereference
• BUG: kernel NULL pointer dereference
• Oops:
• Kernel panic
• general protection fault
• /var/log/kern.log
• /var/log/messages
• /var/log/syslog
• /var/crash
• vmcore
• modprobe pch_uart
• pch_uart.ko

What your security team should do

• Prioritize inventory: identify Linux systems with the pch_uart driver available or loaded and systems with PCH UART/PCI serial hardware.
• Patch affected systems through the normal kernel update process, prioritizing high-availability systems, embedded/appliance deployments, and systems that rely on serial connectivity.
• Reboot into the fixed kernel and verify the running kernel version and vendor advisory status.
• If patching is delayed, disable or blacklist pch_uart on systems that do not require it.
• Monitor kernel logs for pch_uart-related oops, panic, NULL pointer dereference, or DMA allocation failure messages.
• Treat unexplained crashes on systems using this driver as potential exploitation or reliability events and preserve kernel logs, crash dumps, and vmcore artifacts for analysis.
• Because this is not currently KEV-listed, not associated with ransomware, and has low EPSS, handle as a controlled availability-risk remediation rather than an emergency internet-exposed compromise scenario.