libX11: Changes to 'master'

[GitLab Mirror]

 src/FontNames.c |   16 ++++------------
 src/GetFPath.c  |   11 ++++++++---
 src/ListExt.c   |   19 ++++++++++---------
 3 files changed, 22 insertions(+), 24 deletions(-)

New commits:
commit e83722768fd5c467ef61fa159e8c6278770b45c2
Author: Tobias Stoeckmann <tobias at stoeckmann.org>
Date:   Fri Jul 27 16:38:00 2018 +0200

    Fixed crash on invalid reply (CVE-2018-14598).
    
    If the server sends a reply in which even the first string would
    overflow the transmitted bytes, list[0] (or flist[0]) will be set to
    NULL and a count of 0 is returned.
    
    If the resulting list is freed with XFreeExtensionList or
    XFreeFontPath later on, the first Xfree call:
    
        Xfree (list[0]-1)
     turns into
        Xfree (NULL-1)
    
    which will most likely trigger a segmentation fault.
    
    I have modified the code to return NULL if the first string would
    overflow, thus protecting the freeing functions later on.
    
    Signed-off-by: Tobias Stoeckmann <tobias at stoeckmann.org>

commit dbf72805fd9d7b1846fe9a11b46f3994bfc27fea
Author: Tobias Stoeckmann <tobias at stoeckmann.org>
Date:   Fri Jul 27 16:37:17 2018 +0200

    Fixed out of boundary write (CVE-2018-14600).
    
    The length value is interpreted as signed char on many systems
    (depending on default signedness of char), which can lead to an out of
    boundary write up to 128 bytes in front of the allocated storage, but
    limited to NUL byte(s).
    
    Casting the length value to unsigned char fixes the problem and allows
    string values with up to 255 characters.
    
    Signed-off-by: Tobias Stoeckmann <tobias at stoeckmann.org>

commit b469da1430cdcee06e31c6251b83aede072a1ff0
Author: Tobias Stoeckmann <tobias at stoeckmann.org>
Date:   Fri Jul 27 16:36:34 2018 +0200

    Fixed off-by-one writes (CVE-2018-14599).
    
    The functions XGetFontPath, XListExtensions, and XListFonts are
    vulnerable to an off-by-one override on malicious server responses.
    
    The server replies consist of chunks consisting of a length byte
    followed by actual string, which is not NUL-terminated.
    
    While parsing the response, the length byte is overridden with '\0',
    thus the memory area can be used as storage of C strings later on. To
    be able to NUL-terminate the last string, the buffer is reserved with
    an additional byte of space.
    
    For a boundary check, the variable chend (end of ch) was introduced,
    pointing at the end of the buffer which ch initially points to.
    Unfortunately there is a difference in handling "the end of ch".
    
    While chend points at the first byte that must not be written to,
    the for-loop uses chend as the last byte that can be written to.
    
    Therefore, an off-by-one can occur.
    
    I have refactored the code so chend actually points to the last byte
    that can be written to without an out of boundary access. As it is not
    possible to achieve "ch + length < chend" and "ch + length + 1 > chend"
    with the corrected chend meaning, I removed the inner if-check.
    
    Signed-off-by: Tobias Stoeckmann <tobias at stoeckmann.org>