TextEncoder.encodeInto NOT work on BIG utf8 subarray ON 22.4.1 #62610

Activity

1. semimikoh commented on Apr 6, 2026

   

   semimikoh

   on Apr 6, 2026

   Last edited by semimikoh

   Contributor

   More actions

   Root cause

   This is a 32-bit integer overflow in EncodeInto in
   src/encoding_binding.cc:

   ```cpp
   size_t dest_length = dest->ByteLength(); // size_t — 2,390,753,275 OK

   int nchars;
   int written = source->WriteUtf8(
   isolate,
   write_result,
   dest_length, // implicit narrowing to int
   &nchars,
   String::NO_NULL_TERMINATION | String::REPLACE_INVALID_UTF8);
   ```

   v8::String::WriteUtf8 takes the capacity as an int. When
   dest_length exceeds INT32_MAX (2,147,483,647), the narrowing
   conversion underflows to a negative number, V8 treats it as "no
   capacity", and writes 0 bytes — hence { read: 0, written: 0 }.

   The subarray(offset, offset+10) case works because the view is
   only 10 bytes, well within int range.

   Already fixed on main / v24

   This was incidentally fixed by #58070 (src: use non-deprecated WriteUtf8V2() method), which migrated to WriteUtf8V2 whose
   capacity parameter is size_t. The intent of that PR was
   deprecation cleanup, not bug fixing, but it resolved this issue as
   a side effect.

   • v24.0.0+: fixed ✅
   • v22.x: still affected ❌ (int capacity still in place)

   v22 LTS backport?

   v22 is in maintenance LTS until 2027-04 and this causes silent data
   loss (not an error) for users with >2GB buffers. Would a minimal
   backport patch be acceptable — clamping the capacity to INT_MAX
   in EncodeInto specifically, rather than backporting the full
   WriteUtf8V2 migration?

   Happy to send a PR once the direction is confirmed.

   👍React with 👍1Reacted by sangwook
2. navegador5 commented on Apr 6, 2026

   

   navegador5

   on Apr 6, 2026

   Author

   More actions

   Root cause

   This is a 32-bit integer overflow in EncodeInto in src/encoding_binding.cc:

   int nchars; int written = source->WriteUtf8( isolate, write_result, dest_length, // implicit narrowing to int &nchars, String::NO_NULL_TERMINATION | String::REPLACE_INVALID_UTF8); ```
   
   `v8::String::WriteUtf8` takes the capacity as an `int`. When `dest_length` exceeds `INT32_MAX` (2,147,483,647), the narrowing conversion underflows to a negative number, V8 treats it as "no capacity", and writes 0 bytes — hence `{ read: 0, written: 0 }`.
   
   The `subarray(offset, offset+10)` case works because the view is only 10 bytes, well within int range.
   
   ## Already fixed on main / v24
   This was incidentally fixed by [#58070](https://github.com/nodejs/node/pull/58070) (`src: use non-deprecated WriteUtf8V2() method`), which migrated to `WriteUtf8V2` whose capacity parameter is `size_t`. The intent of that PR was deprecation cleanup, not bug fixing, but it resolved this issue as a side effect.
   
   * v24.0.0+: fixed ✅
   * v22.x: still affected ❌ (`int` capacity still in place)
   
   ## v22 LTS backport?
   v22 is in maintenance LTS until 2027-04 and this causes silent data loss (not an error) for users with >2GB buffers. Would a minimal backport patch be acceptable — clamping the capacity to `INT_MAX` in `EncodeInto` specifically, rather than backporting the full WriteUtf8V2 migration?
   
   Happy to send a PR once the direction is confirmed.

   v8 12.4.254(node 22.4.1) have NO WriteUtf8V2 , i think in 22.4 it should give a warning log
3. Renegade334

   added

   encodingIssues and PRs related to the TextEncoder and TextDecoder APIs.Issues and PRs related to the TextEncoder and TextDecoder APIs.

   v20.x

   v22.xIssues that can be reproduced on v22.x or PRs targeting the v22.x-staging branch.Issues that can be reproduced on v22.x or PRs targeting the v22.x-staging branch.

   on Apr 6, 2026
4. semimikoh

   added a commit that references this issue on Apr 30, 2026

   src: clamp WriteUtf8 capacity to INT_MAX in EncodeInto

   ...

   76b2b58
5. targos

   removed

   v20.x

   on May 1, 2026
6. marco-ippolito

   added 2 commits that reference this issue on May 11, 2026

   src: clamp WriteUtf8 capacity to INT_MAX in EncodeInto

   ...

   578a9a9

   test: simplify encodeInto large buffer regression test

   ...

   daaead3
7. github-actions commented on Jul 31, 2026

   

   github-actionsbot

   on Jul 31, 2026 – with GitHub Actions

   Contributor

   More actions

   This issue has been marked as stale due to 90 days of inactivity.
   It will be automatically closed in 30 days if no further activity occurs. If this is still relevant, please leave a comment or update it to keep it open.
8. github-actions

   added

   staleIssues and PRs marked stale due to inactivity and scheduled for automatic closure.Issues and PRs marked stale due to inactivity and scheduled for automatic closure.

   on Jul 31, 2026
9. richardlau commented on Aug 3, 2026

   

   richardlau

   on Aug 3, 2026

   Member

   More actions

   This was fixed by #62621 in Node.js 22.22.3.
10. richardlau

    closed this as completedon Aug 3, 2026