-
Notifications
You must be signed in to change notification settings - Fork 30.7k
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
New Uint8Arrays are sometimes filled with garbage #2930
Comments
/cc @trevnorris : maybe it has something to do with the new |
FYI, can't reproduce with 4.0.0. |
Must be a side effect of that commit. Give me a bit to look at the issue. If I can't figure it out then I'll revert the change today. |
Issue identified and have a fix. Creating PR shortly. |
@trevnorris it fixes the issue for me, thanks! |
The Uint8Array constructor doesn't hit the ArrayBuffer::Allocator() when length == 0. So in these cases don't set the kNoZeroFill flag, since it won't be reset. Add test to ensure Uint8Array's are zero-filled after creating a Buffer of length zero. This test may falsely succeed, but will not falsely fail. Fix: nodejs#2930
@dchest thanks much for the report, and for the steps to reproduce. allowed me to find the problem and write the fix in under 30 mins. always makes life easier. |
There's a zero-filling bug with Uint8Arrays in 4.1, which breaks one test: nodejs/node#2930 (comment)
Instantiating a Buffer of length zero would set the kNoZeroFill flag to true but never actually call ArrayBuffer::Allocator(). Which means the flag was never set back to false. The result was that the next allocation would unconditionally not be zero filled. Add test to ensure Uint8Array's are zero-filled after creating a Buffer of length zero. This test may falsely succeed, but will not falsely fail. Fix: #2930 PR-URL: #2931 Reviewed-By: Rod Vagg <rod@vagg.org>
Fixed by 0a329d2. Set to be released in v4.1.1. Should happen early next week. |
Instantiating a Buffer of length zero would set the kNoZeroFill flag to true but never actually call ArrayBuffer::Allocator(). Which means the flag was never set back to false. The result was that the next allocation would unconditionally not be zero filled. Add test to ensure Uint8Array's are zero-filled after creating a Buffer of length zero. This test may falsely succeed, but will not falsely fail. Fix: #2930 PR-URL: #2931 Reviewed-By: Rod Vagg <rod@vagg.org>
This makes sure that `kNoZeroFill` flag is not accidentally set by moving the all the flag operations directly inside `createBuffer()`. It safeguards against logical errors like #6006. This also ensures that `kNoZeroFill` flag is always restored to 0 using a try-finally block, as it could be not restored to 0 in cases of failed or zero-size `Uint8Array` allocation. It safeguards against errors like #2930. It also makes the `size > 0` check not needed there. PR-URL: nodejs-private/node-private#30 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Trevor Norris <trev.norris@gmail.com>
This makes sure that `kNoZeroFill` flag is not accidentally set by moving the all the flag operations directly inside `createBuffer()`. It safeguards against logical errors like #6006. This also ensures that `kNoZeroFill` flag is always restored to 0 using a try-finally block, as it could be not restored to 0 in cases of failed or zero-size `Uint8Array` allocation. It safeguards against errors like #2930. It also makes the `size > 0` check not needed there. PR-URL: nodejs-private/node-private#30 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Trevor Norris <trev.norris@gmail.com>
This makes sure that `kNoZeroFill` flag is not accidentally set by moving the all the flag operations directly inside `createBuffer()`. It safeguards against logical errors like nodejs/node#6006. This also ensures that `kNoZeroFill` flag is always restored to 0 using a try-finally block, as it could be not restored to 0 in cases of failed or zero-size `Uint8Array` allocation. It safeguards against errors like nodejs/node#2930. It also makes the `size > 0` check not needed there. PR-URL: https://github.com/nodejs/node-private/pull/35 Reviewed-By: James M Snell <jasnell@gmail.com>
Unfortunately, I don't have a neat small test case, so please bear with me.
One TweetNaCl-js test with Node.js 4.1 fails, while succeeding with 0.12 and io.js v3.3.1. The test is encrypting a message and comparing the result with a known good value.
To reproduce:
Output:
(
actual
may be different for you)The cause is in this function in
nacl.js
:https://github.com/dchest/tweetnacl-js/blob/master/nacl.js#L990
This function requires that
m
must be zero-filled.If I add
console.log
after creatingm
to see what's there:and run the test again, I see that
m
contains some garbage data (results differ from time to time):This only happens for this particular 33-byte Uint8Array in this particular setting (e.g. I couldn't reproduce this outside of this test). I can work around this by manually zeroing the array after creating it.
Any ideas? As I said, io.js v3.3.1 and previous Node versions doesn't have this bug.
The text was updated successfully, but these errors were encountered: