OpenBSD X11 changes summary for 2017-10-14 ==========================================
lib xserver == lib =============================================================== 01/02 == http://cvsweb.openbsd.org/cgi-bin/cvsweb/X11/lib lib ~ libXfont/src/fontfile/fontdir.c > MFC: Check for end of string in PatternMatch (CVE-2017-13720) > If a pattern contains '?' character, any character in the string is > skipped, > even if it is '\0'. The rest of the matching then reads invalid memory. > (matthieu@) ~ libXfont/src/bitmap/pcfread.c > MFC: pcfGetProperties: Check string boundaries (CVE-2017-13722) > Without the checks a malformed PCF file can cause the library to make > atom from random heap memory that was behind the `strings` buffer. > This may crash the process or leak information. (matthieu@) == xserver =========================================================== 02/02 == http://cvsweb.openbsd.org/cgi-bin/cvsweb/X11/xserver xserver ~ Xext/shm.c > MFC: Xext/shm: Validate shmseg resource id (CVE-2017-13721) > Otherwise it can belong to a non-existing client and abort X server with > FatalError "client not in use", or overwrite existing segment of another > existing client. (matthieu@) ~ xkb/xkbtext.c > MFC: xkb: Escape non-printable characters correctly > XkbStringText escapes non-printable characters using octal numbers. > Such escape sequence would be at most 5 characters long ("\0123"), so > it reserves 5 bytes in the buffer. Due to char->unsigned int > conversion, it would print much longer string for negative numbers. > (matthieu@) ~ xkb/xkbtext.c > MFC: xkb: Handle xkb formated string output safely (CVE-2017-13723) > Generating strings for XKB data used a single shared static buffer, > which offered several opportunities for errors. Use a ring of > resizable buffers instead, to avoid problems when strings end up > longer than anticipated. (matthieu@) ~ os/io.c > MFC: os: Make sure big requests have sufficient length. > A client can send a big request where the 32B "length" field has value > 0. When the big request header is removed and the length corrected, > the value will underflow to 0xFFFFFFFF. Functions processing the > request later will think that the client sent much more data and may > touch memory beyond the receive buffer. (matthieu@) ~ Xext/panoramiX.c ~ Xext/saver.c ~ Xext/xres.c ~ Xext/xvdisp.c ~ hw/dmx/dmxpict.c ~ pseudoramiX/pseudoramiX.c ~ render/render.c > MFC: Unvalidated lengths > v2: Add overflow check and remove unnecessary check (Julien Cristau) > This addresses: > CVE-2017-12184 in XINERAMA > CVE-2017-12185 in MIT-SCREEN-SAVER > CVE-2017-12186 in X-Resource > CVE-2017-12187 in RENDER (matthieu@) ~ xfixes/cursor.c ~ xfixes/region.c ~ xfixes/saveset.c ~ xfixes/xfixes.c > MFC: xfixes: unvalidated lengths (CVE-2017-12183) > v2: Use before swap (Jeremy Huddleston Sequoia) > v3: Fix wrong XFixesCopyRegion checks (Alan Coopersmith) (matthieu@) ~ Xext/vidmode.c ~ hw/xfree86/common/xf86DGA.c ~ hw/xfree86/dri/xf86dri.c > MFC: hw/xfree86: unvalidated lengths > This addresses: > CVE-2017-12180 in XFree86-VidModeExtension > CVE-2017-12181 in XFree86-DGA > CVE-2017-12182 in XFree86-DRI (matthieu@) ~ Xi/xibarriers.c > MFC: Xi: Test exact size of XIBarrierReleasePointer > Otherwise a client can send any value of num_barriers and cause > reading or swapping of values on heap behind the receive buffer. > (matthieu@) ~ Xi/xibarriers.c > MFC: Xi: integer overflow and unvalidated length in > (S)ProcXIBarrierReleasePointer > [jcristau: originally this patch fixed the same issue as commit > 211e05ac85 "Xi: Test exact size of XIBarrierReleasePointer", with the > addition of these checks] > This addresses CVE-2017-12179 (matthieu@) ~ Xi/xichangehierarchy.c > MFC: Xi: fix wrong extra length check in ProcXIChangeHierarchy > (CVE-2017-12178) (matthieu@) ~ dbe/dbe.c > MFC: dbe: Unvalidated variable-length request in > ProcDbeGetVisualInfo (CVE-2017-12177) > v2: Protect against integer overflow (Alan Coopersmith) (matthieu@) ~ dix/dispatch.c > MFC: Unvalidated extra length in ProcEstablishConnection (CVE-2017-12176) > (matthieu@) =============================================================================== _______________________________________________ odc mailing list [email protected] http://www.squish.net/mailman/listinfo/odc
