Red Hat Bugzilla – Bug 1285413
CVE-2015-8380 pcre: OOB write when pcre_exec() is called with ovecsize of 1 (8.38/10)
Last modified: 2017-08-02 15:51:53 EDT
A heap-based buffer overflow vulnerability was found in pcre_exec causing crash. Upstream bug (contains reproducer): https://bugs.exim.org/show_bug.cgi?id=1637 Upstream patch: http://vcs.pcre.org/pcre?view=revision&revision=1565 CVE request: http://seclists.org/oss-sec/2015/q4/363
Created pcre tracking bugs for this issue: Affects: fedora-all [bug 1285415]
Upstream fixed it in 8.38 version. Reproducer is passing "printf '//\n\\O1\n'" output to pcretest under valgrind.
Created attachment 1099151 [details] Upstream fix
Created attachment 1099152 [details] Fix ported to Fedora 22's 8.37 version
pcre-8.38-1.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.
pcre-8.37-7.fc22 has been pushed to the Fedora 22 stable repository. If problems still persist, please make note of it in this bug report.
I can reproduce OOB write starting with upstream version 8.31. The actual problematic code was introduced earlier, in version 8.13, in this commit: http://vcs.pcre.org/pcre?view=revision&revision=615 I have not tried to investigate why OOB write is not reproducible in version 8.13 - 8.30. I do not think this should be considered a security flaw. This problem is not triggered by a malicious pattern or malicious input, but by incorrect arguments passed to pcre_exec(). The function accepts the following arguments among others: ovector Points to a vector of ints for result offsets ovecsize Number of elements in the vector (a multiple of 3) The pcretest tool allows specifying ovecsize using \O used on the data line. It does not ensure the value specified is actually multiple of 3, and allows ovecsize 1, which triggers this problem. So the fix applied in r1565 seems to add safeguard against incorrect use of PCRE API.