buffer: don't set zero fill for zero-length buffer by trevnorris · Pull Request #2931 · nodejs/node
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
trevnorris added a commit that referenced this pull request
Sep 18, 2015Instantiating 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>
trevnorris added a commit that referenced this pull request
Sep 20, 2015Instantiating 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>
rvagg
mentioned this pull request
rvagg added a commit that referenced this pull request
Sep 22, 2015Notable 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, 2015Notable 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
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters