Base64Url.DecodeFromChars crashes with AccessViolationException on non-ASCII char input (Microsoft.Bcl.Memory)

[Tomius]

Description

Base64Url.DecodeFromChars causes a fatal AccessViolationException (process crash, exit code 0xC0000005)
when the input ReadOnlySpan<char> contains non-ASCII characters with sufficiently high code point values.

The method should return OperationStatus.InvalidData for invalid input, but instead performs an
out-of-bounds memory read in the scalar decode path via Unsafe.Add into the 256-element DecodingMap.

Reproduction Steps

1. Create a .NET 8 console app referencing Microsoft.Bcl.Memory (any version — tested with 9.0.5)
2. Run the following code:

using System.Buffers;
using System.Buffers.Text;

const string input = "AB\u1000D";
byte[] buffer = new byte[Base64Url.GetMaxDecodedLength(input.Length)];
Base64Url.DecodeFromChars(input, buffer, out _, out _);

Expected behavior

DecodeFromChars returns OperationStatus.InvalidData, since \u1000 is not a valid Base64Url character.

Actual behavior

The process crashes with a fatal AccessViolationException:

Fatal error. System.AccessViolationException: Attempted to read or write protected memory. This is often an indication that other memory is corrupt.
   at System.Buffers.Text.Base64Helper.DecodeFrom[[...Base64UrlDecoderChar...],[System.UInt16...]](...)
   at System.Buffers.Text.Base64Url.DecodeFromChars(...)

Regression?

This is not a regression — the bug has existed since Base64Url was first made available for .NET 8
via the Microsoft.Bcl.Memory NuGet package.

Known Workarounds

A safe workaround is to call System.Text.Ascii.IsValid(input) before decoding.
Base64 only uses ASCII characters, so any non-ASCII input is inherently invalid.

Configuration

• Crashes on: .NET 8.0.24, Windows 10 x64, Microsoft.Bcl.Memory 9.0.5
• Works correctly on: .NET 10.0.2 (in-framework Base64Url — returns InvalidData)
• Not architecture-specific, but only affects the scalar decode path (short inputs or tail processing)

Other information

Root cause

The scalar fallback path in Base64Helper.DecodeFrom calls decoder.DecodeFourElements(src, ref decodingMap).
For the char/ushort decoder, this uses Unsafe.Add(ref decodingMap, (IntPtr)charValue) to index into
the DecodingMap, which is only 256 elements. A char value > 255 (e.g. \u1000 = 4096) reads
4096 bytes past the start of the map, hitting unmapped memory.

Characters in the range 128–255 do not crash (they read adjacent mapped memory that happens to
contain -1 / invalid values), but characters >= ~4096 reliably trigger the access violation.

The SIMD paths (AVX2, SSE, NEON) are not affected because they narrow ushort to byte before the
lookup, which naturally clamps the value to 0–255.

Notes

• Base64Url.DecodeFromChars (the 2-parameter overload that throws FormatException) and
  Base64Url.TryDecodeFromChars are equally affected since they call the same internal DecodeFrom method.

[dotnet-policy-service]

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

[Tomius]

Root Cause Analysis

The bug is in Base64Helper.DecodeFrom<TBase64Decoder, T> (Base64DecoderHelper.cs). After calling DecodeRemaining, the method uses the out parameters t2/t3 as indices into the 256-element DecodingMap via Unsafe.Add without first checking whether DecodeRemaining returned -1 (invalid data):

int i0 = decoder.DecodeRemaining(srcEnd, ref decodingMap, remaining, out uint t2, out uint t3);

byte* destMax = destBytes + (uint)destLength;

if (!decoder.IsValidPadding(t3))
{
    int i2 = Unsafe.Add(ref decodingMap, (IntPtr)t2);  // ← out-of-bounds if t2 > 255
    int i3 = Unsafe.Add(ref decodingMap, (IntPtr)t3);
    i2 <<= 6;
    i0 |= i3;
    i0 |= i2;
    if (i0 < 0)        // ← checked too late
    {
        goto InvalidDataExit;
    }
    // ...

DecodeRemaining(ushort*) itself correctly detects non-ASCII via ((num2 | num3 | t2 | t3) & 0xFFFFFF00u) != 0 and returns -1, but it has already written the raw ushort values to the out parameters. The caller ignores the -1 return and proceeds to use those values as memory offsets.

For input "AB\u1000D", t2 is set to 0x1000 (4096), causing Unsafe.Add(ref decodingMap, 4096) to read 4096 bytes past the 256-byte DecodingMap.

This affects .NET 10 too (latent undefined behavior)

By decompiling both Microsoft.Bcl.Memory.dll (v9.0.5, net8.0) and System.Private.CoreLib.dll (.NET 10.0.0) using ILSpy, the DecodeFrom method is byte-for-byte identical. The bug exists in both.

The reason it doesn't crash on .NET 10 is purely due to memory layout:

• On .NET 8, the DecodingMap lives in the small Microsoft.Bcl.Memory.dll (~50KB). Reading 4096 bytes past it lands beyond the DLL's mapped pages → AccessViolationException.
• On .NET 10, the DecodingMap lives in the large System.Private.CoreLib.dll (~15MB). Reading 4096+ bytes past it still lands within the DLL's read-only data section → reads garbage, but since i0 is already -1, i0 |= garbage stays negative, and the if (i0 < 0) check (which comes after the read) correctly routes to InvalidDataExit.

I confirmed this empirically: on .NET 10, even U+FFFF (offset 65535 past the map) returns InvalidData without crashing. On .NET 8, it crashes at around offset ~2048. The behavior is entirely dependent on what memory happens to be mapped at the read location — textbook undefined behavior.

Suggested fix

Add an early return check in DecodeFrom after the DecodeRemaining call:

int i0 = decoder.DecodeRemaining(srcEnd, ref decodingMap, remaining, out uint t2, out uint t3);

if (i0 < 0)
{
    goto InvalidDataExit;
}

// ... existing code that uses t2/t3 as indices is now safe

This should also be applied to the else if branch that uses t2 via Unsafe.Add(ref decodingMap, (IntPtr)t2).

Minimal repro

using System.Buffers.Text;

const string input = "AB\u1000D";
byte[] buffer = new byte[Base64Url.GetMaxDecodedLength(input.Length)];
Base64Url.DecodeFromChars(input, buffer, out _, out _);
// .NET 8 + Microsoft.Bcl.Memory: fatal AccessViolationException
// .NET 10: returns InvalidData (by luck, not by correctness)

Environment

• Crashes on: .NET 8.0.24, Windows 10 x64, Microsoft.Bcl.Memory 9.0.5
• Latent on: .NET 10.0.2, Windows 10 x64 (same bug, no crash due to memory layout)