Properly wrap the imsg_read() / imsg_get() calls in a while loop.
Do not initialize the fd of the struct ibuf to -1 (this is already done).
Rewrite the imsg parser using imsg_get_ibuf(), ibuf_get and a local new
function ibuf_get_string() which abstracts the extraction of the strings
from the ibuf.
Properly clear and free the user, pass and style variables.
OK tb@ matthieu@
implementations:
1) CVE-2023-6816 can be triggered by passing an invalid array index to
DeviceFocusEvent or ProcXIQueryPointer.
2) CVE-2024-0229 can be triggered if a device has both a button and a
key class and zero buttons.
3) CVE-2024-21885 can be triggered if a device with a given ID was
removed and a new device with the same ID added both in the same
operation.
4) CVE-2024-21886 can be triggered by disabling a master device with
disabled slave devices.
5) CVE-2024-0409 can be triggered by enabling SELinux
xserver_object_manager and running a client.
6) CVE-2024-0408 can be triggered by enabling SELinux
xserver_object_manager and creating a GLX PBuffer.
image format. This is a format with num_planes == 2, so we have only 2
elements in offsets[] and pitches[].
Bug found by otto@ using his strict malloc checking.
There are many places in X drivers where CARD64 is used mixed with uint64_t
and CARD32 mixed with uint32_t.
Initially the CARD* types were only meant to be used in the X protocol
definition and implementation. Later they got used in driver for fixed-
length unsigned integers as synonyms for uintxx_t types.
Unfortunatly on OpenBSD the definition of uint64_t and CARD64 don't match.
So take the bull by the horns and fix the CARDxx definitions using the
corresponding uintxx_t types from stdint.h.
our uint64_t is an unsinged long long, but CARD64 is defined as unsigned long
so the function pointer types in both glamor and xf86-video-amdgpu were
mismatched and clang-16 treats that as an error
ok matthieu@
LUNA's frame buffer is 'planar' type, not packed pixel. So use
shadowUpdateAfb8 as shadow framebuffer procedure to work 8bpp X
server.
It took 10 years to make X server colored on LUNA.
Originally inspired by NetBSD/amiga.
ok miod@
internally.
The functions wireToRawEvent() and copyRawEvent() get memories first,
then allocate memory blocks sequentially for several objects include
'double' from there.
On m88k, the memory area for 'double' should be 8-byte aligned, but
sizeof(XIRawEvent) is 60 and sizeof(out->valuators.mask_len) is 8.
In this case, allocated 'double' memory was not 8-byte aligned.
Because of this, 'xeyes' on luna88k was aborted with Bus Error right
after moving mouse for several years with sys/arch/m88k/m88k/trap.c
r.127.
Tested by me on luna88k, ok matthieu@
LUNA's video memory has 'linebytes * fPtr->info.height' bytes per 1
plane and the real visible area begins at 'offset' within that video
memory area, so it does not need to add 'offset' when mmap'ing video
memory.
Noticed by nono emulator.
ok miod@
For the gpu n, the main device node is /dev/dri/card<n> and the
render device node is /dev/dri/renderD<n+drmGetMinorBase()> not
/dev/dri/renderD<n>
and miod@ checked that no port should be affected.
