1476409 - Fix a case where we could accidentally overrun by one source text currently being tokenized

Status: RESOLVED FIXED

(Core :: JavaScript Engine, enhancement)

Description

[Jeff Walden [:Waldo]]

This is not a security concern, just an assertion failure.

Immediately after the bad line we proceed to call |getCodeUnit()| which has a bounds-check that was conservatively written as |ptr >= limit_| and will cause that call to return EOF, so we'll stop just fine.

The single-code-unit overread is of course not good, but it too shouldn't cause issues -- except maybe extraordinarily rarely.  We can trigger the assertion above *only* if the next code unit is '\n', which can be guaranteed using a two-byte dependent string, but then we're reading from known valid memory.  Otherwise the only way to hit it is if it *happens* the script text gets allocated by the embedder such that the next code unit after it is in unallocated memory -- but then either you read something not-'\n' and don't overrun, or you read '\n' and fall into safe code as noted above.  Or the memory is totally unallocated and you safely pagefault.

This test at least will detect the assertion in the dependent-string case.  Short of a shell helper to set up memory *just so* to trigger the next-code-unit-is-unallocated case, this is the most a testcase can do.  And that's either good enough, or overkill anyway.

Comment 1

[Jeff Walden [:Waldo]]

Attachment: Patch

Comment 2

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/0e23f233f5cf
Fix a case where during tokenization we could overread source text by one code unit -- but safely, due to conservatively-written subsequent code.  r=arai

Comment 3

[Eliza Balazs [:ebalazs_]]

https://hg.mozilla.org/mozilla-central/rev/0e23f233f5cf