mirror of
https://gitlab.freedesktop.org/wayland/wayland.git
synced 2025-10-29 05:40:16 -04:00
50ea9c5b1c
Due to what is arguably a mistake in the C language specification, passing NULL to memcpy and friends is undefined behavior (UB) even when the count is 0. C additionally mistakenly leaves NULL + 0 and NULL - NULL undefined. (C++ fixes this mistake.) These are very problematic because (NULL, 0) is a natural representation of the empty slice. Some details: https://github.com/llvm/llvm-project/issues/49459 https://www.imperialviolet.org/2016/06/26/nonnull.html Unfortunately, despite how clearly this is a mistake, glibc headers and GCC now try to exploit this specification mistake and will miscompile code, so C projects need to workaround this. In particular, UBSan from Clang will flag this as a bug (although Clang itself has the good sense to never lean on this bug). We've run into a few UBSan errors in Chromium stemming from Wayland's memcpy calls. Add runtime guards as needed to avoid these cases. Note: Chromium's copy of wayland has https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/188 applied. It is possible the ring_buffer_copy UB cases are only reachable with that MR applied, I'm not sure. But it seemed simplest to just add the fix to wayland as-is. Then when/if that MR lands, it will pick this up. Signed-off-by: David Benjamin <davidben@google.com> |
||
|---|---|---|
| .. | ||
| .gitignore | ||
| connection.c | ||
| embed.py | ||
| event-loop.c | ||
| meson.build | ||
| scanner.c | ||
| wayland-client-core.h | ||
| wayland-client.c | ||
| wayland-client.h | ||
| wayland-os.c | ||
| wayland-os.h | ||
| wayland-private.h | ||
| wayland-server-core.h | ||
| wayland-server-private.h | ||
| wayland-server.c | ||
| wayland-server.h | ||
| wayland-shm.c | ||
| wayland-util.c | ||
| wayland-util.h | ||
| wayland-version.h.in | ||