zlib: fix node crashing on invalid options #13098

aqrln · 2017-05-18T10:02:03Z

This PR fixes the Node process crashing when constructors of classes of the zlib module are given invalid options.

Throw an Error when the zlib library rejects the value of windowBits, instead of crashing with an assertion.
Treat windowBits and memLevel options consistently with other ones and don't crash when non-numeric values are given.

Checklist

make -j4 test (UNIX), or vcbuild test (Windows) passes
tests and/or benchmarks are included
documentation is changed or added
commit message follows commit guidelines

Affected core subsystem(s)

zlib

The main reason behind this commit is fixing the Node process crashing when zlib rejects the given options. Besides that issue, which got reported and which is linked to this commit, it turned out that Node also used to crash when a non-numeric value was passed as the `windowBits` or the `memLevel` option. This was fixed somewhat inadvertently; initially it was just a stylistic change to avoid lines spanning longer than 80 characters that was written in a manner consistent with surrounding code. Fixes: nodejs#13082

aqrln · 2017-05-18T10:06:06Z

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

lpinca · 2017-05-18T10:10:50Z

@aqrln did something change with zlib 1.2.11?

zlib.createDeflateRaw({ windowBits: 8 })

worked fine with Node.js 6.10.1.

aqrln · 2017-05-18T10:18:04Z

@lpinca frankly, I don't know. But the docs state that 8 is not a valid value of windowBits for raw deflate and gzip.

lpinca · 2017-05-18T10:23:56Z

I wonder if it makes sense to use this remedy

The remedy is to not use 8 with deflateInit2() with this initialization, or at least in that case use 9 with inflateInit2().

in order to avoid the breaking change.

addaleax · 2017-05-18T10:13:16Z

src/node_zlib.cc

    SetDictionary(ctx);
+
+    args.GetReturnValue().Set(Boolean::New(args.GetIsolate(), result));


I’m pretty sure you don’t need Boolean::New here :)

Thanks, didn't know that :)

addaleax · 2017-05-18T10:22:53Z

lib/zlib.js

+    process.nextTick(() => {
+      this.emit('error', error);
+    });
+  }


I think this error should still be thrown synchronously, if there is one.

That'll make it impossible to catch this error since there's on object returned to userland code yet to listen to the error event on. That's basically the reason for all this machinery, otherwise @cjihrig's one-line fix would be just fine.

You could change the ZCtx::Error(ctx, "Init error"); line to throw an error instead … that should work, right?

Hmm... yes, it should. And there would be no need for all those changes in zlib.js then.

addaleax · 2017-05-18T10:25:12Z

src/node_zlib.cc

@@ -553,6 +556,9 @@ class ZCtx : public AsyncWrap {

    if (ctx->err_ != Z_OK) {
      ZCtx::Error(ctx, "Init error");
+      if (dictionary != nullptr)
+        delete[] dictionary;
+      return false;


I’d have to admit I prefer the solution suggested by @cjihrig in #13082 (comment) (or just move this error-checking block to the end of the Init() function, after ctx->init_done_ = true)

aqrln · 2017-05-18T10:52:25Z

@lpinca do you suggest making windowBits 9 when 8 is passed?

lpinca · 2017-05-18T10:57:56Z

@aqrln yes use 15 (default value) when 8 is passed, not sure if it is a good idea though. Maybe it is better to do this in userland code.

Throw an Error synchronously instead of fiddling with 'error' events.

aqrln · 2017-05-18T13:13:31Z

@addaleax throwing an error synchronously indeed makes it a lot more elegant, thanks.

@lpinca I'm not sure about that too. I'd just document this limitation and not change user's options silently, but let's see what others think about it.

aqrln · 2017-05-18T13:30:13Z

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

cjihrig

LGTM with a couple comments.

cjihrig · 2017-05-18T13:43:26Z

doc/api/zlib.md

@@ -437,6 +437,10 @@ added: v0.5.8

 Returns a new [DeflateRaw][] object with an [options][].

+**Note:** zlib library rejects requests for 256-byte windows (i.e.,


Maybe start the note with "The"

cjihrig · 2017-05-18T13:45:24Z

lib/zlib.js

@@ -229,9 +229,15 @@ class Zlib extends Transform {
    var strategy = constants.Z_DEFAULT_STRATEGY;
    if (typeof opts.strategy === 'number') strategy = opts.strategy;

-    this._handle.init(opts.windowBits || constants.Z_DEFAULT_WINDOWBITS,
+    var windowBits = constants.Z_DEFAULT_WINDOWBITS;


Couldn't these both just be ternaries?

They could, and I'd like them to be, but I just wrote these in a style consistent with the code above. How about me addressing this comment in a follow-up PR, together with some more refactoring like replacing most vars with lets and consts?

cjihrig · 2017-05-18T13:46:37Z

test/parallel/test-zlib-failed-init.js

+// (http://zlib.net/manual.html#Advanced)
+assert.throws(() => {
+  zlib.createDeflateRaw({ windowBits: 8 });
+}, /Init error/);


Can you match the full error here using ^ and $.

lpinca · 2017-05-18T15:15:50Z

Does is makes sense to throw early if opts.windowBits === 8? We already have a check here.

addaleax · 2017-05-18T15:17:51Z

@lpinca I think it would. Are you thinking of doing that instead of this PR, or in addition to? I think the changes here are still good independently

aqrln · 2017-05-18T15:20:38Z

@lpinca idk ¯\_(ツ)_/¯ Theoretically, it may change in the future:

For the current implementation of deflate(), a windowBits value of 8 (a window size of 256 bytes) is not supported.

lpinca · 2017-05-18T15:22:37Z

I would make it in addition of these changes to make the error message consistent, but then the "Init error" would not be easy to test.

aqrln · 2017-05-18T15:27:15Z

Yeah, we might do that just for the sake of making the error message more sensible. Seems like all the other ways to break deflateInit2() are already covered by the JavaScript checks.

lpinca · 2017-05-18T15:28:08Z

Yes and this explains why it didn't crash before zlib 1.2.11.

lpinca

LGTM with or without the additional check for opts.windowBits === 8.

aqrln · 2017-05-18T16:09:42Z

That's quite easy to do (aqrln@bf63a37), but I am not really sure about it. I actually see the point in doing so, but being able to test that any sort of failure can be caught seems to be more important, so I'm inclined to leave this PR as it is now unless others would prefer to pull either that commit or something similar to it here.

aqrln · 2017-05-18T16:34:33Z

CI for the latest changes: https://ci.nodejs.org/job/node-test-pull-request/8159/

thefourtheye · 2017-05-18T17:24:55Z

lib/zlib.js

+    if (typeof opts.windowBits === 'number') windowBits = opts.windowBits;
+
+    var memLevel = constants.Z_DEFAULT_MEMLEVEL;
+    if (typeof opts.memLevel === 'number') memLevel = opts.memLevel;


This change alters the existing behaviour a little. If we pass NaN or Zero, they used to pick the default value earlier.

Great catch, thanks. It uncovers a whole bunch of bugs in the validation logic above, i.e., I wanted to say that zero would be caught before this line, but after trying it out it appeared to be not. And it was also possible to pass NaN as the value of some of the other options, like level.

lpinca · 2017-05-18T18:24:38Z

so I'm inclined to leave this PR as it is now unless others would prefer to pull either that commit or something similar to it here.

I agree. As you said this may change again and 8 could be restored as valid value so it's probably better to keep this as is.

This commit fixes the Node process crashing when constructors of classes of the zlib module are given invalid options. * Throw an Error when the zlib library rejects the value of windowBits, instead of crashing with an assertion. * Treat windowBits and memLevel options consistently with other ones and don't crash when non-numeric values are given. * Fix bugs in the validation logic: - Don't conflate 0 and undefined when checking if a field of an options object exists. - Treat NaN and Infinity values the same way as values of invalid types instead of allowing to actually set zlib options to NaN or Infinity. PR-URL: #13098 Fixes: #13082 Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Luigi Pinca <luigipinca@gmail.com> Reviewed-By: Sakthipriyan Vairamani <thechargingvolcano@gmail.com>

This is a partial backport of semver-patch bits of 9e4660b. This commit fixes the Node process crashing when constructors of classes of the zlib module are given invalid options. * Throw an Error when the zlib library rejects the value of windowBits, instead of crashing with an assertion. * Treat windowBits and memLevel options consistently with other ones and don't crash when non-numeric values are given. PR-URL: nodejs#13098 Backport-PR-URL: nodejs#13201 Fixes: nodejs#13082 Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Luigi Pinca <luigipinca@gmail.com> Reviewed-By: Sakthipriyan Vairamani <thechargingvolcano@gmail.com>

This is a partial backport of semver-patch bits of 9e4660b. This commit fixes the Node process crashing when constructors of classes of the zlib module are given invalid options. * Throw an Error when the zlib library rejects the value of windowBits, instead of crashing with an assertion. * Treat windowBits and memLevel options consistently with other ones and don't crash when non-numeric values are given. PR-URL: #13098 Backport-PR-URL: #13201 Fixes: #13082 Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Luigi Pinca <luigipinca@gmail.com> Reviewed-By: Sakthipriyan Vairamani <thechargingvolcano@gmail.com>

This LTS release comes with 221 commits. This includes 80 which are test related, 52 which are doc related, 32 which are build / tool related and 10 commits which are updates to dependencies. Notable Changes: * configure: - add mips64el to valid_arch (Aditya Anand) - #13620 * crypto: - Updated root certificates based on [NSS 3.30] (Ben Noordhuis) - #13279 - #12402 - https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/NSS_3.30_release_notes * deps: - upgrade OpenSSL to version 1.0.2.l (Shigeki Ohtsu) - #12913 * http: - parse errors are now reported when NODE_DEBUG=http (Sam Roberts) - #13206 - Agent construction can now be envoked without `new` (cjihrig) - #12927 * zlib: - node will now throw an Error when zlib rejects the value of windowBits, instead of crashing (Alexey Orlenko) - #13098 PR-URL: #14356

Unset `mode_` when initializing the zlib stream failed, so that we don’t try to call the zlib end functions (`deflateEnd()` etc.) when cleaning up in `ZCtx::Close()`. Fixes: nodejs#14178 Ref: nodejs#13098

Unset `mode_` when initializing the zlib stream failed, so that we don’t try to call the zlib end functions (`deflateEnd()` etc.) when cleaning up in `ZCtx::Close()`. Fixes: #14178 Ref: #13098 PR-URL: #14666 Reviewed-By: Refael Ackermann <refack@gmail.com> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Alexey Orlenko <eaglexrlnk@gmail.com>

This is a partial backport of semver-patch bits of 9e4660b. This commit fixes the Node process crashing when constructors of classes of the zlib module are given invalid options. * Throw an Error when the zlib library rejects the value of windowBits, instead of crashing with an assertion. * Treat windowBits and memLevel options consistently with other ones and don't crash when non-numeric values are given. PR-URL: nodejs#13098 Fixes: nodejs#13082 Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Luigi Pinca <luigipinca@gmail.com> Reviewed-By: Sakthipriyan Vairamani <thechargingvolcano@gmail.com>

Unset `mode_` when initializing the zlib stream failed, so that we don’t try to call the zlib end functions (`deflateEnd()` etc.) when cleaning up in `ZCtx::Close()`. Fixes: nodejs#14178 Ref: nodejs#13098 PR-URL: nodejs#14666 Reviewed-By: Refael Ackermann <refack@gmail.com> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Alexey Orlenko <eaglexrlnk@gmail.com>

This is a partial backport of semver-patch bits of 9e4660b. This commit fixes the Node process crashing when constructors of classes of the zlib module are given invalid options. * Throw an Error when the zlib library rejects the value of windowBits, instead of crashing with an assertion. * Treat windowBits and memLevel options consistently with other ones and don't crash when non-numeric values are given. Backport-PR-URL: #14860 PR-URL: #13098 Fixes: #13082 Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Luigi Pinca <luigipinca@gmail.com> Reviewed-By: Sakthipriyan Vairamani <thechargingvolcano@gmail.com>

Unset `mode_` when initializing the zlib stream failed, so that we don’t try to call the zlib end functions (`deflateEnd()` etc.) when cleaning up in `ZCtx::Close()`. Fixes: #14178 Ref: #13098 Backport-PR-URL: #14860 PR-URL: #14666 Reviewed-By: Refael Ackermann <refack@gmail.com> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Alexey Orlenko <eaglexrlnk@gmail.com>

This is a partial backport of semver-patch bits of 9e4660b. This commit fixes the Node process crashing when constructors of classes of the zlib module are given invalid options. * Throw an Error when the zlib library rejects the value of windowBits, instead of crashing with an assertion. * Treat windowBits and memLevel options consistently with other ones and don't crash when non-numeric values are given. Backport-PR-URL: #14860 PR-URL: #13098 Fixes: #13082 Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Luigi Pinca <luigipinca@gmail.com> Reviewed-By: Sakthipriyan Vairamani <thechargingvolcano@gmail.com>

Unset `mode_` when initializing the zlib stream failed, so that we don’t try to call the zlib end functions (`deflateEnd()` etc.) when cleaning up in `ZCtx::Close()`. Fixes: #14178 Ref: #13098 Backport-PR-URL: #14860 PR-URL: #14666 Reviewed-By: Refael Ackermann <refack@gmail.com> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Alexey Orlenko <eaglexrlnk@gmail.com>

nodejs-github-bot added c++ Issues and PRs that require attention from people who are familiar with C++. zlib Issues and PRs related to the zlib subsystem. labels May 18, 2017

aqrln mentioned this pull request May 18, 2017

zlib assertion error #13082

Closed

addaleax reviewed May 18, 2017

View reviewed changes

squash! follow an alternative approach

c5440af

Throw an Error synchronously instead of fiddling with 'error' events.

aqrln force-pushed the fix-13082 branch from 046f91e to c5440af Compare May 18, 2017 13:06

addaleax approved these changes May 18, 2017

View reviewed changes

cjihrig approved these changes May 18, 2017

View reviewed changes

squash! address the feedback

c5f18b1

lpinca approved these changes May 18, 2017

View reviewed changes

thefourtheye reviewed May 18, 2017

View reviewed changes

zlib: fix bugs in the validation logic

e5c39bd

jasnell mentioned this pull request May 28, 2017

8.0.0 Release Proposal #12220

Closed

Fishrock123 added semver-major PRs that contain breaking changes and should be released in the next major version. and removed semver-major PRs that contain breaking changes and should be released in the next major version. labels Jun 5, 2017

MylesBorins mentioned this pull request Jul 18, 2017

v6.11.2 proposal #14356

Merged

This was referenced Aug 7, 2017

zlib: fix crash when initializing failed #14666

Closed

test: parallel/test-zlib-failed-init, intermittent crash #14178

Closed

aqrln mentioned this pull request Aug 16, 2017

(v4.x-backport) zlib: fix crash when initializing failed #14860

Closed

2 tasks

refack mentioned this pull request Aug 16, 2017

zlib crashes when given windowBits: 8 #14847

Closed

MylesBorins mentioned this pull request Sep 20, 2017

v4.8.5 proposal #15507

Closed

lpinca mentioned this pull request Oct 25, 2017

doc: releases avail for oct DOS sec vuln nodejs/nodejs.org#1420

Closed

MylesBorins mentioned this pull request Oct 25, 2017

v4.8.6 proposal #16500

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

zlib: fix node crashing on invalid options #13098

zlib: fix node crashing on invalid options #13098

aqrln commented May 18, 2017 •

edited

Loading

aqrln commented May 18, 2017

lpinca commented May 18, 2017 •

edited

Loading

aqrln commented May 18, 2017

lpinca commented May 18, 2017

addaleax May 18, 2017

aqrln May 18, 2017

addaleax May 18, 2017

aqrln May 18, 2017

addaleax May 18, 2017

aqrln May 18, 2017

addaleax May 18, 2017

aqrln commented May 18, 2017

lpinca commented May 18, 2017 •

edited

Loading

aqrln commented May 18, 2017

aqrln commented May 18, 2017

cjihrig left a comment

cjihrig May 18, 2017

cjihrig May 18, 2017

aqrln May 18, 2017

cjihrig May 18, 2017

cjihrig May 18, 2017

lpinca commented May 18, 2017

addaleax commented May 18, 2017

aqrln commented May 18, 2017

lpinca commented May 18, 2017

aqrln commented May 18, 2017

lpinca commented May 18, 2017 •

edited

Loading

lpinca left a comment

aqrln commented May 18, 2017

aqrln commented May 18, 2017

thefourtheye May 18, 2017

aqrln May 19, 2017

lpinca commented May 18, 2017

		SetDictionary(ctx);

		args.GetReturnValue().Set(Boolean::New(args.GetIsolate(), result));

		@@ -437,6 +437,10 @@ added: v0.5.8

		Returns a new [DeflateRaw][] object with an [options][].

		Note: zlib library rejects requests for 256-byte windows (i.e.,

zlib: fix node crashing on invalid options #13098

zlib: fix node crashing on invalid options #13098

Conversation

aqrln commented May 18, 2017 • edited Loading

Checklist

Affected core subsystem(s)

aqrln commented May 18, 2017

lpinca commented May 18, 2017 • edited Loading

aqrln commented May 18, 2017

lpinca commented May 18, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

aqrln commented May 18, 2017

lpinca commented May 18, 2017 • edited Loading

aqrln commented May 18, 2017

aqrln commented May 18, 2017

cjihrig left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

lpinca commented May 18, 2017

addaleax commented May 18, 2017

aqrln commented May 18, 2017

lpinca commented May 18, 2017

aqrln commented May 18, 2017

lpinca commented May 18, 2017 • edited Loading

lpinca left a comment

Choose a reason for hiding this comment

aqrln commented May 18, 2017

aqrln commented May 18, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

lpinca commented May 18, 2017

aqrln commented May 18, 2017 •

edited

Loading

lpinca commented May 18, 2017 •

edited

Loading

lpinca commented May 18, 2017 •

edited

Loading

lpinca commented May 18, 2017 •

edited

Loading