CVE-2026-46298

What it actually does

This is a race condition in the Linux kernel pseries/papr-hvpipe driver. The vulnerable ioctl and release handlers can acquire a lock without disabling local interrupts; if an interrupt handler runs on the same CPU and attempts to take the same lock, the CPU can deadlock. The practical technical impact is a local denial of service affecting systems that include and use the affected pSeries/PAPR hypervisor pipe functionality, most relevant to PowerPC pSeries/PowerVM-style environments.

Why it matters to the business

Successful exploitation can cause affected Linux systems to hang, become unresponsive, or require a reboot, leading to workload disruption and possible service outage. The risk is narrower than many remote vulnerabilities because exploitation requires local access to the vulnerable kernel interface and relevant hardware/virtualization support. EPSS is very low and the issue is not listed in CISA KEV, so it should be prioritized as a stability and availability patch rather than an active mass-exploitation emergency.

How an attack unfolds

An attacker who already has local ability to interact with the affected papr-hvpipe kernel interface triggers code paths such as ioctl or device close/release while the system is handling interrupts on the same CPU. Because the vulnerable code takes a spin lock without masking interrupts, the interrupt handler may attempt to acquire the same lock while it is already held. This causes the CPU to wait indefinitely, potentially resulting in a kernel hang, soft lockup, or broader system unavailability. There is no indication from the provided data of public exploit maturity, known ransomware use, or exploitation by named threat actors.

How to fix it

Upgrade to a Linux kernel version that includes the fix for the pseries/papr-hvpipe locking race. The corrected code uses spin_lock_irqsave/spin_unlock_irqrestore or equivalent interrupt-safe locking in the ioctl and release handlers. Because no exact fixed package versions were provided, obtain the patched kernel from the relevant Linux distribution, vendor advisory, or upstream stable kernel branch for the deployed platform. Where immediate patching is not possible, reduce exposure by limiting local shell access, restricting access to the affected device/interface, disabling or avoiding use of the papr-hvpipe functionality if operationally feasible, and monitoring for lockup symptoms. A reboot is required after kernel package replacement for the fix to take effect unless a validated live-patching mechanism covers this specific change.

How to confirm the fix worked

Confirm the running kernel, not just the installed package, includes the vendor fix. Validate by checking distribution security advisories and package changelogs for CVE-2026-46298 or the pseries/papr-hvpipe interrupt-safe locking fix. On Linux, compare `uname -r` against the vendor-fixed kernel version and confirm the host has rebooted into the patched kernel. For source-based or custom kernels, inspect the papr-hvpipe driver code to verify ioctl and release paths use interrupt-safe spin-lock functions. Also confirm whether the platform actually exposes pSeries/PAPR hypervisor pipe functionality; systems that do not include or use this driver are not practically exposed.

Typical attack path

1. Gain local execution or access to an account/process that can interact with the affected pseries/papr-hvpipe device or kernel interface.
2. Identify that the host is running a vulnerable Linux kernel build on a relevant pSeries/PAPR environment.
3. Repeatedly invoke vulnerable ioctl and/or close/release paths against the papr-hvpipe interface.
4. Attempt to win the race where an interrupt fires on the same CPU while the vulnerable lock is held.
5. Cause a CPU deadlock, soft lockup, kernel hang, or service disruption requiring administrative recovery or reboot.

How to detect it

Look for evidence of kernel hangs or soft lockups on systems that support pSeries/PAPR hypervisor pipe functionality. Relevant log sources include kernel ring buffer output, journald kernel logs, syslog, crash dumps, kdump/vmcore artifacts, hypervisor or virtualization management logs, and endpoint telemetry for local processes repeatedly opening or issuing ioctl calls to the affected interface. Search for lockup, hung task, watchdog, and call-trace messages near references to papr-hvpipe or pseries. Because this issue causes availability failure rather than a clean post-exploitation artifact, detection is symptom-based: correlate unresponsive hosts, forced reboots, watchdog resets, or kernel panic/crash evidence with local user activity or processes accessing papr-hvpipe immediately beforehand. There are no known threat actors, KEV listing, ransomware association, or public exploit maturity in the provided data.

• papr-hvpipe
• pseries/papr-hvpipe
• NMI watchdog: BUG: soft lockup
• BUG: soft lockup
• watchdog: BUG: soft lockup
• INFO: task
• blocked for more than
• hung_task
• rcu_sched detected stalls
• rcu: INFO: rcu_sched self-detected stall
• kernel: Call Trace:
• spin_lock
• ioctl
• release

What your security team should do

• Inventory Linux systems running on PowerPC pSeries, PowerVM, or PAPR-related virtualization platforms where the papr-hvpipe driver may be present.
• Prioritize kernel updates for affected availability-sensitive systems, especially shared hosts or systems where untrusted local users or workloads can run code.
• Verify patched kernels are both installed and active after reboot or validated live patching.
• Restrict local access and device permissions for interfaces associated with papr-hvpipe until patching is complete.
• Monitor for kernel soft lockups, hung tasks, unexpected reboots, and logs referencing papr-hvpipe on potentially affected systems.
• Treat exploitation as a local denial-of-service scenario; investigate any suspicious local process activity that coincides with kernel lockups.
• Track vendor advisories for exact fixed kernel package versions because none were provided in the input data.