-
Notifications
You must be signed in to change notification settings - Fork 29.8k
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
buffer: don't set zero fill for zero-length buffer #2931
Conversation
CI is green. |
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
d2d60e0
to
088585a
Compare
// sanity check to prevent the arraybuffer from being allocated with | ||
// garbage. | ||
if (size > 0) | ||
flags[kNoZeroFill] = 1; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Perhaps we should just reset the flag ourselves?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Already considered that. If for some reason buffer instantiation throws, and is caught, it won't have a chance to reset the value. The likelihood of that happening is slim to none. Just being super paranoid. I can swap the impl if you think it's unnecessary.
For anyone landing here as confused as I was about zero-filling zero-length buffers I had @trevnorris explain it to me in n00b terms. 74178a5 switched to using the V8 allocate and to make that performant enough to warrant removing Did I sum that up well enough @trevnorris? LGTM |
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>
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>
See nodejs/node#2943 for the discussion about the issue Refs nodejs/node#2931
See nodejs/node#2943 for the discussion about the issue Refs nodejs/node#2931
See nodejs/node#2943 for the discussion about the issue Refs nodejs/node#2931
See nodejs/node#2943 for the discussion about the issue Refs nodejs/node#2931
See nodejs/node#2943 for the discussion about the issue Refs nodejs/node#2931
Notable changes * buffer: Fixed a bug introduced in v4.1.0 where allocating a new zero-length buffer can result in the next allocation of a TypedArray in JavaScript not being zero-filled. In certain circumstances this could result in data leakage via reuse of memory space in TypedArrays, breaking the normally safe assumption that TypedArrays should be always zero-filled. (Trevor Norris) #2931. * http: Guard against response-splitting of HTTP trailing headers added via response.addTrailers() by removing new-line ([\r\n]) characters from values. Note that standard header values are already stripped of new-line characters. The expected security impact is low because trailing headers are rarely used. (Ben Noordhuis) #2945. * npm: Upgrade to npm 2.14.4 from 2.14.3, see release notes for full details (Kat Marchán) #2958 - Upgrades graceful-fs on multiple dependencies to no longer rely on monkey-patching fs - Fix npm link for pre-release / RC builds of Node * v8: Update post-mortem metadata to allow post-mortem debugging tools to find and inspect: - JavaScript objects that use dictionary properties (Julien Gilli) #2959 - ScopeInfo and thus closures (Julien Gilli) #2974
Notable changes * buffer: Fixed a bug introduced in v4.1.0 where allocating a new zero-length buffer can result in the next allocation of a TypedArray in JavaScript not being zero-filled. In certain circumstances this could result in data leakage via reuse of memory space in TypedArrays, breaking the normally safe assumption that TypedArrays should be always zero-filled. (Trevor Norris) #2931. * http: Guard against response-splitting of HTTP trailing headers added via response.addTrailers() by removing new-line ([\r\n]) characters from values. Note that standard header values are already stripped of new-line characters. The expected security impact is low because trailing headers are rarely used. (Ben Noordhuis) #2945. * npm: Upgrade to npm 2.14.4 from 2.14.3, see release notes for full details (Kat Marchán) #2958 - Upgrades graceful-fs on multiple dependencies to no longer rely on monkey-patching fs - Fix npm link for pre-release / RC builds of Node * v8: Update post-mortem metadata to allow post-mortem debugging tools to find and inspect: - JavaScript objects that use dictionary properties (Julien Gilli) #2959 - ScopeInfo and thus closures (Julien Gilli) #2974 PR-URL: #2995
landed in lts-v4.x-staging as d63e02e |
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: #2930
R=@indutny
R=@Fishrock123