CVE-2026-46118

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