CVE-2026-46118
Received Received - Intake
Null Pointer Dereference in Linux Kernel pseries/papr-hvpipe

Publication date: 2026-05-28

Last updated on: 2026-05-28

Assigner: kernel.org

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.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2026-05-28
Last Modified
2026-05-28
Generated
2026-05-28
AI Q&A
2026-05-28
EPSS Evaluated
N/A
NVD
EUVD
Affected Vendors & Products
Showing 1 associated CPE
Vendor Product Version / Range
linux linux_kernel *
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-UNKNOWN
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

This vulnerability is a null pointer dereference in the Linux kernel's pseries/papr-hvpipe component, specifically in the function papr_hvpipe_dev_create_handle().

A recent code change converted papr_hvpipe_dev_create_handle() to use FD_PREPARE(), but this caused a kernel null pointer dereference because after calling retain_and_null_ptr(src_info), the src_info pointer was reused incorrectly when adding it to a global list.

This leads to a kernel panic when the kernel tries to add src_info to the list, resulting in a crash due to a null pointer dereference.


How can this vulnerability impact me? :

This vulnerability can cause a kernel panic, which means the Linux system could crash unexpectedly.

Such crashes can lead to denial of service, making the system unavailable until it is rebooted.

Additionally, the kernel log shows an attempted write to a user page at address 0, which may indicate an exploit attempt.


How can this vulnerability be detected on my network or system? Can you suggest some commands?

This vulnerability manifests as a kernel panic caused by a NULL pointer dereference in the papr_hvpipe_dev_create_handle() function. Detection involves monitoring system logs for kernel panic messages related to papr_hvpipe and NULL pointer dereferences.

  • Check kernel logs for messages like 'BUG: Kernel NULL pointer dereference on write at 0x00000000' or 'Kernel attempted to write user page (0) - exploit attempt? (uid: 0)'.
  • Use the command: dmesg | grep -i 'papr_hvpipe' to filter relevant kernel panic traces.
  • Monitor system logs (e.g., /var/log/kern.log or /var/log/messages) for similar error patterns.

What immediate steps should I take to mitigate this vulnerability?

Immediate mitigation involves updating the Linux kernel to a version that includes the fix for this vulnerability, which addresses the null pointer dereference in papr_hvpipe_dev_create_handle() by properly handling FD_PREPARE and error cleanup.

Until the update can be applied, avoid using the papr_hvpipe interface or related functionality that triggers the vulnerable code path to prevent kernel panics.


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart