Re: [PATCH] os: Make sure big requests have sufficient length.

2017-10-09 Thread Michal Srb
On pondělí 9. října 2017 17:14:44 CEST Eric Anholt 
> I tried the updated testcase and that didn't crash for me, either.  My
> v2 (which I've now sent out) testcase times out in 30 seconds without
> the fix and passes with the fix.  I'd love your review if you like that
> as a solution.

PolyLine is not crashing because it has `if (npoint > 1)` test and the 
`npoint` (int) overflowed into negative numbers.

If you change the XCB_POLY_LINE into XCB_POLY_RECTANGLE in your test it is 
enough to crash X server on my machine.

Michal Srb
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH] os: Make sure big requests have sufficient length.

2017-10-09 Thread Eric Anholt
Peter Hutterer  writes:

> On Mon, Sep 25, 2017 at 12:55:47PM -0700, Eric Anholt wrote:
>> Michal Srb  writes:
>> 
>> > On neděle 24. září 2017 0:20:07 CEST Eric Anholt wrote:
>> >> Michal Srb  writes:
>> >> > Here is a script that can be used to crash X server using a broken big
>> >> > request for PolyLine. It connects to DISPLAY=:1 and doesn't support
>> >> > authentication. Look inside the script for more details.
>> >> > 
>> >> > Other requests could be used to crash X server in similar way, for 
>> >> > example
>> >> > SetFontPath.
>> >> 
>> >> I noticed this still in my mailbox.  I tried writing an mergeable unit
>> >> test for it at:
>> >> 
>> >> https://github.com/anholt/xserver/commit/d0e9d732750aa8eb7eeb33adce321f1dfee
>> >> f265d
>> >> 
>> >> but it doesn't manage to crash the server because I can't set the endian
>> >> mode using xcb (and xcb, sensibly, doesn't let me get an fd without
>> >> doing connection setup on it).
>> >> 
>> >> I don't know much about the codepath with the bug, but hopefully this
>> >> sparks some discussion.
>> >
>> > Hi,
>> >
>> > I think in your test case the underflow of the request length still 
>> > happens, 
>> > but it doesn't crash because nobody tries to access the data. It ends 
>> > inside 
>> > ProcPolyLine because the Drawable and the GC are not valid.
>> >
>> > In my test case the client was big endian, so it crashed inside SProcPoly 
>> > trying to swap the (incorrectly) huge request.
>> >
>> > I think if you supply valid Drawable and GC, you should get crash even 
>> > with 
>> > little endian.
>> 
>> I tried creating a gc against the root window and doing the drawing
>> there, but the request seems to process successfully.  bigreq branch
>> updated with that code.
>
> Following the path in the code, michal's patch is
> Reviewed-by: Peter Hutterer  though fixing the
> typos in the commit message would be good :)
>
> I think for the unit test you have to invert your approach. If you're
> supplying a zero-length big req then you should expect the server to
> complain. If it processes your request, then something is wrong.

I tried the updated testcase and that didn't crash for me, either.  My
v2 (which I've now sent out) testcase times out in 30 seconds without
the fix and passes with the fix.  I'd love your review if you like that
as a solution.


signature.asc
Description: PGP signature
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

[PATCH xserver] test: Add a test for the overflow bug in bigreqs.

2017-10-09 Thread Eric Anholt
The failing struct comes from the python test written by Michal Srb
.

v2: Use a drawable (root window) and gc, so that PolyLines hopefully
actually tries processing things.  However, the request seems to
process successfully so the poll() just stalls out.  However, this
does let us distinguish between detecting the bigrequests error
and not, at least.
v3: Clean up the description of what we expect the poll() call to do.

Signed-off-by: Eric Anholt 
---
 test/bigreq/meson.build  |  8 +
 test/bigreq/request-length.c | 71 
 test/meson.build |  1 +
 3 files changed, 80 insertions(+)
 create mode 100644 test/bigreq/meson.build
 create mode 100644 test/bigreq/request-length.c

diff --git a/test/bigreq/meson.build b/test/bigreq/meson.build
new file mode 100644
index ..9462ede31dca
--- /dev/null
+++ b/test/bigreq/meson.build
@@ -0,0 +1,8 @@
+xcb_dep = dependency('xcb', required: false)
+
+if get_option('xvfb')
+if xcb_dep.found()
+requestlength = executable('request-length', 'request-length.c', 
dependencies: xcb_dep)
+test('request-length', simple_xinit, args: [requestlength, '--', 
xvfb_server])
+endif
+endif
diff --git a/test/bigreq/request-length.c b/test/bigreq/request-length.c
new file mode 100644
index ..82d712e0624d
--- /dev/null
+++ b/test/bigreq/request-length.c
@@ -0,0 +1,71 @@
+/*
+ * Copyright © 2017 Broadcom
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+int main(int argc, char **argv)
+{
+xcb_connection_t *c = xcb_connect(NULL, NULL);
+xcb_screen_t *screen = xcb_setup_roots_iterator(xcb_get_setup(c)).data;
+xcb_gcontext_t gc = xcb_generate_id(c);
+int fd = xcb_get_file_descriptor(c);
+struct {
+uint8_t reqtype;
+uint8_t coordmode;
+uint16_t length;
+uint32_t length_bigreq;
+uint32_t drawable;
+uint32_t gc;
+} polyline_req = {
+.reqtype = XCB_POLY_LINE,
+.drawable = screen->root,
+.gc = gc,
+
+/* This is the value that triggers the bug. */
+.length_bigreq = 0,
+};
+
+xcb_create_gc(c, gc, screen->root, 0, NULL);
+
+free(xcb_big_requests_enable_reply(c, xcb_big_requests_enable(c), NULL));
+
+/* Manually write out the bad request.  XCB can't help us here.*/
+write(fd, &polyline_req, sizeof(polyline_req));
+
+/* Block until the server has processed our mess and throws an
+ * error.  If it never throws an error, then it probably did
+ * things wrong (either a crash, or "successfully" processing our
+ * broken request).
+ */
+struct pollfd pfd = {
+.fd = fd,
+.events = POLLIN,
+};
+poll(&pfd, 1, -1);
+
+return 0;
+}
diff --git a/test/meson.build b/test/meson.build
index 3e482d6f19cd..d413e9da5323 100644
--- a/test/meson.build
+++ b/test/meson.build
@@ -23,4 +23,5 @@ if get_option('xvfb')
 endif
 endif
 
+subdir('bigreq')
 subdir('sync')
-- 
2.14.2

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel