diff options
Diffstat (limited to 'xorg-server-hwcursor-gamma/0001-os-make-sure-the-clientsWritable-fd_set-is-initializ.patch')
| -rw-r--r-- | xorg-server-hwcursor-gamma/0001-os-make-sure-the-clientsWritable-fd_set-is-initializ.patch | 63 |
1 files changed, 63 insertions, 0 deletions
diff --git a/xorg-server-hwcursor-gamma/0001-os-make-sure-the-clientsWritable-fd_set-is-initializ.patch b/xorg-server-hwcursor-gamma/0001-os-make-sure-the-clientsWritable-fd_set-is-initializ.patch new file mode 100644 index 0000000..b3a7d2e --- /dev/null +++ b/xorg-server-hwcursor-gamma/0001-os-make-sure-the-clientsWritable-fd_set-is-initializ.patch @@ -0,0 +1,63 @@ +From 7cc7ffd25d5e50b54cb942d07d4cb160f20ff9c5 Mon Sep 17 00:00:00 2001 +From: Martin Peres <martin.peres@linux.intel.com> +Date: Fri, 17 Jul 2015 17:21:26 +0300 +Subject: [PATCH] os: make sure the clientsWritable fd_set is initialized + before use + +In WaitForSomething(), the fd_set clientsWritable may be used unitialized when +the boolean AnyClientsWriteBlocked is set in the WakeupHandler(). This leads to +a crash in FlushAllOutput() after x11proto's commit +2c94cdb453bc641246cc8b9a876da9799bee1ce7. + +The problem did not manifest before because both the XFD_SIZE and the maximum +number of clients were set to 256. As the connectionTranslation table was +initalized for the 256 clients to 0, the test on the index not being 0 was +aborting before dereferencing the client #0. + +As of commit 2c94cdb453bc641246cc8b9a876da9799bee1ce7 in x11proto, the XFD_SIZE +got bumped to 512. This lead the OutputPending fd_set to have any fd above 256 +to be uninitialized which in turns lead to reading an index after the end of +the ConnectionTranslation table. This index would then be used to find the +client corresponding to the fd marked as pending writes and would also result +to an out-of-bound access which would usually be the fatal one. + +Fix this by zeroing the clientsWritable fd_set at the beginning of +WaitForSomething(). In this case, the bottom part of the loop, which would +indirectly call FlushAllOutput, will not do any work but the next call to +select will result in the execution of the right codepath. This is exactly what +we want because we need to know the writable clients before handling them. In +the end, it also makes sure that the fds above MaxClient are initialized, +preventing the crash in FlushAllOutput(). + +Thanks to everyone involved in tracking this one down! + +Reported-by: Karol Herbst <freedesktop@karolherbst.de> +Reported-by: Tobias Klausmann <tobias.klausmann@mni.thm.de> +Signed-off-by: Martin Peres <martin.peres@linux.intel.com> +Tested-by: Martin Peres <martin.peres@linux.intel.com> +Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91316 +Cc: Ilia Mirkin <imirkin@alum.mit.edu> +Cc: Martin Peres <martin.peres@linux.intel.com> +Cc: Olivier Fourdan <ofourdan@redhat.com +Cc: Adam Jackson <ajax@redhat.com> +Cc: Alan Coopersmith <alan.coopersmith@oracle.com +Cc: Chris Wilson <chris@chris-wilson.co.uk> +--- + os/WaitFor.c | 1 + + 1 file changed, 1 insertion(+) + +diff --git a/os/WaitFor.c b/os/WaitFor.c +index 431f1a6..993c14e 100644 +--- a/os/WaitFor.c ++++ b/os/WaitFor.c +@@ -158,6 +158,7 @@ WaitForSomething(int *pClientsReady) + Bool someReady = FALSE; + + FD_ZERO(&clientsReadable); ++ FD_ZERO(&clientsWritable); + + if (nready) + SmartScheduleStopTimer(); +-- +2.4.5 + |