PULSE
FEED
ransombooba project reclama a Boardman Park · GB · Otherransombooba project reclama a Vetstoria · SE · Healthcareransombooba project reclama a City of Edgewater · US · Government & Defenseransombooba project reclama a DROUIN SAS · FR · Manufacturingransomn0n reclama a Company #127 · SAransomn0n reclama a Company #126ransomn0n reclama a Company #125 · USransomn0n reclama a Company #124 · USransomn0n reclama a Company #123 · USransomrhysida reclama a Here at Pope and Johnson County Title Company · Financial Servicesransomorova reclama a MARDEC Berhad · MY · Manufacturingransomorova reclama a Hydrogel Vision Corporation · US · Healthcareransomorova reclama a Raffles United Holdings Pte Ltd · SG · Hospitalityransomobsoft reclama a Company #2 · KRransombooba project reclama a Boardman Park · GB · Otherransombooba project reclama a Vetstoria · SE · Healthcareransombooba project reclama a City of Edgewater · US · Government & Defenseransombooba project reclama a DROUIN SAS · FR · Manufacturingransomn0n reclama a Company #127 · SAransomn0n reclama a Company #126ransomn0n reclama a Company #125 · USransomn0n reclama a Company #124 · USransomn0n reclama a Company #123 · USransomrhysida reclama a Here at Pope and Johnson County Title Company · Financial Servicesransomorova reclama a MARDEC Berhad · MY · Manufacturingransomorova reclama a Hydrogel Vision Corporation · US · Healthcareransomorova reclama a Raffles United Holdings Pte Ltd · SG · Hospitalityransomobsoft reclama a Company #2 · KR
← Todos los CVEs
CVE Watch15 oct 2026

CVE-2026-46118

In the Linux kernel, the following vulnerability has been resolved: pseries/papr-hvpipe: Fix null ptr deref in papr_hvpipe_dev_create_handl

CVSS

5.5

Medio

EPSS

0.1%

p2

KEV

—

Exploit Today

1

0-100

Publicado: 28 may 2026 · Última mod.: 15 oct 2026 · CWE-476

EPSS · 30d
0.1%EPSS · 30 días0.2%
2026-10-052026-11-02
Descripción técnica

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.

Referencias oficiales
CVEs relacionados
CVECVSSEPSSKEVRExplotTítuloVis.
CVE-2026-115403—
—
——0In Eclipse ThreadX NetX Duo versions 6.0 through 6.5.2.202603a, built with BSD raw socket and IPv6 support, the IPv6 raw send path uses the destination-table entry it adds without checking that the add succeeded. When the destination table is full and an off-link destination is reached through a default router whose neighbour cache entry is unknown, sending on an IPv6 raw socket with header inclusion dereferences a NULL pointer; a remote sender can fill the table, for example with ICMPv6 Packet Too Big messages, and crash the sending thread.19h
CVE-2026-114408—
—
——0In Eclipse ThreadX NetX Duo versions 6.4.5.202504 through 6.5.2.202603a, built with IPv6 path MTU discovery, the ICMPv6 Packet Too Big handler uses the destination-table entry it adds without checking that the add succeeded. A sender on the network can fill the destination table with Packet Too Big messages quoting new destinations, after which the next message makes the IP helper thread dereference a NULL pointer, crashing it on targets that fault on address 0 and stopping all network processing.22h
CVE-2026-1204545.5 MED
—
——0The Sleuth Kit through 4.15.0 contains a NULL pointer dereference vulnerability in decmpfs_decompress_lzvn_attr() that allows attackers to crash the tool by supplying a crafted HFS+ image. Attackers can set a huge uncompressed_size in an LZVN inline com.apple.decmpfs attribute so allocation fails and the decoder writes through NULL, causing denial of service.22h
CVE-2026-629667.5 ALT
36.9%
——11ESPAsyncWebServer is an asynchronous HTTP and WebSocket server library for ESP32, ESP8266, RP2040 and RP2350. Prior to version 3.11.2, the multipart parser in `src/WebRequest.cpp` frees `_itemBuffer` and sets it to NULL when `BOUNDARY_OR_DATA` matches the closing boundary of a file part, before confirming the following terminator, while leaving `_itemIsFile` true. If the next byte is neither the final closing dashes nor a clean CRLF, the `DASH3_OR_RETURN2` or `EXPECT_FEED2` rewind branch re-injects provisionally consumed bytes through `itemWriteByte`. Because `_itemIsFile` remains true, `_itemBuffer`[`_itemBufferIndex`++] writes through a null pointer. On ESP32 this causes a `StoreProhibited` exception, panic and device reboot, producing remote denial of service. A route with a non-trivial body/upload handler, such as a file-upload or web-OTA endpoint, must be present. This issue is fixed in version 3.11.2.4d
CVE-2026-599936.5 MED
16.1%
——5Picotls is a TLS protocol library that allows users select different crypto backends based on their use case. In affected revisions through 44bc503, when picotls is used as a `client-side TLS stack`, a peer can send a `HelloRetryRequest` followed by a `spoofed Hello message` that causes a null-pointer dereference. This can terminate the consuming process, including a process performing other work, resulting in denial of service. This issue is fixed in commit a06ca41.4d
CVE-2026-62298—
42.9%
——13mouse07410/asn1c is an ASN.1 compiler. Prior to 1.2.5, `OPEN TYPE` decoding can dereference an unallocated member pointer and crash the consuming program. `OPEN_TYPE_aper_get` in `OPEN_TYPE_aper.c`, `OPEN_TYPE_ber_get` in `OPEN_TYPE_ber.c`, `OPEN_TYPE_oer_get` in `OPEN_TYPE_oer.c`, and `OPEN_TYPE_uper_get` in `OPEN_TYPE_uper.c` share the pattern: a conditional null check on `*memb_ptr2` resets presence only when the member exists, but execution then unconditionally computes an inner value from that pointer and a member offset. If the `OPEN TYPE` member has not been allocated, the null-pointer arithmetic and subsequent read cause a segmentation fault. The advisory demonstrates UPER and APER crashes for `E2connectionUpdateAcknowledge`, notes that `E2AP` uses APER, and provides a BER reproducer; OER is also explicitly identified as affected. This issue is fixed in version 1.2.5.4d