server: Add API to protect access to an SHM buffer
authorNeil Roberts <neil@linux.intel.com>
Wed, 13 Nov 2013 15:32:05 +0000 (15:32 +0000)
committerKristian Høgsberg <krh@bitplanet.net>
Thu, 14 Nov 2013 00:31:28 +0000 (16:31 -0800)
commitcf4f5995dce400b2feaf9875d5bbc7c42a99f905
treed371d3a0b22fd13e00ff1d9ee40649943e0d70c8
parent05f95c85c8cad07bee233f1d4e205a12538365e1
server: Add API to protect access to an SHM buffer

Linux will let you mmap a region of a file that is larger than the
size of the file. If you then try to read from that region the process
will get a SIGBUS signal. Currently the clients can use this to crash
a compositor because it can create a pool and lie about the size of
the file which will cause the compositor to try and read past the end
of it. The compositor can't simply check the size of the file to
verify that it is big enough because then there is a race condition
where the client may truncate the file after the check is performed.

This patch adds the following two public functions in the server API
which can be used wrap access to an SHM buffer:

void wl_shm_buffer_begin_access(struct wl_shm_buffer *buffer);
void wl_shm_buffer_end_access(struct wl_shm_buffer *buffer);

The first time wl_shm_buffer_begin_access is called a signal handler
for SIGBUS will be installed. If the signal is caught then the buffer
for the current pool is remapped to an anonymous private buffer at the
same address which allows the compositor to continue without crashing.
The end_access function will then post an error to the buffer
resource.

The current pool is stored as part of some thread-local storage so
that multiple threads can safely independently access separate
buffers.

Eventually we may want to add some more API so that compositors can
hook into the signal handler or replace it entirely if they also want
to do some SIGBUS handling.
src/wayland-server.h
src/wayland-shm.c