-
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
[v10.x] buffer: fix crash for invalid index types #23795
Conversation
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.
IMHO this should be only for node10. Masking errors is bad practice, with possible security implications.
Let 11 crash until we implement a clearer error message.
@nodejs/tsc PTAL … if there are objections standing on Wednesday I’ll call for a vote. |
I don’t think this is a good one. I would prefer a PR that throwed a JS error instead of crashing. Why is that approach unfeasible? |
@mcollina I was going for the existing behavior on v10.9.0 and below to avoid a breaking change… I’d be happy to implement that as a semver-major follow up, or, if the TSC thinks it could land on v10.x and v11.x, we could make an exception and add typechecking in a patch release? Edit: I’ve also decided to not go for the breaking change because the fact that there’s an issue on this demonstrates that this does affect in-the-wild code. I fully agree with throwing, but I’d prefer to keep breaking changes semver-major… |
+1 as a follow-up semver-major. |
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.
LGTM since it just restores the previous behavior. A proper (semver-major?) fix would be nice but we don't have to fix it here.
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.
LGTM since it just restores the previous behavior. A proper (semver-major?) fix would be nice but we don't have to fix it here - or we can go with reverting 2555cb4 but I don't think it's necessary with this change.
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.
LGTM since it just restores the previous behavior. A proper (semver-major?) fix would be nice but we don't have to fix it here - or we can go with reverting 2555cb4 but I don't think it's necessary with this change.
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.
LGTM since it just restores the previous behavior. A proper (semver-major?) fix would be nice but we don't have to fix it here - or we can go with reverting 2555cb4 but I don't think it's necessary with this change.
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.
LGTM since it just restores the previous behavior. A proper (semver-major?) fix would be nice but we don't have to fix it here - or we can go with reverting 2555cb4 but I don't think it's necessary with this change.
(Oops, multiple reviews submitted during the GitHub outage) |
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.
+1 to backporting this, fixing the bug. Let me know what behavior everyone agrees with for the actual semver-major fix and I'll gladly open a PR.
BTW the bug (#23668) was opened for The actual bug (wyhaya/updns#7) is in https://github.com/wyhaya/updns/blob/4fb62c6fa6863089c8443d737ad1de61031280af/lib/parse.js#L125-L126 question.qtype.copy(buf, 12 + qname.length, question.qtype, 2)
question.qclass.copy(buf, 12 + qname.length + 2, question.qclass, 2) third argument is the buffer, and not a This module has been failing silently since the module was published, possibly leaking memory content. So IIUC we have a crash instead of a silent fail in the node10 line, and that is going like that into LTS? |
P.S. The previous behavior is undefined, it's not default to > const b = Buffer.allocUnsafe(1024);
> const c = Buffer.allocUnsafe(512);
> b.copy(c, 'not a valid offset');
512
> b.copy(c, '4');
508
> const d = Buffer.alloc(1)
> d[0]='8'.charCodeAt(0)
> b.copy(c, d);
504 So this PR is |
Summery:
|
After talking a bunch with @refack and doing a minimal bit of tinkering, it does seem like this does not quite restore the previous behavior. This might duplicate comments above by @refack, but this is a small behavior change: Node.js 10.9.0 (which is the version with the behavior we wish to restore): > var b = Buffer.allocUnsafe(1024)
undefined
> var c = Buffer.allocUnsafe(512)
undefined
> b.copy(c, '112', 600)
400
> b.copy(c, 112, 600)
400
> With this patch: $ ./node
> var b = Buffer.allocUnsafe(1024)
undefined
> var c = Buffer.allocUnsafe(512)
undefined
> b.copy(c, '112', 600)
424
> b.copy(c, 112, 600)
400
> Can we patch that up? Or is that not desirable for a reason I don't see? |
27aa8f6
to
b31dd6e
Compare
1036d6e
to
027082d
Compare
I’ve re-targeted this PR to v10.x, under the assumption that we can do something like #23840 a) for all affected methods and b) without significant performance impact. |
@nodejs/tsc ... We have two competing PRs addressing the same issue. We need a resolution. This PR is one option, #23875 is the other. |
I personally defer to the review of folks that know this code but would like to see something land ASAP so we can test 10.13.0 before pushing it out |
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.
LGTM
@MylesBorins for the record (as the person who originally made the change that broke things, sorry for that) I'd prefer this one over #23875 as long as it uses V8 functions that'll be deprecated soon. |
With regards to v10.x:
2555cb4 is the breaking commit that landed in v10.x (v10.10.0, although the changelog has this as c637d41b9d). #23795 is an attempt to fix the issue while #23875 is a revert. #23795 has a number of approvals, so IMHO can land as a fix. The alternative is to revert (#23875) and then immediately re-backport #22129 including the changes from #23795. |
@MylesBorins @richardlau I think all we need at this point is a green CI. We could either rebase out the commit that broke the bootstrap module count for Workers CI, or land #23876 as soon as we can. |
Resume Build CI: https://ci.nodejs.org/job/node-test-pull-request/18153/ |
Another attempt at CI: https://ci.nodejs.org/job/node-test-pull-request/18166/ |
Resume Build CI: https://ci.nodejs.org/job/node-test-pull-request/18176/ |
8b431ad
to
3f63297
Compare
2555cb4 introduced a crash when a non-number value was passed to `ParseArrayIndex()`. We do not always have JS typechecking for that in place, though. This returns back to the previous behavior of coercing values to integers, which is certainly questionable. Refs: nodejs#22129 Fixes: nodejs#23668
027082d
to
b617de0
Compare
I’ve removed #23625 from v10.x-staging. CI should be good now: https://ci.nodejs.org/job/node-test-pull-request/18181/ |
Resume CI again: https://ci.nodejs.org/job/node-test-pull-request/18186/ |
Another CI attempt: https://ci.nodejs.org/job/node-test-pull-request/18193/ |
I've reimplemented the workaround for #22006 |
landed in the v10.13.0-proposal branch in 2ba6010 |
2555cb4 introduced a crash
when a non-number value was passed to
ParseArrayIndex()
.We do not always have JS typechecking for that in place, though.
This returns back to the previous behavior of defaulting to
0
,which is certainly questionable.
Refs: #22129
Fixes: #23668
Checklist
make -j4 test
(UNIX), orvcbuild test
(Windows) passes