Ascii and Latin1 APIs can return wrong results for misaligned buffers

[MihaZupan]

char* pBuffer = stackalloc char[17];
Span<char> misalignedSpan = new((char*)((byte*)pBuffer + 1), 16);
misalignedSpan.Fill('a');

if (!Ascii.IsValid(misalignedSpan)) Console.WriteLine("Oh no");

Ascii.IsValid pins the input and works with pointers internally. GetIndexOfFirstNonAsciiChar_Intrinsified will attempt to 16-byte align the input pointer to make use of aligned reads, but in doing so it ends up working with the "corrupted" data if the input wasn't 2-byte aligned initially.

runtime/src/libraries/System.Private.CoreLib/src/System/Text/Ascii.Utility.cs

Line 829 in 72586a7

pBuffer = (char*)(((nuint)pBuffer + SizeOfVector128InBytes) & ~(nuint)(SizeOfVector128InBytes - 1));

As a result it may end up returning the wrong result (both false positives and false negatives).

Latin1Utility also likely shares the same issue.

It's safe to assume that related operations on Encoding that make use of these helpers are likewise affected.

Tagging subscribers to this area: @dotnet/area-system-buffers
See info in area-owners.md if you want to be subscribed.

Issue Details

---

char* pBuffer = stackalloc char[17];
Span<char> misalignedSpan = new((char*)((byte*)pBuffer + 1), 16);
misalignedSpan.Fill('a');

if (!Ascii.IsValid(misalignedSpan)) Console.WriteLine("Oh no");

Ascii.IsValid pins the input and works with pointers internally. GetIndexOfFirstNonAsciiChar_Intrinsified will attempt to 16-byte align the input pointer to make use of aligned reads, but in doing so it ends up working with the "corrupted" data if the input wasn't 2-byte aligned initially.

runtime/src/libraries/System.Private.CoreLib/src/System/Text/Ascii.Utility.cs

Line 829 in 72586a7

pBuffer = (char*)(((nuint)pBuffer + SizeOfVector128InBytes) & ~(nuint)(SizeOfVector128InBytes - 1));

As a result it may end up returning the wrong result (both false positives and false negatives).

Latin1Utility also likely shares the same issue.

It's safe to assume that related operations on Encoding that make use of these helpers are likewise affected.

Author:	MihaZupan
Assignees:	-
Labels:	area-System.Buffers
Milestone:	-

[tannergooding]

CC. @GrabYourPitchforks, this has been around for about 4 years since dotnet/coreclr#22516

While the JIT expects that any T, ref T, or T* is "naturally aligned" and it expects you to use the unaligned. prefix (such as via Unsafe.ReadUnaligned) to access unaligned data; correctly detecting and handling data that is misaligned isn't difficult and won't noticeably hurt the common path. -- We should just need to check that address % 2 == 0 prior to trying to align the data.

[thatbakamono]

I'd like to take care of this, could it be assigned to me?

[thatbakamono]

The issue is actually not reproducible anymore with the provided example, I noticed after rebasing that Ascii.IsValid got reimplemented in #84881 without using the affected methods. All other APIs relying on GetIndexOfFirstNonXYZChar or GetIndexOfFirstNonXYZByte (where XYZ is either Ascii or Latin1) should be still affected.

[thatbakamono]

Sorry for stalling the issue, I thought I'd be able to resolve it pretty quickly but a few unforeseen complications occurred and I don't think I'll be able to finish working on the fix any time soon. Thanks for the opportunity though, I learned quite a bit about the workflow and it'll allow me to make contributions more easily in the future.