[Bug 252403] unsafe pointer arithmetic in regcomp()
bugzilla-noreply at freebsd.org
bugzilla-noreply at freebsd.org
Mon Jan 4 07:57:01 UTC 2021
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=252403
Bug ID: 252403
Summary: unsafe pointer arithmetic in regcomp()
Product: Base System
Version: Unspecified
Hardware: Any
OS: Any
Status: New
Severity: Affects Only Me
Priority: ---
Component: bin
Assignee: bugs at FreeBSD.org
Reporter: miod at online.fr
Created attachment 221266
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=221266&action=edit
suggested patch to fix the issue
regcomp.c uses the "start + count < end" idiom to check that there are "count"
bytes available in an array of char "start" and "end" both point to.
This is fine, unless "start + count" goes beyond the last element of the array.
In this case, pedantic interpretation of the C standard makes the comparison of
such a pointer against "end" undefined, and optimizers from hell will happily
remove as much code as possible because of this.
An example of this occurs in regcomp.c's bothcases(), which defines bracket[3],
sets "next" to "bracket" and "end" to "bracket + 2". Then it invokes
p_bracket(), which starts with "if (p->next + 5 < p->end)"...
Because bothcases() and p_bracket() are static functions in regcomp.c, there is
a real risk of miscompilation if aggressive inlining happens.
The following diff rewrites the "start + count < end" constructs into "end -
start > count". Assuming "end" and "start" are always pointing in the array
(such as "bracket[3]" above), "end - start" is well-defined and can be compared
without trouble.
As a bonus, MORE2() implies MORE() therefore SEETWO() can be simplified a bit.
--
You are receiving this mail because:
You are the assignee for the bug.
More information about the freebsd-bugs
mailing list