CVE-2025-55090: Eclipse ThreadX NetX Duo Buffer Overflow

CVE-2025-55090 Overview

CVE-2025-55090 is an out-of-bounds read vulnerability in Eclipse ThreadX NetX Duo, the networking support module for the Eclipse Foundation ThreadX real-time operating system. The flaw resides in the _nx_ipv4_packet_receive() function, which fails to properly validate the size of incoming Ethernet frames before parsing the encapsulated IP packet. When an attacker sends a malformed Ethernet frame containing fewer than 4 bytes of IP packet data, the function reads memory beyond the intended buffer boundary. The vulnerability affects NetX Duo versions prior to 6.4.4 and is tracked under [CWE-125: Out-of-Bounds Read].

Critical Impact
Remote attackers on adjacent networks can trigger memory disclosure or cause instability in embedded devices running ThreadX by sending undersized IPv4 Ethernet frames.

Affected Products

Eclipse ThreadX NetX Duo versions prior to 6.4.4
Embedded systems and IoT devices using ThreadX RTOS with the NetX Duo networking stack
Real-time applications relying on the NetX Duo IPv4 packet receive path

Discovery Timeline

2025-10-16 - CVE-2025-55090 published to NVD
2026-06-17 - Last updated in NVD database

Technical Details for CVE-2025-55090

Vulnerability Analysis

The vulnerability exists in the IPv4 packet reception path of the NetX Duo networking stack. The _nx_ipv4_packet_receive() function processes incoming Ethernet frames and interprets their payload as IPv4 packets. The function assumes that the frame contains at least a minimum viable IPv4 header, but it does not verify that the payload contains enough bytes to satisfy this assumption. When a frame carrying fewer than 4 bytes of IP data reaches the function, the parser dereferences memory outside the allocated packet buffer.

An adjacent-network attacker can exploit this behavior by crafting undersized Ethernet frames and transmitting them to a vulnerable device. The out-of-bounds read may expose adjacent kernel memory contents or destabilize the RTOS depending on memory layout and pool configuration. The EPSS score of 0.344% indicates a low probability of exploitation activity in the near term, but embedded targets often lack rapid patch cycles.

Root Cause

The root cause is missing length validation prior to header field access. The receive routine reads IPv4 header fields without first confirming that the packet length is at least the size of the minimum header the code intends to inspect. This omission allows the underlying memory read to extend past the buffer supplied by the driver layer.

Attack Vector

Exploitation requires network access to the target device. The attacker sends a specially crafted Ethernet frame with an IPv4 EtherType and a payload smaller than 4 bytes. Because IPv4 packet reception occurs early in the network stack, no authentication or user interaction is required. The condition is triggered before any application-layer processing.

No verified proof-of-concept code has been published. Refer to the GitHub Security Advisory GHSA-cf2g-j6vv-m8c5 for authoritative technical detail.

Detection Methods for CVE-2025-55090

Indicators of Compromise

Malformed Ethernet frames with IPv4 EtherType 0x0800 and payload length less than 4 bytes on monitored network segments
Unexpected reboots, watchdog resets, or memory faults on ThreadX-based embedded devices
Anomalous traffic patterns targeting the management interfaces of IoT and industrial control devices

Detection Strategies

Deploy network intrusion detection signatures that flag IPv4 frames with truncated headers on network segments hosting ThreadX devices
Correlate device crash telemetry with inbound packet capture data to identify triggering frames
Use the SentinelOne Singularity Platform to ingest and correlate network telemetry from adjacent managed endpoints and identify hosts sourcing malformed IPv4 traffic

Monitoring Recommendations

Forward device syslog, watchdog, and crash-dump events into a centralized SIEM such as Singularity Data Lake for OCSF-normalized correlation across the fleet
Monitor egress traffic from user workstations to embedded device management VLANs for anomalies
Track firmware version inventory to identify devices still running NetX Duo builds prior to 6.4.4

How to Mitigate CVE-2025-55090

Immediate Actions Required

Upgrade Eclipse ThreadX NetX Duo to version 6.4.4 or later across all affected firmware images
Rebuild and redeploy any embedded firmware that statically links vulnerable NetX Duo revisions
Segment ThreadX-based devices onto isolated VLANs that restrict adjacent-network exposure
Inventory all products and OEM devices using the ThreadX RTOS to identify indirect exposure

Patch Information

Eclipse Foundation addressed the flaw in NetX Duo 6.4.4. The fix introduces length validation in _nx_ipv4_packet_receive() to reject frames that do not contain the minimum required IP header bytes before any header dereference. Consult the GitHub Security Advisory GHSA-cf2g-j6vv-m8c5 for the patch commit and integration guidance.

Workarounds

Enforce Layer 2 filtering on switches to drop IPv4 Ethernet frames smaller than the minimum expected size of 60 bytes
Restrict device network exposure through access control lists that only permit trusted management hosts
Where feasible, disable IPv4 processing on interfaces that do not require it until patched firmware is deployed

bash

# Example switch ACL to drop undersized IPv4 frames on an access port
# (syntax varies by vendor; verify against platform documentation)
interface GigabitEthernet0/5
  storm-control broadcast level 1.00
  ip access-group DROP_TRUNCATED_IPV4 in

ip access-list extended DROP_TRUNCATED_IPV4
  deny   ip any any packet-length lt 28
  permit ip any any