stream: fix highWaterMark integer overflow #12593

Closed
wants to merge 4 commits into
from

Conversation

@tniessen
Member

tniessen commented Apr 22, 2017

Fixes integer overflows when supplying values exceeding 2 ^ 31 - 1 for highWaterMark.

Fixes: #12553

Checklist
  • make -j4 test (UNIX), or vcbuild test (Windows) passes
  • tests and/or benchmarks are included
  • commit message follows commit guidelines
Affected core subsystem(s)

stream

@mscdex

This comment has been minimized.

Show comment
Hide comment
@mscdex

mscdex Apr 22, 2017

Contributor

Instead of using ~~ to cast to integer, why not use something like Math.trunc() that will still convert to integer but allows larger numbers (>32 bits)? That should be a much simpler change.

Contributor

mscdex commented Apr 22, 2017

Instead of using ~~ to cast to integer, why not use something like Math.trunc() that will still convert to integer but allows larger numbers (>32 bits)? That should be a much simpler change.

test/parallel/test-regress-GH-12593.js
@@ -0,0 +1,16 @@
+'use strict';

This comment has been minimized.

@cjihrig

cjihrig Apr 22, 2017

Contributor

Could you add this to an appropriate existing test or give the file a better name. regress-GH-*.js names aren't really helpful for people working on the tests in the future.

@cjihrig

cjihrig Apr 22, 2017

Contributor

Could you add this to an appropriate existing test or give the file a better name. regress-GH-*.js names aren't really helpful for people working on the tests in the future.

This comment has been minimized.

@tniessen

tniessen Apr 23, 2017

Member

I could not find an existing test file matching this issue, so pick a new name?

@tniessen

tniessen Apr 23, 2017

Member

I could not find an existing test file matching this issue, so pick a new name?

This comment has been minimized.

@calvinmetcalf

calvinmetcalf May 3, 2017

Member

the convention would be then test-streams-highwatermark.js or similar

@calvinmetcalf

calvinmetcalf May 3, 2017

Member

the convention would be then test-streams-highwatermark.js or similar

test/parallel/test-regress-GH-12593.js
+
+assert.throws(() => {
+ stream.Readable({
+ highWaterMark: 'foo'

This comment has been minimized.

@cjihrig

cjihrig Apr 22, 2017

Contributor

Can you test a wider range of "bad" inputs.

@cjihrig

cjihrig Apr 22, 2017

Contributor

Can you test a wider range of "bad" inputs.

test/parallel/test-regress-GH-12593.js
+const stream = require('stream');
+
+assert.throws(() => {
+ stream.Readable({

This comment has been minimized.

@cjihrig

cjihrig Apr 22, 2017

Contributor

There should be tests for Writable too.

@cjihrig

cjihrig Apr 22, 2017

Contributor

There should be tests for Writable too.

lib/_stream_readable.js
+ }
+
+ if (~~hwm !== hwm) {
+ throw new Error('highWaterMark exceeds valid range');

This comment has been minimized.

@cjihrig

cjihrig Apr 22, 2017

Contributor

This should be a RangeError. It might be helpful to say what the valid range actually is.

@cjihrig

cjihrig Apr 22, 2017

Contributor

This should be a RangeError. It might be helpful to say what the valid range actually is.

lib/_stream_readable.js
- this.highWaterMark = (hwm || hwm === 0) ? hwm : defaultHwm;
+ if (hwm != null) {
+ if (typeof hwm !== 'number') {
+ throw new TypeError('highWaterMark must be a number');

This comment has been minimized.

@cjihrig

cjihrig Apr 22, 2017

Contributor

I think we're standardizing on putting the offending data's name in double quotes. So "highWaterMark" in this case.

@cjihrig

cjihrig Apr 22, 2017

Contributor

I think we're standardizing on putting the offending data's name in double quotes. So "highWaterMark" in this case.

This comment has been minimized.

@jasnell

jasnell May 4, 2017

Member

This raises a good question... at some point we will need these errors to work with internals/errors but we need to make sure we are coordinating with the readable-streams folks.

@jasnell

jasnell May 4, 2017

Member

This raises a good question... at some point we will need these errors to work with internals/errors but we need to make sure we are coordinating with the readable-streams folks.

test/parallel/test-regress-GH-12593.js
@@ -0,0 +1,16 @@
+'use strict';
+const common = require('../common');

This comment has been minimized.

@vsemozhetbyt

vsemozhetbyt Apr 22, 2017

Member

Linter: 'common' is assigned a value but never used. This can be just:

require('../common');
@vsemozhetbyt

vsemozhetbyt Apr 22, 2017

Member

Linter: 'common' is assigned a value but never used. This can be just:

require('../common');
@tniessen

This comment has been minimized.

Show comment
Hide comment
@tniessen

tniessen Apr 23, 2017

Member

@mscdex These changes are based on the discussion below #12553 which suggested to disallow exceeding values. If it is consensus that larger values than 2GB should be supported, I will adapt the PR accordingly.

Member

tniessen commented Apr 23, 2017

@mscdex These changes are based on the discussion below #12553 which suggested to disallow exceeding values. If it is consensus that larger values than 2GB should be supported, I will adapt the PR accordingly.

@mscdex

This comment has been minimized.

Show comment
Hide comment
@mscdex

mscdex Apr 23, 2017

Contributor

@tniessen I could see throwing on negative values, but I think most people would expect larger values to just work (as #12553 shows). Separating out the two changes would allow just the negative value check to be semver-major while the Math.trunc() fix could be backported as a bug fix (IMHO).

Contributor

mscdex commented Apr 23, 2017

@tniessen I could see throwing on negative values, but I think most people would expect larger values to just work (as #12553 shows). Separating out the two changes would allow just the negative value check to be semver-major while the Math.trunc() fix could be backported as a bug fix (IMHO).

@tniessen

This comment has been minimized.

Show comment
Hide comment
@tniessen

tniessen Apr 23, 2017

Member

@mscdex Should I use this PR to fix the bug using Math.trunc() and another to check against negative values (and invalid types)?

Member

tniessen commented Apr 23, 2017

@mscdex Should I use this PR to fix the bug using Math.trunc() and another to check against negative values (and invalid types)?

@mscdex

This comment has been minimized.

Show comment
Hide comment
@mscdex

mscdex Apr 23, 2017

Contributor

@tniessen It might be good to hear from other @nodejs/collaborators about my proposed solution first.

Contributor

mscdex commented Apr 23, 2017

@tniessen It might be good to hear from other @nodejs/collaborators about my proposed solution first.

@mcollina

This comment has been minimized.

Show comment
Hide comment
@mcollina

mcollina Apr 23, 2017

Member

I'm on vacation untill the end of this week.

This should be reviewed by @nodejs/streams. If someone else from the wg has time, we need to check this deeply as we do not want to break the ecosystem.

Generically, I'm -1 on making a semver-major out of this, so we should stick to throwing on negative values.

Member

mcollina commented Apr 23, 2017

I'm on vacation untill the end of this week.

This should be reviewed by @nodejs/streams. If someone else from the wg has time, we need to check this deeply as we do not want to break the ecosystem.

Generically, I'm -1 on making a semver-major out of this, so we should stick to throwing on negative values.

@mscdex

This comment has been minimized.

Show comment
Hide comment
@mscdex

mscdex Apr 23, 2017

Contributor

@mcollina Throwing where we previously didn't would be semver-major I think. At least I believe that's been the general trend in the past.

Contributor

mscdex commented Apr 23, 2017

@mcollina Throwing where we previously didn't would be semver-major I think. At least I believe that's been the general trend in the past.

@mcollina

This comment has been minimized.

Show comment
Hide comment
@mcollina

mcollina Apr 23, 2017

Member

I think if highWaterMark is < 0, none of the stream machinery would work. I am without a laptop, so I need to check this. I would classify this as a bug fix, as the original code would fail silently.

I'm -1 on pumping semver-major for this right now, because of the maintenance burden it will take on readable-stream.

Member

mcollina commented Apr 23, 2017

I think if highWaterMark is < 0, none of the stream machinery would work. I am without a laptop, so I need to check this. I would classify this as a bug fix, as the original code would fail silently.

I'm -1 on pumping semver-major for this right now, because of the maintenance burden it will take on readable-stream.

@tniessen

This comment has been minimized.

Show comment
Hide comment
@tniessen

tniessen May 3, 2017

Member

Any updates?

Member

tniessen commented May 3, 2017

Any updates?

@mcollina

This comment has been minimized.

Show comment
Hide comment
@mcollina

mcollina May 3, 2017

Member

Any negative value is interpreted by the stream machinery as a 0, which makes this bug tricky: a user is putting in a value that is extremely high with the intent of "buffer forever", and instead it gets a stream that is always flowing.

I think we should not throw in this case, but instead cast the highWaterMark to 2147483647 if there is an overflow. Also, I would normalize any negative value to 0. Those should not be semver-major changes.

Member

mcollina commented May 3, 2017

Any negative value is interpreted by the stream machinery as a 0, which makes this bug tricky: a user is putting in a value that is extremely high with the intent of "buffer forever", and instead it gets a stream that is always flowing.

I think we should not throw in this case, but instead cast the highWaterMark to 2147483647 if there is an overflow. Also, I would normalize any negative value to 0. Those should not be semver-major changes.

lib/_stream_readable.js
+ throw new TypeError('highWaterMark must be a number');
+ }
+
+ if (~~hwm !== hwm) {

This comment has been minimized.

@calvinmetcalf

calvinmetcalf May 3, 2017

Member

is this the way we do things other places in node?

@calvinmetcalf

calvinmetcalf May 3, 2017

Member

is this the way we do things other places in node?

This comment has been minimized.

@tniessen

tniessen May 4, 2017

Member

It is how the old implementation converted hvm to a 32-bit integer. This is open for discussion, see this comment by @mscdex.

@tniessen

tniessen May 4, 2017

Member

It is how the old implementation converted hvm to a 32-bit integer. This is open for discussion, see this comment by @mscdex.

@calvinmetcalf

This comment has been minimized.

Show comment
Hide comment
@calvinmetcalf

calvinmetcalf May 3, 2017

Member

I think we should not throw in this case, but instead cast the highWaterMark to 2147483647 if there is an overflow. Also, I would normalize any negative value to 0. Those should not be semver-major changes.

I think buffer.kMaxLength is the actual upper bounds for how large hwm could be

Member

calvinmetcalf commented May 3, 2017

I think we should not throw in this case, but instead cast the highWaterMark to 2147483647 if there is an overflow. Also, I would normalize any negative value to 0. Those should not be semver-major changes.

I think buffer.kMaxLength is the actual upper bounds for how large hwm could be

@mscdex

This comment has been minimized.

Show comment
Hide comment
@mscdex

mscdex May 3, 2017

Contributor

I think buffer.kMaxLength is the actual upper bounds for how large hwm could be

Why is that? I would think the only time that particular constant would matter is if a user tried to .read(n) a very large number of bytes that exceeded that constant and there was enough buffered data to actually cover that kind of length. Otherwise such a single, large Buffer shouldn't ever be created.

Contributor

mscdex commented May 3, 2017

I think buffer.kMaxLength is the actual upper bounds for how large hwm could be

Why is that? I would think the only time that particular constant would matter is if a user tried to .read(n) a very large number of bytes that exceeded that constant and there was enough buffered data to actually cover that kind of length. Otherwise such a single, large Buffer shouldn't ever be created.

@mcollina

This comment has been minimized.

Show comment
Hide comment
@mcollina

mcollina May 4, 2017

Member

I would think the only time that particular constant would matter is if a user tried to .read(n) a very large number of bytes that exceeded that constant and there was enough buffered data to actually cover that kind of length. Otherwise such a single, large Buffer shouldn't ever be created.

Currently hightWaterMark  is going from 2147483647 to -2147483647.

Member

mcollina commented May 4, 2017

I would think the only time that particular constant would matter is if a user tried to .read(n) a very large number of bytes that exceeded that constant and there was enough buffered data to actually cover that kind of length. Otherwise such a single, large Buffer shouldn't ever be created.

Currently hightWaterMark  is going from 2147483647 to -2147483647.

@mscdex

This comment has been minimized.

Show comment
Hide comment
@mscdex

mscdex May 4, 2017

Contributor

Currently hightWaterMark  is going from 2147483647 to -2147483647.

I don't understand this comment. What does that have to do with potentially using buffer.kMaxLength as the upper bound? Right now it's just coincidence that buffer.kMaxLength and ~~ produce the same max value.

Anyway, I think we should still allow larger values via Math.trunc().

Contributor

mscdex commented May 4, 2017

Currently hightWaterMark  is going from 2147483647 to -2147483647.

I don't understand this comment. What does that have to do with potentially using buffer.kMaxLength as the upper bound? Right now it's just coincidence that buffer.kMaxLength and ~~ produce the same max value.

Anyway, I think we should still allow larger values via Math.trunc().

lib/_stream_readable.js
@@ -68,11 +68,19 @@ function ReadableState(options, stream) {
// the point at which it stops calling _read() to fill the buffer
// Note: 0 is a valid value, means "don't call _read preemptively ever"
var hwm = options.highWaterMark;
- var defaultHwm = this.objectMode ? 16 : 16 * 1024;
- this.highWaterMark = (hwm || hwm === 0) ? hwm : defaultHwm;
+ if (hwm != null) {

This comment has been minimized.

@reqshark

reqshark May 4, 2017

why the loose null check? why not do if (hwm) { // ... ?

@reqshark

reqshark May 4, 2017

why the loose null check? why not do if (hwm) { // ... ?

This comment has been minimized.

@micnic

micnic May 4, 2017

Contributor

I guess because hwm can be 0 (zero)

@micnic

micnic May 4, 2017

Contributor

I guess because hwm can be 0 (zero)

This comment has been minimized.

@reqshark

reqshark May 4, 2017

a zero watermark doesn't make sense, anything less than 1 is nothing getting processed.

also why delete defaultHwm?

@reqshark

reqshark May 4, 2017

a zero watermark doesn't make sense, anything less than 1 is nothing getting processed.

also why delete defaultHwm?

This comment has been minimized.

@calvinmetcalf

calvinmetcalf May 4, 2017

Member

a 0 is allowed for comparability reasons

@calvinmetcalf

calvinmetcalf May 4, 2017

Member

a 0 is allowed for comparability reasons

This comment has been minimized.

@reqshark

reqshark May 4, 2017

a 0 is allowed for comparability reasons

please embellish, what/when does that comparison happen?

@reqshark

reqshark May 4, 2017

a 0 is allowed for comparability reasons

please embellish, what/when does that comparison happen?

This comment has been minimized.

@tniessen

tniessen May 4, 2017

Member

I did not want to change the behavior of accepting 0. I just deleted defaultHwm because I think it is pretty obvious what 16 * 1024 is in the new code, though I can use a variable as well.

@tniessen

tniessen May 4, 2017

Member

I did not want to change the behavior of accepting 0. I just deleted defaultHwm because I think it is pretty obvious what 16 * 1024 is in the new code, though I can use a variable as well.

@tniessen

This comment has been minimized.

Show comment
Hide comment
@tniessen

tniessen May 4, 2017

Member

Without further discussions of the code, are there any objections to @mscdex suggestion? Otherwise, I am going to split this into two PRs as suggested.

Member

tniessen commented May 4, 2017

Without further discussions of the code, are there any objections to @mscdex suggestion? Otherwise, I am going to split this into two PRs as suggested.

@mcollina

This comment has been minimized.

Show comment
Hide comment
@mcollina

mcollina May 5, 2017

Member

@tniessen go ahead and implement @mscdex suggestion.

Member

mcollina commented May 5, 2017

@tniessen go ahead and implement @mscdex suggestion.

@tniessen tniessen changed the title from stream: add highWaterMark validity checks to stream: fix highWaterMark integer overflow May 10, 2017

stream: fix highWaterMark integer overflow
Fixes integer overflows when supplying values exceeding 2 ^ 31 - 1 for
highWaterMark.
@tniessen

This comment has been minimized.

Show comment
Hide comment
@tniessen

tniessen May 10, 2017

Member

@mscdex @cjihrig @mcollina @calvinmetcalf I force-pushed a commit which only contains the integer overflow fix.

Member

tniessen commented May 10, 2017

@mscdex @cjihrig @mcollina @calvinmetcalf I force-pushed a commit which only contains the integer overflow fix.

@cjihrig

LGTM with one request.

+const assert = require('assert');
+const stream = require('stream');
+
+const readable = stream.Readable({ highWaterMark: 2147483648 });

This comment has been minimized.

@cjihrig

cjihrig May 10, 2017

Contributor

Can you move all of the 2147483648s into a variable, and add a comment on why that specific value was chosen. That should prevent anyone from changing it to a small value in the future.

@cjihrig

cjihrig May 10, 2017

Contributor

Can you move all of the 2147483648s into a variable, and add a comment on why that specific value was chosen. That should prevent anyone from changing it to a small value in the future.

This comment has been minimized.

@mscdex

mscdex May 10, 2017

Contributor

I think a better value to test is Number.MAX_SAFE_INTEGER.

@mscdex

mscdex May 10, 2017

Contributor

I think a better value to test is Number.MAX_SAFE_INTEGER.

This comment has been minimized.

@mcollina

LGTM, dropping this to semver-minor

@mcollina mcollina added semver-minor and removed semver-major labels May 10, 2017

@mcollina

This comment has been minimized.

Show comment
Hide comment
@mcollina

mcollina May 10, 2017

Member

I'll be landing this tomorrow (11th of May), if no one objects.

CI: https://ci.nodejs.org/job/node-test-pull-request/7991/

edit: 11th of May

Member

mcollina commented May 10, 2017

I'll be landing this tomorrow (11th of May), if no one objects.

CI: https://ci.nodejs.org/job/node-test-pull-request/7991/

edit: 11th of May

@tniessen

This comment has been minimized.

Show comment
Hide comment
@tniessen

tniessen May 10, 2017

Member

Thanks @mcollina. I will create a separate PR with the semver-major changes after this gets merged.

Member

tniessen commented May 10, 2017

Thanks @mcollina. I will create a separate PR with the semver-major changes after this gets merged.

@mscdex

This comment has been minimized.

Show comment
Hide comment
@mscdex

mscdex May 10, 2017

Contributor

I'll be landing this tomorrow (10th of May), if no one objects.

Today is the 10th ;-)

Anyway, here is CITGM: https://ci.nodejs.org/view/Node.js-citgm/job/citgm-smoker/772/

Contributor

mscdex commented May 10, 2017

I'll be landing this tomorrow (10th of May), if no one objects.

Today is the 10th ;-)

Anyway, here is CITGM: https://ci.nodejs.org/view/Node.js-citgm/job/citgm-smoker/772/

@mcollina

This comment has been minimized.

Show comment
Hide comment
@mcollina

mcollina May 10, 2017

Member

Updated with the correct date, thanks @mscdex.

Member

mcollina commented May 10, 2017

Updated with the correct date, thanks @mscdex.

@mcollina

This comment has been minimized.

Show comment
Hide comment
@mcollina

mcollina May 10, 2017

Member

I think the citgm failures are recurring, can someone confirm?

Member

mcollina commented May 10, 2017

I think the citgm failures are recurring, can someone confirm?

@tniessen

This comment has been minimized.

Show comment
Hide comment
@tniessen

tniessen May 10, 2017

Member

@mcollina I don't see any relations between the reported errors and this PR. Are there known problems with citgm?

Member

tniessen commented May 10, 2017

@mcollina I don't see any relations between the reported errors and this PR. Are there known problems with citgm?

@lucamaraschi

LGTM
@tniessen can you please add the general description of the test as indicated in the general guidelines?

@tniessen

This comment has been minimized.

Show comment
Hide comment
Member

tniessen commented May 11, 2017

@lucamaraschi Done.

@tniessen

This comment has been minimized.

Show comment
Hide comment
@tniessen

tniessen May 13, 2017

Member

@mscdex @mcollina Thoughts about citgm? Was this tested on master? I built 57a08e2 (which was the last commit on master before I branched) and tried npm test on node-ftp (which failed on citgm). I was able to reproduce the error without my PR.

Member

tniessen commented May 13, 2017

@mscdex @mcollina Thoughts about citgm? Was this tested on master? I built 57a08e2 (which was the last commit on master before I branched) and tried npm test on node-ftp (which failed on citgm). I was able to reproduce the error without my PR.

lib/_stream_readable.js
@@ -72,7 +72,7 @@ function ReadableState(options, stream) {
this.highWaterMark = (hwm || hwm === 0) ? hwm : defaultHwm;
// cast to ints.
- this.highWaterMark = ~~this.highWaterMark;
+ this.highWaterMark = Math.trunc(this.highWaterMark);

This comment has been minimized.

@mscdex

mscdex May 14, 2017

Contributor

Actually, I think we may want to use Math.floor() instead, it seems to be significantly faster (~6x at least on V8 5.8).

@mscdex

mscdex May 14, 2017

Contributor

Actually, I think we may want to use Math.floor() instead, it seems to be significantly faster (~6x at least on V8 5.8).

This comment has been minimized.

@mcollina

mcollina May 15, 2017

Member

👍

This comment has been minimized.

@mcollina

mcollina May 15, 2017

Member

@tniessen can you update that?

@mcollina

mcollina May 15, 2017

Member

@tniessen can you update that?

This comment has been minimized.

@tniessen

tniessen May 15, 2017

Member

Done.

@@ -72,7 +72,7 @@ function ReadableState(options, stream) {
this.highWaterMark = (hwm || hwm === 0) ? hwm : defaultHwm;
// cast to ints.
- this.highWaterMark = ~~this.highWaterMark;
+ this.highWaterMark = Math.floor(this.highWaterMark);

This comment has been minimized.

@thefourtheye

thefourtheye May 15, 2017

Contributor

Minor nit: This changes the result when passed a negative floating point number.

@thefourtheye

thefourtheye May 15, 2017

Contributor

Minor nit: This changes the result when passed a negative floating point number.

This comment has been minimized.

@mcollina

mcollina May 15, 2017

Member

@thefourtheye what do you suggest? Can you make an example?
This was just changed at @mscdex suggestion from Math.trunc.

All negative values are interpreted as 0 by the machinery, so nothing should change.

@mcollina

mcollina May 15, 2017

Member

@thefourtheye what do you suggest? Can you make an example?
This was just changed at @mscdex suggestion from Math.trunc.

All negative values are interpreted as 0 by the machinery, so nothing should change.

This comment has been minimized.

@thefourtheye

thefourtheye May 15, 2017

Contributor

@mcollina Oh thats okay. This is just a nit. I am just making an observation here.

@thefourtheye

thefourtheye May 15, 2017

Contributor

@mcollina Oh thats okay. This is just a nit. I am just making an observation here.

This comment has been minimized.

@mscdex

mscdex May 15, 2017

Contributor

It'll be even less of an issue once we start throwing on invalid values.

@mscdex

mscdex May 15, 2017

Contributor

It'll be even less of an issue once we start throwing on invalid values.

This comment has been minimized.

@tniessen

tniessen May 15, 2017

Member

This is correct, but not an actual problem. According to @mcollina:

Any negative value is interpreted by the stream machinery as a 0

Therefore, it does not matter whether the value is Math.floor(-233.5) = -234 or ~~(-233.5) = -233, not even in the special case of Math.floor(-0.5) = -1 whilst ~~(-0.5) = 0.

We are planning to throw on negative values anyway.

Edit: Sorry, the last three messages were invisible to me until now, I did not know this had already been discussed with @mcollina and @mscdex.

@tniessen

tniessen May 15, 2017

Member

This is correct, but not an actual problem. According to @mcollina:

Any negative value is interpreted by the stream machinery as a 0

Therefore, it does not matter whether the value is Math.floor(-233.5) = -234 or ~~(-233.5) = -233, not even in the special case of Math.floor(-0.5) = -1 whilst ~~(-0.5) = 0.

We are planning to throw on negative values anyway.

Edit: Sorry, the last three messages were invisible to me until now, I did not know this had already been discussed with @mcollina and @mscdex.

@mcollina

This comment has been minimized.

Show comment
Hide comment
@mcollina

mcollina May 16, 2017

Member

Landed as 11918c4

Member

mcollina commented May 16, 2017

Landed as 11918c4

@mcollina mcollina closed this May 16, 2017

mcollina added a commit that referenced this pull request May 16, 2017

stream: fix highWaterMark integer overflow
Fixes integer overflows when supplying values exceeding MAX_SAFE_INTEGER
for highWaterMark.

PR-URL: #12593
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Luca Maraschi <luca.maraschi@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>

tniessen added a commit to tniessen/node that referenced this pull request May 16, 2017

stream: check highWaterMark type and range
Adds checks for the type of "highWaterMark" and restricts it to
non-negative values.

Refs: nodejs#12593

@tniessen tniessen referenced this pull request May 16, 2017

Closed

stream: check type and range of highWaterMark #13065

3 of 3 tasks complete

anchnk added a commit to anchnk/node that referenced this pull request May 19, 2017

stream: fix highWaterMark integer overflow
Fixes integer overflows when supplying values exceeding MAX_SAFE_INTEGER
for highWaterMark.

PR-URL: nodejs#12593
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Luca Maraschi <luca.maraschi@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>

@jasnell jasnell referenced this pull request May 28, 2017

Closed

8.0.0 Release Proposal #12220

@gibfahn

This comment has been minimized.

Show comment
Hide comment
@gibfahn

gibfahn Jan 15, 2018

Member

Release team opted not to backport to v6.x, as it seems there is a chance it might break things, and we haven't seen any requests for it. If there are reasons to backport let us know.

Member

gibfahn commented Jan 15, 2018

Release team opted not to backport to v6.x, as it seems there is a chance it might break things, and we haven't seen any requests for it. If there are reasons to backport let us know.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment