x/sys/windows: reject overlong inputs in NewNTString

[bg0d-droid]

The x/sys/windows.NewNTString helper currently delegates length initialization to RtlInitString and does not reject strings that cannot fit in NTString's uint16 Length and MaximumLength fields. For overlong inputs, RtlInitString cannot accurately represent the source string, and the resulting NTString can have inconsistent length fields.

NewNTUnicodeString already rejects inputs that cannot fit in the corresponding 16-bit fields. NewNTString should do the same for ANSI strings and return syscall.EINVAL instead of returning a malformed NTString.

A pending fix and regression test are in CL 793100:

https://go-review.googlesource.com/c/sys/+/793100

Related GitHub PR:

golang/sys#281

[gopherbot]

Change https://go.dev/cl/793100 mentions this issue: windows: avoid length overflow in NewNTString

[gopherbot]

Change https://go.dev/cl/793120 mentions this issue: windows: avoid length overflow in NewNTString

[gabyhelp]

Related Issues

• x/sys/windows, internal/syscall/windows: integer overflow in NewNTUnicodeString #78916 (closed)

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}

[dmitshur]

CC @golang/windows.

[qmuntal]

Thanks for reporting and submitting the fix.

[neild]

Thanks to sorte for reporting this as a potential security vulnerability (before this issue was filed).

We designated a similar issue in NewNTUnicodeString CVE-2026-39824 (#78916). In the case of NewNTString, we are considering this a hardening measure rather than a vulnerability:

• NewNTString is a very thin wrapper for RtlInitString, which performs no length validation and requires the caller to avoid overflow.
• There are almost no uses of NewNTString in the wild. Few Windows APIs use NTString.
• None of the uses we have found seem to be vulnerable to overflow in any interesting way.