GHSA-G7GX-Q434-9VPG
Vulnerability from github – Published: 2026-05-28 12:30 – Updated: 2026-05-28 12:30In 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.
{
"affected": [],
"aliases": [
"CVE-2026-46118"
],
"database_specific": {
"cwe_ids": [],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-05-28T10:16:27Z",
"severity": null
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\npseries/papr-hvpipe: Fix null ptr deref in papr_hvpipe_dev_create_handle()\n\ncommit 6d3789d347a7 (\"papr-hvpipe: convert papr_hvpipe_dev_create_handle() to FD_PREPARE()\"),\nchanged the create handle to FD_PREPARE(), but it caused kernel\nnull-ptr-deref because after call to retain_and_null_ptr(src_info),\nsrc_info is re-used for adding it to the global list.\n\nGetting the following kernel panic in papr_hvpipe_dev_create_handle()\nwhen trying to add src_info to the list.\n Kernel attempted to write user page (0) - exploit attempt? (uid: 0)\n BUG: Kernel NULL pointer dereference on write at 0x00000000\n Faulting instruction address: 0xc0000000001b44a0\n Oops: Kernel access of bad area, sig: 11 [#1]\n ...\n Call Trace:\n papr_hvpipe_dev_ioctl+0x1f4/0x48c (unreliable)\n sys_ioctl+0x528/0x1064\n system_call_exception+0x128/0x360\n system_call_vectored_common+0x15c/0x2ec\n\nNow, the error handling with FD_PREPARE\u0027s file cleanup and __free(kfree) auto\ncleanup is getting too convoluted. This is mainly because we need to\nensure only 1 user get the srcID handle. To simplify this, we allocate\nprepare the src_info in the beginning and add it to the global list\nunder a spinlock after checking that no duplicates exist.\n\nThis simplify the error handling where if the FD_ADD fails, we can\nsimply remove the src_info from the list and consume any pending msg in\nhvpipe to be cleared, after src_info became visible in the global list.",
"id": "GHSA-g7gx-q434-9vpg",
"modified": "2026-05-28T12:30:29Z",
"published": "2026-05-28T12:30:29Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46118"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1b9f7aafa44f5ce852c00509104d10fd9eb0f402"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/735439394dde8462f9b50566727fbe333beaadaf"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/cf51bec1560f8bf115d1476f60335f9d90e110b0"
}
],
"schema_version": "1.4.0",
"severity": []
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.