Edge Node CLI Crash on Dataplane API with Multibyte Object Names Exceeding Byte Boundaries

Products

• VMware NSX

Issue/Introduction

Parsing errors and unexpected failures occur on NSX Edge Nodes when object names contain non-Latin characters and exceed certain byte-length boundaries. This manifests in two primary ways:

API Failure: The Dataplane Firewall Stats API fails when processing objects like IPsec Route-based VPNs. For example, a request to

GET /api/v1/transport-nodes/{transport-node-id}/node/services/dataplane/fw-stats
returns
500 Internal Server Error. 

CLI Failure on Edge Node: Running the bridge summary command on the Edge Node CLI fails with an internal exception:

edge> get bridge summary
<timestamp>
% An unexpected error occurred: Failed to get bridge port. Internal exception

Environment

VMware NSX

Cause

This issue is caused by an unsafe UTF-8 string truncation inside C-based Dataplane components.

An internal variable uses a fixed-size buffer declared as char name[32] (allowing up to 31 bytes plus a null terminator \0). When an object name (such as an IPsec Route-based VPN or a Segment with bridging enabled) contains multibyte UTF-8 characters (e.g., Greek characters where 1 character = 2 bytes) and crosses the 31-byte threshold:

• If the first byte of a multibyte character falls exactly on the 31st byte boundary, the character sequence is split/truncated.
• The resulting string contains an invalid/corrupted UTF-8 byte sequence and may lack proper null-termination.
• When C-based Dataplane components process this corrupted string buffer, it leads to memory parsing errors, CLI crashes.

Reproduction Matrix & Behavior

Testing with Greek characters (α  = 2 bytes in UTF-8):

Test #	Segment Name Structure	Byte Calculation	Total Bytes	Result	Notes
1	15 x α + 'A'	(15 x 2) + 1	31 bytes	PASS	Fits inside 31-byte limit.
2	16 x α	16 x 2	32 bytes	FAIL	1st byte of 16th α lands on byte 31 --> Truncation/Crash.
3	17 x α	17 x 2	34 bytes	FAIL	1st byte of 16th α lands on byte 31 --> Truncation/Crash.

 

Resolution

This issue will be fixed in the upcoming VMware NSX releases.

Workaround: To prevent or resolve this issue:

• Avoid non-ASCII / Multibyte Characters: Limit object names (VPNs, Segments, etc.) strictly to standard ASCII characters (1 byte per character).
• Limit Name Length: Keep names under 31 bytes total in UTF-8 encoding.