CVE-2026-46118

What it actually does

This is a local Linux kernel denial-of-service vulnerability in the pseries/papr-hvpipe subsystem. A logic error introduced during conversion of papr_hvpipe_dev_create_handle() to FD_PREPARE() can cause src_info to be nulled and then reused when adding it to a global list, leading to a NULL pointer dereference in kernel context. A local privileged or partially privileged user able to reach the affected papr_hvpipe ioctl path can trigger a kernel oops/panic, resulting in loss of system availability. The published CVSS vector indicates local attack access, low complexity, low privileges required, no user interaction, no confidentiality or integrity impact, and high availability impact.

Why it matters to the business

Successful exploitation can crash affected Linux systems, interrupting workloads, virtualized services, or Power/pSeries environments that rely on the affected kernel functionality. Because the flaw requires local access and has very low EPSS, broad internet-scale exploitation is unlikely, but systems that allow untrusted shell access, containerized workloads with access to relevant device interfaces, or multi-user compute environments have higher operational risk. It is not currently listed in CISA KEV and is not known to be used in ransomware campaigns, so remediation should be prioritized based on exposure of affected pseries/PAPR hvpipe functionality and availability requirements rather than emergency internet-facing risk.

How an attack unfolds

An attacker first obtains local access to an affected Linux host with sufficient privilege to invoke the vulnerable papr_hvpipe device ioctl path. They then issue a crafted or repeated create-handle operation that exercises papr_hvpipe_dev_create_handle(). Due to the flawed FD_PREPARE-related error-handling sequence, the kernel retains and nulls the src_info pointer and subsequently attempts to reuse it when adding the handle metadata to a global list. This causes a write through a NULL pointer, producing a kernel oops or panic. The likely result is immediate denial of service through system crash or instability rather than code execution or data theft.

How to fix it

Upgrade to a Linux kernel build that includes the upstream fix for the pseries/papr-hvpipe NULL pointer dereference in papr_hvpipe_dev_create_handle(). Because fixed package versions were not provided, use your Linux distribution vendor’s advisory and kernel changelog to identify the first patched kernel for CVE-2026-46118 or the referenced papr_hvpipe fix. Prioritize systems running on IBM Power/pSeries or environments where PAPR hypervisor pipe functionality is present. If immediate patching is not possible, reduce exposure by restricting local shell access, limiting access to relevant device nodes and ioctl-capable interfaces, applying least-privilege controls to users and containers, and disabling unused pseries/PAPR hvpipe functionality where operationally safe. Plan a reboot after kernel update where required for the patched kernel to take effect.

How to confirm the fix worked

Confirm the running kernel has been updated, not just installed, by checking the active kernel version after reboot and comparing it with the vendor-fixed version. Review distribution security advisories or package changelogs for the papr-hvpipe fix affecting papr_hvpipe_dev_create_handle(). Validate exposure by determining whether the affected pseries/PAPR hvpipe driver or device interface is present and accessible on the host. Where safe in a non-production test environment, reproduce the previously crashing ioctl workflow and confirm it no longer causes an oops or panic. Also verify that local users and containers cannot access unnecessary hvpipe-related device nodes.

Typical attack path

1. Gain local access to an affected Linux system, or compromise a workload/user context that can reach the affected kernel interface.
2. Identify that the host is running a vulnerable kernel with pseries/PAPR hvpipe support enabled and accessible.
3. Open the relevant hvpipe device or interface and invoke the ioctl path that creates a handle.
4. Trigger the flawed papr_hvpipe_dev_create_handle() sequence so src_info is nulled and then reused.
5. Cause a kernel NULL pointer dereference, resulting in an oops, panic, reboot, or service outage.

How to detect it

Look for evidence of kernel crashes or attempted triggering in kernel and system logs. Relevant sources include dmesg, journald, /var/log/kern.log, /var/log/messages, crash dumps, kdump/vmcore records, hypervisor management logs, and EDR telemetry for unusual local processes repeatedly opening hvpipe-related devices or invoking ioctl calls shortly before a crash. Search for kernel oops/panic messages containing papr_hvpipe_dev_create_handle(), papr_hvpipe_dev_ioctl(), NULL pointer dereference, write to address 0x00000000, or the phrase 'Kernel attempted to write user page (0) - exploit attempt?'. Correlate these messages with local login/session history, sudo activity, container activity, and process execution around the crash time. Since no public exploit indicators or malware-specific artifacts are known, detection should focus on crash signatures and anomalous local access to the affected kernel interface.

• papr_hvpipe_dev_create_handle
• papr_hvpipe_dev_ioctl
• Kernel NULL pointer dereference on write at 0x00000000
• Kernel attempted to write user page (0) - exploit attempt?
• BUG: Kernel NULL pointer dereference
• Kernel access of bad area
• Faulting instruction address: 0xc0000000001b44a0
• sys_ioctl
• system_call_exception
• system_call_vectored_common
• papr-hvpipe
• hvpipe

What your security team should do

• Inventory Linux systems running on Power/pSeries or with pseries/PAPR hvpipe support and identify vulnerable kernel versions.
• Apply vendor kernel updates that include the papr_hvpipe_dev_create_handle() fix, then reboot into the patched kernel.
• Prioritize multi-user, shared compute, virtualization, and high-availability systems where a local denial of service would have material operational impact.
• Restrict access to relevant device nodes and ioctl-capable interfaces until patching is complete, especially from untrusted local users or containers.
• Monitor kernel logs for NULL pointer dereference, oops, or panic messages referencing papr_hvpipe_dev_create_handle, papr_hvpipe_dev_ioctl, or hvpipe.
• Because this is not KEV-listed, has low EPSS, and has no known exploit maturity, handle it through normal kernel vulnerability management unless affected systems are exposed to untrusted local users.