CVE-2026-46182

What it actually does

This Linux kernel flaw is an information disclosure issue in the pseries PAPR hypervisor pipe handling code. A stack-allocated papr_hvpipe_hdr structure was partially initialized before being copied to user space, leaving reserved padding bytes potentially containing uninitialized kernel stack data. A local user with access to the affected interface could trigger the vulnerable path and receive small fragments of kernel memory. While the leak appears limited in size and scope, kernel memory disclosure can sometimes help defeat exploit mitigations or expose sensitive runtime state. The supplied CVSS vector indicates local access with low attack complexity and low privileges required.

Why it matters to the business

Organizations running affected Linux kernels on impacted pseries/PAPR environments may have a local information exposure risk. The direct operational impact is likely limited compared with remotely exploitable vulnerabilities, because exploitation requires local access, but it can still matter on multi-user systems, shared compute platforms, virtualization hosts, or environments where untrusted users or workloads can interact with kernel interfaces. There is no current CISA KEV listing, no ransomware association, and the provided EPSS score is very low, so this should generally be handled through normal kernel patching cycles unless affected systems host untrusted local users or workloads.

How an attack unfolds

An attacker first needs local access to a system running an affected Linux kernel with the vulnerable pseries/PAPR hypervisor pipe functionality available. The attacker then invokes the relevant kernel interface in a way that causes the kernel to prepare a papr_hvpipe_hdr structure on the stack. Because only selected fields are initialized and the reserved padding fields are not cleared, the kernel may copy those uninitialized bytes back to user space. The attacker repeatedly triggers the operation and collects returned data, attempting to reconstruct useful kernel stack fragments. The vulnerability does not by itself provide remote code execution or privilege escalation, but leaked kernel memory may be useful as a supporting primitive in a larger local exploit chain.

How to fix it

Apply a Linux kernel update that includes the fix for the pseries/papr-hvpipe stack initialization issue. The corrective change initializes the entire papr_hvpipe_hdr structure to zero before it is copied to user space, preventing reserved padding bytes from leaking stack data. No exact fixed package versions were provided in the input, so use the fixed kernel versions published by the relevant Linux distribution, hardware vendor, or kernel stable branch. Where immediate patching is not possible, reduce exposure by limiting local shell access, restricting untrusted users and workloads on affected systems, applying least privilege controls, and monitoring access to pseries/PAPR-related device or kernel interfaces. Reboot into the patched kernel after installation; installing kernel packages without rebooting generally does not remove exposure from the running kernel.

How to confirm the fix worked

Confirm that the running kernel, not just the installed kernel package, has been updated to a version containing the fix. Validate with distribution package metadata, kernel changelogs, vendor advisories, or source-level confirmation that the pseries/papr-hvpipe change zero-initializes the full papr_hvpipe_hdr structure before copy_to_user(). Check the active kernel version with standard system commands and confirm the host has been rebooted into the patched kernel. For source-based validation, inspect the affected code path and verify the header structure is initialized to zero, for example by declaration with a zero initializer or equivalent memset before field assignment and user-space copy. Exposure is most relevant on Linux systems using affected pseries/PAPR functionality; systems without that code path available are less likely to be practically exploitable.

Typical attack path

1. Obtain local access to an affected Linux system, such as a shell, user account, compromised service account, or untrusted workload execution context.
2. Determine whether the system is running an affected kernel and whether the pseries/PAPR hypervisor pipe interface is present and reachable.
3. Invoke the vulnerable interface repeatedly to cause the kernel to copy a partially initialized papr_hvpipe_hdr structure to user space.
4. Collect the returned data and inspect the reserved padding bytes for leaked kernel stack contents.
5. Use any recovered kernel memory fragments for reconnaissance or as part of a broader local exploitation chain.

How to detect it

Detecting prior exploitation is difficult because this class of kernel information disclosure may not generate explicit security logs, crashes, or persistent artifacts. Focus on systems where untrusted local users or workloads had access before patching. Review auditd, shell history, process accounting, EDR telemetry, and command execution logs for unusual binaries or scripts repeatedly interacting with pseries/PAPR hypervisor pipe interfaces. If device-node auditing is enabled, look for repeated open, read, write, or ioctl activity against PAPR hypervisor pipe-related paths. Review kernel logs for unusual pseries, PAPR, or hvpipe messages, although successful exploitation may be silent. Investigate suspicious local compilation, fuzzing tools, proof-of-concept execution, or repeated low-level system call activity by non-administrative users. Because no public exploit maturity is indicated and no threat actors are provided, detection should be based on anomalous local behavior rather than known campaign indicators.

• papr_hvpipe
• papr-hvpipe
• pseries/papr-hvpipe
• /dev/papr-hvpipe
• copy_to_user
• papr_hvpipe_hdr

What your security team should do

• Prioritize patching affected Linux kernels on pseries/PAPR systems that support multiple local users, shared workloads, or untrusted code execution.
• Confirm systems have rebooted into the patched kernel after updates are installed.
• Inventory pseries/PAPR Linux deployments and map them to distribution advisories or kernel stable fixes for this issue.
• Restrict local access to affected systems until patched, especially for non-administrative users and untrusted workloads.
• Review whether affected hosts are part of shared compute, virtualization, or high-sensitivity environments where small kernel memory disclosures could aid further exploitation.
• Monitor for unusual local enumeration or repeated access to PAPR hypervisor pipe interfaces, recognizing that exploitation may leave minimal or no default logs.
• Treat this as lower urgency than remotely exploitable or KEV-listed issues, but do not ignore it on multi-tenant or high-assurance systems.