Corruption has again been reported on Intel hardware running Xorg with
the modesetting driver (which uses OpenGL based acceleration instead of
SNA acceleration the intel driver defaults to).
Reported in various forms on Sandy Bridge (X220), Ivy Bridge (X230) and
Haswell (X240). Confirmed to not occur with the intel driver but the
xserver was changed to default to the modesetting driver on >= gen4
hardware (except Ironlake).
One means of triggering this is to open a large pdf with xpdf on an
idle machine and highlight a section of the document.
There have been reports of gpu hangs on gen4 intel hardware
(T500 with GM45, X61 with 965GM) when starting Xorg as well.
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.
require python/bison a configure flag instead of the previous way of
testing whether python was found (which shouldn't be the case in
xenocara even with ports packages installed).
This is required when timestamps change on files causing targets to be
invoked that will break if python and bison aren't available and found
in path by the configure script.
- use BUILDFIRST
- have fontconfig use normal 'all' targets to make sure its files are built
- explicitly document the fontconfig lib order
okay matthieu@
out-of-bounds write caused by a heap-based buffer overflow related
to the t1_decoder_parse_charstrings function in psaux/t1decode.c
out-of-bounds write caused by a heap-based buffer overflow related
to the t1_builder_close_contour function in psaux/psobjs.c
From upstream via Arch Linux
OK matthieu@
atomic builtins on a 64 bit integer which is not supported on 32 bit powerpc.
Makes 3D work again on a PowerBook G4 with an ATI RV350 video card.
tweak and ok jsg@
After a cvs import timestamps change which triggers rules that attempt
to call python to regenerate files. When python is not found this
generates empty files that override those from the distfile, breaking
the build.
When building inside xenocara python is never found as the pkg paths
are not searched.
The existing code walks all of /dev looking for different types of drm
nodes. We just have primary nodes and can directly map the minor number
to a path.
ok kettenis@
Always return DRM_BUS_PCI for now. No non-pci drm drivers are in the
kernel and this is unlikely to change anytime soon as the existing ones
aren't permissively licensed.
ok kettenis@
This prevents autotools to try to rebuild themselve automagically
if configure.ac, Makefile.am or a few other have more recent time
stamps than the generated files.
It will allows to get rid of the NO_REORDER mechanism that touches
files in the source tree to ensure nothing gets rebuilt.
of the makekeys util. This means it's also rebuilt during install. First
as root during build, later by the BUILDUSER during release, which won't
be able to rewrite it, because it's now owned by root. With this result:
override rw-r--r-- root/wheel for ks_tables.h?
One step closer towards noperm release builds for xenocara.
ok matthieu
If an empty string is received from an x-server, do not underrun the
buffer by accessing "rep.nameLen - 1" unconditionally, which could end
up being -1.
From Tobias Stoeckmann / X.Org security advisory Oct 4, 2016
The Xv query functions for adaptors and encodings suffer from out of boundary
accesses if a hostile X server sends a maliciously crafted response.
A previous fix already checks the received length against fixed values but
ignores additional length specifications which are stored inside the received
data.
These lengths are accessed in a for-loop. The easiest way to guarantee a
correct processing is by validating all lengths against the remaining size
left before accessing referenced memory.
This makes the previously applied check obsolete, therefore I removed it.
From Tobias Stoeckmann / X.Org security advisory Oct 4, 2016
A lack of range checks in libXtst allows out of boundary accesses.
The checks have to be done in-place here, because it cannot be done
without in-depth knowledge of the read data.
If XRecordStartOfData, XRecordEndOfData, or XRecordClientDied
without a client sequence have attached data, an endless loop would
occur. The do-while-loop continues until the current index reaches
the end. But in these cases, the current index would not be
incremented, leading to an endless processing.
From Tobias Stoeckmann / X.Org security advisory Oct 4, 2016
Individual lengths inside received server data can overflow
the previously reserved memory.
It is therefore important to validate every single length
field to not overflow the previously agreed sum of all invidual
length fields.
From Tobias Stoeckmann / X.Org security advisory Oct 4, 2016
The memory for filter names is reserved right after receiving the reply.
After that, filters are iterated and each individual filter name is
stored in that reserved memory.
The individual name lengths are not checked for validity, which means
that a malicious server can reserve less memory than it will write to
during each iteration.
From Tobias Stoeckmann / X.Org security advisory Oct 4, 2016
The responses of the connected X server have to be properly checked
to avoid out of boundary accesses that could otherwise be triggered
by a malicious server.
From Tobias Stoeckmann / X.Org security advisory Oct 4, 2016
By validating length fields from server responses, out of boundary
accesses and endless loops can be mitigated.
From Tobias Stoeckmann / X.Org security advisory Oct 4, 2016
The 32 bit field "rep.length" is not checked for validity, which allows
an integer overflow on 32 bit systems.
A malicious server could send INT_MAX as length, which gets multiplied
by the size of XRectangle. In that case the client won't read the whole
data from server, getting out of sync.
From Tobias Stoeckmann / X.Org security advisory Oct 4, 2016
Check if enough bytes were received for specified image type and
geometry. Otherwise GetPixel and other functions could trigger an
out of boundary read later on.
From Tobias Stoeckmann / X.Org security advisory Oct 4, 2016
gets used if allocating W|X memory fails, which is probably a bit slower.
However, that is much better than commit a W^X violation which currently
gets you killed.
ok jca@
