Date: Mon, 04 Jan 2021 07:57:01 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 252403] unsafe pointer arithmetic in regcomp() Message-ID: <bug-252403-227@https.bugs.freebsd.org/bugzilla/>
next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D252403 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@FreeBSD.org Reporter: miod@online.fr Created attachment 221266 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D221266&action= =3Dedit suggested patch to fix the issue regcomp.c uses the "start + count < end" idiom to check that there are "cou= nt" 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 ar= ray. In this case, pedantic interpretation of the C standard makes the compariso= n of such a pointer against "end" undefined, and optimizers from hell will happi= ly 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, ther= e 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 comp= ared without trouble. As a bonus, MORE2() implies MORE() therefore SEETWO() can be simplified a b= it. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-252403-227>