-
Notifications
You must be signed in to change notification settings - Fork 30.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in 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>
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: