Skip to content
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

Closed
wants to merge 1 commit into from

Conversation

trevnorris
Copy link
Contributor

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

@trevnorris
Copy link
Contributor Author

@mscdex mscdex added the buffer Issues and PRs related to the buffer subsystem. label Sep 17, 2015
@trevnorris
Copy link
Contributor Author

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
// sanity check to prevent the arraybuffer from being allocated with
// garbage.
if (size > 0)
flags[kNoZeroFill] = 1;
Copy link
Member

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?

Copy link
Contributor Author

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.

@rvagg
Copy link
Member

rvagg commented Sep 17, 2015

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 Buffer::Create() a flag was conditionally set that tells ArrayBuffer::Allocator() to not zero-fill the next allocation—because we zero-fill initial allocations of Buffer because it slows it down (you can .fill(0) if you need). This is done by setting a flag that applies to the next allocation. Unfortunately for zero-length buffers there is no allocation required .. because .. zero .. so the flags don't get used and therefore don't get reset. So, when the next allocation comes around, it won't zero-fill it regardless of whether it's for a Node Buffer or not. So, the reported issue @ #2930 demonstrates that asking for a new Uint8Array from V8 will result in a non-zero-filled array, which is not what it should be doing and not what users expect to happen with those types.

Did I sum that up well enough @trevnorris?

LGTM

trevnorris added a commit that referenced this pull request Sep 18, 2015
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 <[email protected]>
@trevnorris
Copy link
Contributor Author

@rvagg That does well explain it. I've updated the commit message to be more clear on that point.

Landed in 0a329d2.

@trevnorris trevnorris closed this Sep 18, 2015
trevnorris added a commit that referenced this pull request Sep 20, 2015
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 <[email protected]>
mgol added a commit to mgol/check-dependencies that referenced this pull request Sep 20, 2015
See nodejs/node#2943 for the discussion about the issue

Refs nodejs/node#2931
mgol added a commit to mgol/grunt-check-dependencies that referenced this pull request Sep 20, 2015
See nodejs/node#2943 for the discussion about the issue

Refs nodejs/node#2931
mgol added a commit to EE/grunt-inline-images that referenced this pull request Sep 20, 2015
See nodejs/node#2943 for the discussion about the issue

Refs nodejs/node#2931
mgol added a commit to EE/jscs-trailing-comma that referenced this pull request Sep 20, 2015
See nodejs/node#2943 for the discussion about the issue

Refs nodejs/node#2931
mgol added a commit to mgol/npm-bump that referenced this pull request Sep 20, 2015
See nodejs/node#2943 for the discussion about the issue

Refs nodejs/node#2931
@rvagg rvagg mentioned this pull request Sep 22, 2015
rvagg added a commit that referenced this pull request Sep 22, 2015
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
rvagg added a commit that referenced this pull request Sep 23, 2015
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
@MylesBorins
Copy link
Contributor

landed in lts-v4.x-staging as d63e02e

@trevnorris trevnorris deleted the fix-ui8-zero-fill branch March 28, 2016 22:22
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
buffer Issues and PRs related to the buffer subsystem.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants