Bug 290829 – Uint8Array.prototype.setFromBase64 doesn't work correctly in Ubuntu build

• Status: NEW
• Component: JavaScriptCore

If there’s extra padding in the Base64 string, the Uint8Array.prototype.setFromBase64 method should not write the last chunk — but it does.

Example:
target = new Uint8Array([255, 255, 255, 255, 255]);
target.setFromBase64('MjYyZg===');

It should throw an error and the result should be Uint8Array([50, 54, 50, 255, 255]), but actual result is Uint8Array([255, 255, 255, 255, 255]).

Tested on Web (48.0) and WebKitHeadless (2.46.6) via playwright on Ubuntu 22.04.5 LTS

Fixed summary:
If there’s extra padding in the Base64 string, the Uint8Array.prototype.setFromBase64 method should write all chunks except the last — but it writes nothing.

[Alexey Proskuryakov]

FWIW, on macOS I'm getting an exception:

>>> target.setFromBase64('MjYyZg===');
Exception: SyntaxError: Uint8Array.prototype.setFromBase64 requires a valid base64 string

[Sosuke Suzuki]

Probably sm's output is correct.

```
// input
target = new Uint8Array([255, 255, 255, 255, 255]);
try {
    target.setFromBase64('MjYyZg===');
} catch (e) {
    print(e.constructor.name);
}
print(target);
```

## JSC

```
SyntaxError
255,255,255,255,255
```

## SM

```
SyntaxError
50,54,50,255,255
```

(In reply to Sosuke Suzuki from comment #3)
> Probably sm's output is correct.
> 
> ```
> // input
> target = new Uint8Array([255, 255, 255, 255, 255]);
> try {
>     target.setFromBase64('MjYyZg===');
> } catch (e) {
>     print(e.constructor.name);
> }
> print(target);
> ```
> 
> ## JSC
> 
> ```
> SyntaxError
> 255,255,255,255,255
> ```
> 
> ## SM
> 
> ```
> SyntaxError
> 50,54,50,255,255
> ```

According to the specification https://tc39.es/proposal-arraybuffer-base64/spec/#sec-uint8array.prototype.setfrombase64, the SM behavior is correct.

I found this https://bugs.webkit.org/show_bug.cgi?id=276859, and it seems like it has been fixed, but...

[Yusuke Suzuki]

Ah, this does not reproduce on Trunk with ARM64 / x64 macOS. So given that reported version is very old (WebKitGTK 2.46), it is already fixed.

[Radar WebKit Bug Importer]

<rdar://problem/148546882>

[zloirock]

It's reproduced in the latest Playwright and only on Linux, not on Mac, so it seems it's not fixed.

We added a test upstream for this specific issue (in an underlying library handling base64 content, simdutf). The simdutf library is tested and built under linux as a matter of course.


In simplified form, we test it in C++ as follows:

    std::string data = "MjYyZg===";
    std::vector<char> output(3);
    std::vector<uint8_t> expected = {0x32, 0x36, 0x32};
    size_t back_length = output.size();
    auto r = simdutf::base64_to_binary_safe(data.data(), data.size(),
                                            output.data(), back_length);
    ASSERT_EQUAL(r.error, simdutf::error_code::INVALID_BASE64_CHARACTER);
    ASSERT_EQUAL(r.count, 6);
    ASSERT_EQUAL(back_length, 3);
    ASSERT_BYTES_EQUAL(output, expected, 3);

If you'd like to test it on your system, we invite you to do :

   git clone https://github.com/simdutf/simdutf.git
   cd simdutf
   cmake -B build
   cmake --build build
   ctest --test-dir build

This will run many tests, including the test equivalent to the code I provided. I am assuming you have cmake and g++ installed, if not, you should be able to install them under ubuntu as follows:

   sudo apt update
   sudo apt install build-essential

If you are a Linux alpine or fedora user, you can install simdutf directly. You can also install simdutf using homebrew.

Should you encounter an issue, please report it at https://github.com/simdutf/simdutf

[Yusuke Suzuki]

I've ran JSC on Ubuntu 24.04 x86_64. But it didn't reproduce the issue.
I wonder if this is happening only when it uses some specific x64 path on simdutf?

[Yusuke Suzuki]

@zloirock @[e-mail]
Can you describe your CPU model specifically? I wonder if this is happening on older Intel x64 CPU and related to simdutf.

[Yusuke Suzuki]

Note that my tested Ubuntu x64 CPU is `Intel Core i5-9600K @ 6x 4.6GHz`

[Yusuke Suzuki]

Or I wonder if this is happening only on IceLake or later

(In reply to Yusuke Suzuki from comment #11)
> @zloirock @[e-mail]
> Can you describe your CPU model specifically? I wonder if this is happening
> on older Intel x64 CPU and related to simdutf.

11th Gen Intel(R) Core(TM) i7-11370H @ 3.30GHz

(In reply to Yusuke Suzuki from comment #6)
> Ah, this does not reproduce on Trunk with ARM64 / x64 macOS. So given that
> reported version is very old (WebKitGTK 2.46), it is already fixed.

My bad — Playwright uses its own builds instead of the local one. In my tests, it was build 2140, which uses libjavascriptcoregtk-6.0.so.1.5.1 and libwebkitgtk-6.0.so.4.11.3.

(In reply to daniel from comment #9)
> If you'd like to test it on your system, we invite you to do :
> 
>    git clone https://github.com/simdutf/simdutf.git
>    cd simdutf
>    cmake -B build
>    cmake --build build
>    ctest --test-dir build

All tests have passed

The code from this topic fails in Epiphany 48 (based on WebKitGTK 2.48.0)

[Yusuke Suzuki]

@[e-mail]

So, can you try the latest JSC build?
For example, esvu can install the up-to-date JSC https://github.com/devsnek/esvu

We have that [e-mail] finds that simdutf passes tests locally when testing the simdutf library directly on their system. These tests include a test simdutf::base64_to_binary_safe. It is the function that WTF calls in this context:

https://github.com/WebKit/WebKit/blob/b82feba1824ebd42478f2ad9eecb7c112a24db49/Source/WTF/wtf/text/Base64.cpp#L458

It would be nice to then check *which version* of the code [e-mail] is testing. It is possible that the issue is triggered by older code (no longer current).

These were core-js tests run via Playwright. I can’t explain why, but on Sauce Labs, using the same OS (Ubuntu 22.04), all tests pass. The error from the code in the topic is reproducible locally in the browser (Epiphany 48). I think it’s just something weird on my local machine.

[zloirock]

The same bug is present in the latest Bun on Ubuntu 22.04.

The issue has been identified in simdutf: 

https://github.com/simdutf/simdutf/pull/762

The simdutf library decodes data in large blocks for performance. It identifies mistaken characters ahead of time and exits quickly.

We should be able to patch over the issue. :-)