CVE-2026-46007

What it actually does

This is a local availability vulnerability in the Linux kernel hwmon powerz driver. The driver used a DMA transfer buffer that, on some CPU architectures, could share a cache line with an adjacent mutex. Because DMA can modify memory independently of CPU cache coherency expectations, this cacheline sharing can corrupt adjacent kernel state or cause unsafe synchronization behavior. A local attacker with the ability to interact with the affected hardware/driver path could trigger kernel instability, crashes, or hangs, resulting in denial of service. The issue is not known to provide confidentiality or integrity impact, and no public exploit maturity is currently reported.

Why it matters to the business

Systems running affected Linux kernels with the vulnerable powerz hardware-monitoring driver exposed may be susceptible to local crashes or service outages. The practical risk is highest for multi-user systems, shared workstations, lab/embedded devices, appliance-style Linux deployments, or environments where untrusted users can access hardware monitoring interfaces. There is no CISA KEV listing, no known ransomware association, and EPSS is very low, so broad internet-scale exploitation is unlikely; however, kernel availability flaws can still cause operational disruption where local access is possible.

How an attack unfolds

An attacker first needs local access to a system running an affected Linux kernel and a reachable code path for the hwmon powerz driver. The attacker interacts with the device or driver interface in a way that causes DMA transfers to use the vulnerable buffer. On architectures where the DMA buffer shares a cache line with the following mutex, the DMA activity can interfere with adjacent kernel memory or synchronization state. This can lead to kernel warnings, deadlocks, memory corruption symptoms, a panic, or a system hang. Successful exploitation is expected to result in denial of service rather than data theft or privilege escalation based on the available vulnerability details.

How to fix it

Upgrade to a Linux kernel build that includes the upstream fix for the hwmon powerz DMA buffer allocation issue. Because no exact fixed versions were provided, use distribution vendor advisories and kernel changelogs to identify a patched kernel containing the change that uses high-level DMA helpers to prevent cacheline sharing for the powerz transfer buffer. If immediate patching is not possible, reduce exposure by unloading or blacklisting the affected powerz driver where it is not required, restricting local user access to hardware-monitoring device nodes and USB/device interfaces, and limiting shell access on systems where the driver is used. Reboot into the patched kernel after installation; merely installing kernel packages is not sufficient if the running kernel is unchanged.

How to confirm the fix worked

Confirm the running kernel version is a vendor-supported build that includes the fix, not only that a patched package is installed. Check whether the powerz driver is present or loaded using standard module and kernel configuration inspection tools, and verify whether supported hardware is attached. Review vendor kernel advisories, package changelogs, or source patches for the hwmon powerz change that prevents DMA buffer cacheline sharing. After remediation, perform a controlled reboot and confirm the running kernel matches the patched version. Where the driver was mitigated instead of patched, verify it is not loaded after reboot and cannot be auto-loaded by normal device attachment.

Typical attack path

1. Obtain local, low-privileged access to a Linux system running an affected kernel.
2. Determine whether the hwmon powerz driver is present, loaded, or reachable through attached supported hardware.
3. Interact with the exposed device or driver interface to trigger DMA transfers through the vulnerable buffer handling path.
4. Cause cacheline-sharing side effects between the DMA buffer and adjacent mutex on susceptible architectures.
5. Induce kernel instability such as a panic, hang, or crash, causing denial of service.

How to detect it

There are no public, specific exploitation indicators for this vulnerability. Detection should focus on evidence of local triggering and resulting kernel instability. Review kernel logs from journald, syslog, dmesg, crash dumps, and remote logging platforms for events involving the powerz hwmon driver, DMA mapping or coherency warnings, mutex corruption, kernel oopses, panics, soft lockups, hard lockups, or unexplained reboots. Correlate these events with local user sessions, recent device attachment, access to hardware-monitoring interfaces, and command execution around the time of the crash. On systems with crash dumping enabled, inspect vmcore or kdump artifacts for stack traces involving the powerz driver or hwmon subsystem. Because the expected impact is denial of service, absence of file-based malware artifacts does not rule out exploitation; the strongest signals are repeated, user-correlated kernel crashes on systems where the affected driver is reachable.

What your security team should do

• Prioritize patching affected Linux systems where local users, shared access, hardware labs, embedded deployments, or appliance workloads can reach the hwmon powerz driver.
• Confirm whether the powerz driver is enabled, loaded, or present in deployed kernel configurations; systems without the driver or relevant hardware have materially lower exposure.
• If patching must be delayed, blacklist or unload the powerz driver where operationally safe and restrict access to related device interfaces.
• Monitor kernel logs for crashes, hangs, DMA-related warnings, mutex corruption symptoms, or repeated hardware-monitoring driver failures on systems using the driver.
• Track distribution-specific advisories for exact fixed kernel package versions, since fixed versions were not provided in the input.
• Treat unexplained local kernel panics on systems with this driver as potential exploitation or fault-triggering events and preserve logs before reboot cycles overwrite evidence.