FreeRTOS Plus TCP CVE-2026-7424: Integer Underflow in DHCPv6 Parser Enables Single Packet Denial of Service — Quick Look and Patch Analysis

Introduction

A single malformed DHCPv6 packet from an adjacent network device can permanently freeze the IP task on any FreeRTOS based system running FreeRTOS-Plus-TCP with DHCPv6 enabled, requiring a physical hardware reset to recover. CVE-2026-7424 is an integer underflow in the DHCPv6 sub-option parser that also corrupts IPv6 address assignment and DNS configuration, earning it a CVSS 3.1 score of 8.1 (High).

FreeRTOS is a market leading real time operating system for microcontrollers and small microprocessors, supporting over 40 processor architectures and distributed freely under the MIT license. FreeRTOS-Plus-TCP is its companion open source TCP/IP stack, widely deployed in IoT devices, industrial controllers, and embedded systems across virtually every vertical. AWS maintains the project and its Long Term Support libraries, making this vulnerability relevant to a broad swath of the embedded ecosystem.

Technical Information

Root Cause: Unsigned Integer Underflow in prvDHCPv6_subOption()

The vulnerability resides in the file source/FreeRTOS_DHCPv6.c, specifically within the prvDHCPv6_subOption() function. This function contains a switch statement that processes known DHCPv6 sub-option types. The default case is responsible for handling unknown sub-option types by skipping over their payload bytes so the parser can advance to the next option.

In the vulnerable code, the number of bytes to skip was calculated as uxLength2 - uxUsed. The problem is that these two variables have entirely different semantics:

• uxLength2 is the payload length of the current sub-option being processed.
• uxUsed is a cumulative counter of bytes consumed from the parent option.

Subtracting a cumulative parent counter from a single sub-option's length is fundamentally incorrect. Both variables are unsigned (size_t), so when uxUsed exceeds uxLength2 (which it will in any message containing more than one sub-option), the subtraction wraps around to an extremely large positive value. This wrapped value is then passed to xBitConfig_read_uc(), which attempts to advance the parser index by that many bytes, corrupting the parser state entirely.

Attack Flow

The attack is straightforward and requires minimal sophistication:

1. Positioning: The attacker needs to be on the same local network segment as the target device. This is consistent with the CVSS 3.1 vector: AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H. No authentication, no privileges, and no user interaction are required.

2. Crafting the packet: The attacker constructs a single DHCPv6 response packet containing at least one unknown sub-option type within a parent option. The sub-option's declared payload length (uxLength2) must be smaller than the cumulative bytes already consumed (uxUsed) from the parent option, which naturally occurs when the unknown sub-option appears after other sub-options have been parsed.

3. Triggering the underflow: When the target device's DHCPv6 client processes this packet, the default case in prvDHCPv6_subOption() executes the skip calculation. The unsigned subtraction wraps, and xBitConfig_read_uc() is called with a massive byte count.

4. Impact: The corrupted parser index causes the device to misinterpret subsequent fields in the DHCPv6 message, leading to corruption of the IPv6 address assignment, DNS configuration, and lease times. The IP task enters a permanent freeze state. Recovery requires a hardware reset.

Because the attack requires only a single packet and no interaction from the target, any compromised or malicious device sharing the same Layer 2 segment can trigger it.

Impact Profile

The CVSS 3.1 assessment reflects high integrity impact (corrupted IPv6 and DNS settings) and high availability impact (permanent task freeze). Confidentiality is unaffected. The scope is unchanged, meaning the impact is confined to the vulnerable component itself, though in practice a frozen IP task renders the entire device non-functional from a networking perspective.

Patch Information

The vulnerability is fully patched in FreeRTOS-Plus-TCP V4.4.1 and V4.2.6, with identical fixes applied to both release branches. The patches were authored by Aniruddha Kanhere of Amazon and landed on April 29, 2026, via commits ca65d44 (V4.4.x line) and 0015547 (V4.2.x line). The change is surgical: only source/FreeRTOS_DHCPv6.c is modified, with 3 additions and 2 deletions.

The diff tells the full story:

             default:
-                ( void ) xBitConfig_read_uc( pxMessage, NULL, uxLength2 - uxUsed );
+                ( void ) xBitConfig_read_uc( pxMessage, NULL, uxLength2 );
                 FreeRTOS_printf( ( "prvDHCPv6Analyse: skipped unknown option %u\n", usOption2 ) );
                 break;
         }

-        if( xReturn != pdTRUE )
+        if( ( xReturn != pdTRUE ) || ( pxMessage->xHasError != pdFALSE ) )
         {
+            xReturn = pdFALSE;
             FreeRTOS_printf( ( "prvDHCPv6_subOption: One of sub-options %d returns error\n", usOption2 ) );
             break;
         }

Three distinct changes work together:

Change 1: Eliminate the underflow. The skip call now advances by uxLength2 bytes (the sub-option's own payload length) instead of uxLength2 - uxUsed. This is the core fix. The parser correctly skips exactly the bytes belonging to the current unknown sub-option, regardless of how much data has already been consumed from the parent option.

Change 2: Guard on xHasError. The loop exit condition is strengthened from just checking xReturn != pdTRUE to also checking pxMessage->xHasError != pdFALSE. This is a defense in depth measure. Even if no sub-option handler explicitly returns failure, an underlying xBitConfig_read_uc call that reads past the buffer will set xHasError on the message struct. Before this change, that error flag was silently ignored and the parsing loop would continue with corrupted state.

Change 3: Propagate failure. When the new combined condition triggers, the code now explicitly sets xReturn = pdFALSE before breaking out of the loop. This ensures the error status is correctly propagated to the caller, preventing any corrupted parser results from being used for IPv6 address or DNS configuration.

The AWS security bulletin (2026-022-AWS) and the GitHub Security Advisory (GHSA-wrhm-c99p-2p8g) both confirm V4.4.1 and V4.2.6 as the fixed versions.

Workarounds for Environments That Cannot Patch Immediately

For users who cannot immediately upgrade, two interim mitigations are available:

Mitigation Option	Implementation Details	Operational Impact
Disable DHCPv6	Set ipconfigUSE_DHCPv6 to 0 in FreeRTOSIPConfig.h	Requires manual static IPv6 address configuration
Network Filtering	Restrict DHCPv6 traffic to trusted sources on the local segment	Requires capable network hardware and strict segment control

It is critical to ensure that any forked or derivative code is also patched to incorporate these fixes.

Affected Systems and Versions

The vulnerability impacts two main version branches of FreeRTOS-Plus-TCP. The flaw is present whenever DHCPv6 is enabled (ipconfigUSE_DHCPv6 set to 1).

Branch	Affected Versions	Fixed Version
V4.0.x through V4.2.x	V4.0.0 through V4.2.5	V4.2.6
V4.3.x through V4.4.x	V4.3.0 through V4.4.0	V4.4.1

Devices running any affected version with DHCPv6 enabled and reachable from an adjacent network segment are vulnerable.

References

• NVD: CVE-2026-7424
• CVE Record: CVE-2026-7424
• AWS Security Bulletin 2026-022-AWS
• GitHub Security Advisory GHSA-wrhm-c99p-2p8g
• FreeRTOS-Plus-TCP Release V4.2.6
• FreeRTOS-Plus-TCP Release V4.4.1
• Patch Commit ca65d44 (V4.4.x branch)
• Patch Commit 0015547 (V4.2.x branch)
• FreeRTOS Official Site
• FreeRTOS LTS Libraries