Fix epcre heap overflow in repeat_max bounds checking. #1111

Closed
wants to merge 2 commits into
from

Projects

None yet

5 participants

@zv
zv commented Jun 21, 2016

Erlang's PCRE library is prone to a heap overflow vulnerability. Due to insufficient
bounds checking inside compile_branch(), the heap memory could be overflowed
via a crafted regular expression.

The patch for this bug is a riff off a related bug in PCRE, although this patch covers additional errors also found while while subjecting ERTS to the full KLEE symbolic execution treatment.

@zv zv changed the title from Pcre repeatmax bug to Fix epcre heap overflow in repeat_max bounds checking. Jun 21, 2016
@OTP-Maintainer

The summary line of the commit message is too long and/or ends with a "."
Make sure the whole message follows the guidelines here: https://github.com/erlang/otp/wiki/Writing-good-commit-messages.

Bad message: Fix bugs caused by (?!) as a condition (which is converted to OP_FAIL)


I am a script, I am not human


@garazdawi
Contributor

PR put in waiting for patch to comply with same format as mentioned in #1107

@garazdawi garazdawi added the waiting label Jun 30, 2016
@zv
zv commented Jun 30, 2016

@garazdawi The commit line format?

@garazdawi
Contributor

@zv apparently I wasn't clear in what I wrote in #1107. In order to accept these patches to pcre we need you to change the pull requests so that they look like 6138bb6#diff-59347161e18d98230b255e855ff51f84.

@garazdawi garazdawi was assigned by psyeugenic Aug 1, 2016
@garazdawi
Contributor

Closing this due to inactivity, please open a new PR when/if you decide to get back to it.

@garazdawi garazdawi closed this Aug 8, 2016
@okeuday
Contributor
okeuday commented Aug 8, 2016

@garazdawi Is there any bug or issue filed so that PCRE can be updated independently, through a NIF or some other route? I ask because this seems like a problem with maintaining a very old version of PCRE that has forked from the main development and prevents Erlang/OTP from benefiting from fixes, or is this situation by design, better the bug you know than the bug you don't know?

@garazdawi
Contributor

@okeuday There are two larger problems with not using our own pcre. First of all it is not yielding, so it would have to execute in a separate thread with the overhead associated with that. Secondly I cannot find any modern windows pcre dll that we can use, so that needs to be solved somehow.

I don't know what the best route to take with this is. There is as of right now no planned work to make any changes in this area.

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