On OpenBSD, we need the console fd to query wsdisplay type,
This was only causing problems with -keepPriv, since the privilege
separation code already calls xf86OpenConsole() earlier.
The function is idempotent, so there's no harm calling it
several times.
ok kettenis@
It was previously disabled by a broken test for XdmcpWrap() in xdm and
later in xenodm but it won't be missed. (use of DES, no IPv6 support).
ok tb@ mortimer@
and we held out hope too long. This will break some stuff. Let's start
with non-setuid as the baseline, and see if it is worth trying to fix
the broken parts in some other way.
their fds over to the parent proc. Knowing this then we already have a list of
all possible devices that might be opened in the future, in struct okdev
allowed_devices[], and we just need to traverse them and unveil(2) each one
with read/write permissions.
positive feedback from semarie@, OK matthieu@
--enable-glamor has changed from 'no' to 'auto'.
This makes an error running configure on luna88k, so disable it
explicitly with ${XENOCARA_BUILD_GL}=no machines.
ok jsg@
and NOTE_CHANGE to notify the desktop environment to deal with
the change (e.g. after plugging in an HDMI cable)
with this change there is no need to manually do any randr commands
if your desktop environment supports it (gnome, mate, kde, etc.)
ok matthieu@, kettenis@
(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
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
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.
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.
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.
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.
stsp@ reported that modesetting(4) has been reported unreliable
on his laptop, while intel(4) works.
XXXX to be removed after 6.2 to figure out and fix the issue.
ok kettenis@, also discussed briefly with deraadt@ during EuroBSDCon.
It is supposed to be slow, and when such instructions are used to copy
data from/to mapped video memory, some hypervisors (e.g. KVM,
Microsoft Hyper-V) can generate SIGILL or SIGBUS exceptions, causing
Xorg to crash.
Bug report to OpenBSD by Max Parmer, fix from FreeBSD (Dimitry Andric)
via kettenis@
ok kettenis@
care of autoconfiguration based on the information returned by the
WSDISPLAYIO_GTYPE ioctl of the console FD. This should fix selection of
wsfb on loongson and sgi when using a non-KMS kernel driver.
ok matthieu@, jsg@
later. This matches what several Linux distros do these days as it tends to
work better than the intel driver in most cases.
There are some performance issues with vncviewer on at least Ivy Bridge and
Haswell. But for now that regression outweighs the benefits.
ok robert@, tedu@, sthen@
