[llvm-bugs] [Bug 48649] New: unsafe pointer arithmetic in llvm_regcomp()

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=48649

            Bug ID: 48649
           Summary: unsafe pointer arithmetic in llvm_regcomp()
           Product: libraries
           Version: trunk
          Hardware: All
                OS: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Support Libraries
          Assignee: unassignedbugs at nondot.org
          Reporter: miod at trust-in-soft.com
                CC: llvm-bugs at lists.llvm.org

llvm/lib/Support/regcomp.c is borrowed from OpenBSD, to which the following
issue has been reported and fixed. (report and patch in
https://marc.info/?l=openbsd-tech&m=160923823113340&w=2 )

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 on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20210104/5c71fac3/attachment-0001.html>