Re: Reporting Security Violations in Software Package

Yao Shuangjie <[email protected]> writes:

> We are cybersecurity researchers from the Hong Kong University of
> Science and Technology. We found several security violations of
> undefined behaviors in GNU bison 3.8.2 using our novel symbolic
> execution technique several months ago. The details are shown below.
>
> ../lib/obstack.c:138:35: runtime error: applying non-zero offset 10782085=
8999056 to null pointer
>     #0 0x6a3c9c in _obstack_begin_worker /root/projects/bison-3.8.2/obj-s=
an/../lib/obstack.c:138:35
>     #1 0x6a3a6d in _obstack_begin /root/projects/bison-3.8.2/obj-san/../l=
ib/obstack.c:157:10
>     #2 0x54988c in muscle_init /root/projects/bison-3.8.2/obj-san/../src/=
muscle-tab.c:126:3
>     #3 0x548e2f in main /root/projects/bison-3.8.2/obj-san/../src/main.c:=
97:3
>     #4 0x7f14c84cdd8f in __libc_start_call_main csu/../sysdeps/nptl/libc_=
start_call_main.h:58:16
>     #5 0x7f14c84cde3f in __libc_start_main csu/../csu/libc-start.c:392:3
>     #6 0x420664 in _start (/root/projects/bison-3.8.2/obj-san/src/bison+0=
x420664)

This is reported in Gnulib here [1].

It is not a bug, in the Gnulib documentation there is a warning about
this [2]:

Clang=E2=80=99s -fsanitize=3Dundefined option causes the program to crash i=
f it
adds zero to a null pointer =E2=80=93 behavior that is undefined in strict =
C,
but which yields a null pointer on all practical porting targets and
which the Gnulib portability guidelines allow.

If you use Clang with -fsanitize=3Dundefined, you can work around the
problem by also using =E2=80=98-fno-sanitize=3Dpointer-overflow=E2=80=99, a=
lthough this
may also disable some unrelated and useful pointer checks. Perhaps
someday the Clang developers will fix the infelicity.

Collin

[1] https://lists.gnu.org/archive/html/bug-gnulib/2023-12/msg00002.html
[2] https://www.gnu.org/software/gnulib/manual/html_node/Unsupported-Platfo=
rms.html