Repository navigation
Ascii and Latin1 APIs can return wrong results for misaligned buffers #84877
Description
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.
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.
Activity
tannergooding commentedon Apr 17, 2023
CC. @GrabYourPitchforks, this has been around for about 4 years since dotnet/coreclr#22516
While the JIT expects that any
T,ref T, orT*is "naturally aligned" and it expects you to use theunaligned.prefix (such as viaUnsafe.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 thataddress % 2 == 0prior to trying to align the data.thatbakamono commentedon Apr 18, 2023
I'd like to take care of this, could it be assigned to me?
thatbakamono commentedon Apr 29, 2023
The issue is actually not reproducible anymore with the provided example, I noticed after rebasing that
Ascii.IsValidgot reimplemented in #84881 without using the affected methods. All other APIs relying onGetIndexOfFirstNonXYZCharorGetIndexOfFirstNonXYZByte(whereXYZis eitherAsciiorLatin1) should be still affected.thatbakamono commentedon May 11, 2023
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.
GrabYourPitchforks commentedon May 20, 2024
Looks like a dupe of #44497, which was resolved by-design. From that issue: in general, pointers are assumed to be properly aligned for the target data type, except in very specific circumstances where the API is expressly documented as supporting unaligned accesses.
stephentoub commentedon Jul 23, 2024
Closing as duplicate and by-design per above.