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@
mpi found where the r300 driver would not load on macppc due to an
undefined drisw_create_screen symbol.
The code related to that symbol was removed sometime after Mesa 11.0
branched.
Initial diff from and ok mpi@
operations and older CPUs lack the needed instructions. The hardware
supported by that driver will never be used together those older CPUs.
This might mean that even the software rasterizer doesn't work anymore on
those. But they're so slow that you probably wouldn't want to anyway.
ok jsg@
xterm -fa mono (underscores disappearing because the glyph exceeds
the cell size), matthieu@ can't remember why he enabled it, and it's
not enabled by default anywhere else. ok matthieu@
the address of a function argument which triggers a gcc ICE on sparc64
resulting in libdrm_radeon not being built as reported by naddy.
kettenis pointed out that while other architectures probably spill the
argument onto the stack this is likely not the case on register window
architectures like SPARC and suggested passing a pointer as an argument
instead which avoids the ICE and allows the drm libraries requiring
atomics to build on sparc64 again.
ok kettenis@ matthieu@
architecture-specific. This prevents us from trying to establish
write-combining mappings on other architectures, which in turn makes
non-kms pci video drivers work again on those platforms.
ok mlarkin@
This is needed by glamor egl in the xserver which is in turn needed
to get acceleration with some hardware on xf86-video-ati.
Worked on during s2k15. Glamor is not yet enabled in the xserver,
but adding this now as libepoxy recently showed up in ports.
The libepoxy port will be removed and ports will transition to
this version. The xenocara version will be enabled when we're
ready to transition.
Contains fixes for following issues:
CVE-2015-1802: bdfReadProperties: property count needs range check
CVE-2015-1803: bdfReadCharacters: bailout if a char's bitmap cannot be read
CVE-2015-1804: bdfReadCharacters: ensure metrics fit into xCharInfo struct
those are the only archs that currently use gallium radeon drivers.
It should build anywhere that has the libdrm radeon headers
installed. And while that should really be everywhere it
isn't at the moment and won't be for release.
It isn't clear why the radeon winsys in Mesa 10.4 didn't have
the same problem.
Found the hard way by todd@ on alpha.
This is desirable as the chromium port now uses this extension to
obtain pci vendor/device ids for use in feature/extension blacklists.
Prompted by a mail from byrnet@, tested on r600g by krw@
The newly added os_get_total_physical_memory() was passing the length of
a pointer rather than the type which made the sysctl call fail on
non 64 bit archs. And it was passing the wrong pointer for the result.
Fixes for these problems have been submitted back upstream.
With 10.4.3 gpu compositing on chromium would result in a black window
on older Intel parts (ie x60s with 945gm) and at least some discrete
Radeon parts. These problems do not seem to occur on recent Intel
parts, though those have coherent memory and hardware contexts.
It isn't clear what changes in Mesa are involved in the problem
though it also occurs with the 10.3 branch.
libEGL against libgbm and libglapi.
The libgbm requirement comes from the drm EGL backend that was
enabled with the 10.2.3 update.
ok matthieu@ kettenis@
/etc/X11/app-defaults stays 1st in the libXt search path so, people
and ports can put customized versions there if needed.
If you didn't customize the versions in /etc/X11/app-defaults, they
should be removed to avoid future issues when one file changes.
discussed at g2k14 and ok ajacoutot@
As the functions check if the member pointers are NULL but not the
pointer to the struct itself.
Reworked version of a diff from ratchov@ who created it to prevent a
xserver crash on zaurus where there is no PCI.
'looks ok' matthieu@, ok deraadt@
gallium/targets/{r300,r600,radeonsi}/common/drm_target.c in the Mesa source
but cvs import ignores symlinks.
Change the directory we search for drm_target.c in to deal with this.
page directory. fixes the following X man 3 pages:
XTestCompareCurrentCursorWithWindow.man
XTestCompareCursorWithWindow.man XTestDiscard.man
XTestFakeButtonEvent.man XTestFakeKeyEvent.man
XTestFakeMotionEvent.man XTestFakeRelativeMotionEvent.man
XTestGrabControl.man XTestSetGContextOfGC.man
XTestSetVisualIDOfVisual.man
X Font Service Protocol & Font metadata file handling issues in libXfont
May 13, 2014
- CVE-2014-0209: integer overflow of allocations in font metadata file parsing
When a local user who is already authenticated to the X server adds
a new directory to the font path, the X server calls libXfont to open
the fonts.dir and fonts.alias files in that directory and add entries
to the font tables for every line in it. A large file (~2-4 gb) could
cause the allocations to overflow, and allow the remaining data read
from the file to overwrite other memory in the heap.
Affected functions: FontFileAddEntry(), lexAlias()
- CVE-2014-0210: unvalidated length fields when parsing xfs protocol replies
When parsing replies received from the font server, these calls do not
check that the lengths and/or indexes returned by the font server are
within the size of the reply or the bounds of the memory allocated to
store the data, so could write past the bounds of allocated memory when
storing the returned data.
Affected functions: _fs_recv_conn_setup(), fs_read_open_font(),
fs_read_query_info(), fs_read_extent_info(), fs_read_glyphs(),
fs_read_list(), fs_read_list_info()
- CVE-2014-0211: integer overflows calculating memory needs for xfs replies
These calls do not check that their calculations for how much memory
is needed to handle the returned data have not overflowed, so can
result in allocating too little memory and then writing the returned
data past the end of the allocated buffer.
Affected functions: fs_get_reply(), fs_alloc_glyphs(),
fs_read_extent_info()
Reported by Ilja van Sprundel of IOActive
Fixes by Alan Coopersmith of Oracle
sends (for example, XGetImage() replies in the X server) happen at non-glacial
speeds. Makes Firefox useable again on web pages with large images. Already
pushed upstream.
ok matthieu@
With help for handling ports breakage from at least landry@, naddy@,
ajacoutot@, jasper@, and dcoppa@. Thanks to all.
Need an up to date /etc/mtree/BSD.x11.dist (from a base system build)
before building.
