- Dec 15, 2021
-
-
Povilas Kanapickas authored
Signed-off-by:Povilas Kanapickas <povilas@radix.lt>
-
Initially reported downstream in Gentoo. Manifests with errors like: ``` gnu/bin/ld: hw/xfree86/common/libxorg_common.a(xf86fbBus.c.o): in function `xf86ClaimFbSlot': xf86fbBus.c:(.text+0x20): undefined reference to `sbusSlotClaimed' /usr/lib/gcc/sparc-unknown-linux-gnu/11.2.0/../../../../sparc-unknown-linux-gnu/bin/ld: xf86fbBus.c:(.text+0x2c): undefined reference to `sbusSlotClaimed' ``` While we use the headers in meson.build, we don't reference xf86sbusBus.c which defines the missing symbols like sbusSlotClaimed. Bug: https://bugs.gentoo.org/828513 Signed-off-by:
Sam James <sam@gentoo.org> (cherry picked from commit 6c1a1fcc)
-
Povilas Kanapickas authored
ZDI-CAN-14192, CVE-2021-4008 This vulnerability was discovered and the fix was suggested by: Jan-Niklas Sohn working with Trend Micro Zero Day Initiative Signed-off-by:
-
Povilas Kanapickas authored
ZDI-CAN-14951, CVE-2021-4010 This vulnerability was discovered and the fix was suggested by: Jan-Niklas Sohn working with Trend Micro Zero Day Initiative Signed-off-by:
-
Povilas Kanapickas authored
ZDI-CAN-14950, CVE-2021-4009 This vulnerability was discovered and the fix was suggested by: Jan-Niklas Sohn working with Trend Micro Zero Day Initiative Signed-off-by:
-
Povilas Kanapickas authored
ZDI-CAN-14952, CVE-2021-4011 This vulnerability was discovered and the fix was suggested by: Jan-Niklas Sohn working with Trend Micro Zero Day Initiative Signed-off-by:
-
With the new numbering scheme, XORG_VERISON_SNAP doesn't mean a pre-release version anymore. Signed-off-by:
Matthieu Herrb <matthieu@herrb.eu> (cherry picked from commit 4de9666b)
-
- Dec 10, 2021
-
-
Matt Turner authored
(cherry picked from commit d189102c)
-
- Dec 04, 2021
-
-
Povilas Kanapickas authored
This worked with autotools, but not meson build system. Signed-off-by:
-
Attempting to run fvwm on a x61/965gm with xserver 1.21.1 with the modesetting driver on OpenBSD/amd64 would cause the xserver to reliably crash. I tracked this down to the free() calls introduced in 2906ee5e (d1ca47e1 in branch). clang also warns about this: glamor_program.c:296:13: warning: variable 'vs_prog_string' is used uninitialized whenever 'if' condition is true [-Wsometimes-uninitialized] glamor_program.c:290:9: warning: variable 'vs_prog_string' is used uninitialized whenever 'if' condition is true [-Wsometimes-uninitialized] glamor_program.c:288:9: warning: variable 'vs_prog_string' is used uninitialized whenever 'if' condition is true [-Wsometimes-uninitialized] glamor_program.c:277:13: warning: variable 'vs_prog_string' is used uninitialized whenever 'if' condition is true [-Wsometimes-uninitialized] glamor_program.c:296:13: warning: variable 'fs_prog_string' is used uninitialized whenever 'if' condition is true [-Wsometimes-uninitialized] glamor_program.c:290:9: warning: variable 'fs_prog_string' is used uninitialized whenever 'if' condition is true [-Wsometimes-uninitialized] glamor_program.c:288:9: warning: variable 'fs_prog_string' is used uninitialized whenever 'if' condition is true [-Wsometimes-uninitialized] glamor_program.c:277:13: warning: variable 'fs_prog_string' is used uninitialized whenever 'if' condition is true [-Wsometimes-uninitialized] Signed-off-by:
Jonathan Gray <jsg@jsg.id.au> Reviewed-by:
Olivier Fourdan <ofourdan@redhat.com> Fixes: 2906ee5e ("glamor: Fix leak in glamor_build_program()") (cherry picked from commit 5ac63197)
-
The previous if/else condition resulted in us always setting the key type count to the current number of key types. Split this up correctly. Regression introduced in de940e06 Fixes #1249 Signed-off-by:
Peter Hutterer <peter.hutterer@who-t.net> (cherry picked from commit be16bd85)
-
- Dec 03, 2021
-
-
Povilas Kanapickas authored
Quite a lot of applications currently expect the screen DPI exposed by the X server to be 96 even when the real display DPI is different. Additionally, currently Xwayland completely ignores any hardware information and sets the DPI to 96. Accordingly the new behavior, even if it fixes a bug, should not be enabled automatically to all users. A better solution would be to make the default DPI stay as is and enable the correct behavior with a command line option (maybe -dpi auto, or similar). For now let's just revert the bug fix. This reverts commit 05b3c681. Signed-off-by:
-
(cherry picked from commit a7b0a7fa)
-
When switching to VT, the ioctl DRM_DROP_MASTER must be done before the ioctl VT_RELDISP. Otherwise the kernel can't change the modesetting reliably, and this leads to the console not showing up in some cases, like after unplugging a docking station with a DP or HDMI monitor. Before doing the VT_RELDISP, send a dbus message to logind, to pause the drm device, so logind will do the ioctl DRM_DROP_MASTER. With this patch, it changes the order logind will send the resume event, and drm will be sent last instead of first. so there is a also fix to call systemd_logind_vtenter() at the right time. Signed-off-by:
Jocelyn Falempe <jfalempe@redhat.com> Reviewed-by:
Hans de Goede <hdegoede@redhat.com> (cherry picked from commit da9d012a)
-
logind send the resume event for input devices and drm device, in any order. if we call vt_enter before logind resume the drm device, it leads to a driver error, because logind has not done the DRM_IOCTL_SET_MASTER on it. Keep the old workaround to make sure we call systemd_logind_vtenter at least once if there are no platform device Signed-off-by:
-
- Nov 23, 2021
-
-
(cherry picked from commit b8c12aac)
-
- Nov 06, 2021
-
-
Povilas Kanapickas authored
Signed-off-by: -
Povilas Kanapickas authored
-
Some drivers (mach64 w/o DRI for instance) don't initialize privates. Signed-off-by:
Matthieu Herrb <matthieu.herrb@laas.fr> (cherry picked from commit 80eeff3e)
-
-
- Oct 27, 2021
-
-
Povilas Kanapickas authored
Signed-off-by:
-
- Oct 21, 2021
-
-
Due to a switched order of parameters in the xorg_list_add() call inside ProcRRCreateLease(), adding a new lease for RandR output leasing does not actually add the new RRLeasePtr lease record to the list of existing leases for a X-Screen, but instead replaces the existing list with a new list that has the new lease as the only element, and probably leaks a bit of memory. Therefore the server "forgets" all active leases for a screen, except for the last added lease. If multiple leases are created in a session, then destruction of all leases but the last one will fail in many cases, e.g., during server shutdown in RRCloseScreen(), or resource destruction, e.g., in RRCrtcDestroyResource(). Most importantly, it fails if a client simply close(fd)'es the DRM master descriptor to release a lease, quits, gets killed or crashes. In this case the kernel will destroy the lease and shut down the display output, then send a lease event via udev to the ddx, which e.g., in the modesetting-ddx will trigger a call to drmmode_validate_leases(). That function is supposed to detect the released lease and tell the server to terminate the lease on the server side as well, via xf86CrtcLeaseTerminated(), but this doesn't happen for all the leases the server has forgotten. The end result is a dead video output, as the server won't reinitialize the crtc's corresponding to the terminated but forgotten lease. This bug was observed when using the amdvlk AMD OSS Vulkan driver and trying to lease multiple VKDisplay's, and also under Mesa radv, as both Mesa Vulkan/WSI/Display and amdvlk terminate leases by simply close()ing the lease fd, not by sending explicit RandR protocol requests to free leases. Leasing worked, but ending a session with multiple active leases ended in a lot of unpleasant darkness. Fixing the wrong argument order to xorg_list_add() fixes the problem. Tested on single-X-Screen and dual-X-Screen setups, with one, two or three active leases. Please merge this for the upcoming server 21.1 branch. Merging into server 1.20 would also make a lot of sense. Fixes: e4e34476 Signed-off-by:
Mario Kleiner <mario.kleiner.de@gmail.com> Cc: Keith Packard <keithp@keithp.com> (cherry picked from commit f467f85c)
-
- Oct 14, 2021
- Oct 08, 2021
-
-
Adding the offset between the realloc result and the old allocation to update pointers into the new allocation is undefined behaviour: the old pointers are no longer valid after realloc() according to the C standard. While this works on almost all architectures and compilers, it causes problems on architectures that track pointer bounds (e.g. CHERI or Arm's Morello): the DevPrivateKey pointers will still have the bounds of the previous allocation and therefore any dereference will result in a run-time trap. I found this due to a crash (dereferencing an invalid capability) while trying to run `XVnc` on a CHERI-RISC-V system. With this commit I can successfully connect to the XVnc instance running inside a QEMU with a VNC viewer on my host. This also changes the check whether the allocation was moved to use uintptr_t instead of a pointer since according to the C standard: "The value of a pointer becomes indeterminate when the object it points to (or just past) reaches the end of its lifetime." Casting to an integer type avoids this undefined behaviour. Signed-off-by:
Alex Richardson <Alexander.Richardson@cl.cam.ac.uk> (cherry picked from commit f9f705bf)
-
SimpleDRM 'devices' are a fallback device, and do not have a busid so they are getting skipped. This will allow simpledrm to work with the modesetting driver (cherry picked from commit b9218fad)
-
The "sync crtc" is the crtc used to drive the display timing of a drawable under DRI2 and DRI3/Present. If a drawable intersects multiple video outputs, then normally the crtc is chosen which has the largest intersection area with the drawable. If multiple outputs / crtc's have exacty the same intersection area then the crtc chosen was simply the first one with maximum intersection. Iow. the choice was random, depending on plugging order of displays. This adds the ability to choose a preferred output in such a tie situation. The RandR output marked as "primary output" is chosen on such a tie. This new behaviour and its implementation is consistent with other video ddx drivers. See amdgpu-ddx, ati-ddx and nouveau-ddx for reference. This commit is a straightforward port from amdgpu-ddx. Signed-off-by:
-
In a setup with both VRR capable and non-VRR capable displays, it was so far inconsistent if the driver would allow use of VRR support or not, as "is_connector_vrr_capable" was set to whatever the capabilities of the last added drm output were. Iow. the plugging order of monitors determined the outcome. Fix this: Now if at least one display is VRR capable, the driver will treat an X-Screen as capable for VRR, plugging order no longer matters. Tested with a dual-display setup with one VRR monitor and one non-VRR monitor. This is also beneficial with the new Option "AsyncFlipSecondaries". When we are at it, also add some so far missing description of the "VariableRefresh" driver option, copied from amdgpu-ddx. Signed-off-by:
-
A lut size of 4096 slots has been verified to work correctly, as tested with amdgpu-kms. Intel Tigerlake Gen12 hw has a very large GAMMA_LUT size of 262145 slots, but also issues with its current GAMMA_LUT implementation, as of Linux 5.14. Therefore we keep GAMMA_LUT off for large lut's. This currently excludes Intel Icelake, Tigerlake and later. This can be overriden via the "UseGammaLUT" boolean xorg.conf option to force use of GAMMA_LUT on or off. See following link for the Tigerlake situation: https://gitlab.freedesktop.org/drm/intel/-/issues/3916#note_1085315 Signed-off-by:
-
Commit 446ff2d3 added checks to prevalidate the size of incoming SetMap requests. That commit checks for the XkbSetMapResizeTypes flag to be set before allowing key types data to be processed. key types data can be changed or even just sent wholesale unchanged without the number of key types changing, however. The check for XkbSetMapResizeTypes rejects those legitimate requests. In particular, XkbChangeMap never sets XkbSetMapResizeTypes and so always fails now any time XkbKeyTypesMask is in the changed mask. This commit drops the check for XkbSetMapResizeTypes in flags when prevalidating the request length. (cherry picked from commit 8b7f4d32)
-
This reverts commit 617f591f. The problem described in that commit exists, but the two preceeding commits with improvements to the servers RandR code should avoid the mentioned problems while allowing the use of GAMMA_LUT's instead of legacy gamma lut. Use of legacy gamma lut's is not a good fix, because it will reduce color output precision of gpu's with more than 1024 GAMMA_LUT slots, e.g., AMD, ARM MALI and KOMEDA with 4096 slot luts, and some Mediathek parts with 512 slot luts. On KOMEDA, legacy lut's are completely unsupported by the kms driver, so gamma correction gets disabled. The situation is especially bad on Intel Icelake and later: Use of legacy gamma tables will cause the kms driver to switch to hardware legacy lut's with 256 slots, 8 bit wide, without interpolation. This way color output precision is restricted to 8 bpc and any deep color / HDR output (10 bpc, fp16, fixed point 16) becomes impossible. The latest Intel gen gpu's would have worse color precision than parts which are more than 10 years old. Signed-off-by:
-
The assumption in the upsampling code was that the crtc->gamma_size size of the crtc's gamma table is a power of two. This is true for almost all current driver + gpu combos at least on Linux, with typical sizes of 256, 512, 1024 or 4096 slots. However, Intel Gen-11 Icelake and later are outliers, as their gamma table has 2^18 + 1 slots, very big and not a power of two! Try to make upsampling behave at least reasonable: Replicate the last gamma value to fill up remaining crtc->gamma_red/green/blue slots, which would normally stay uninitialized. This is important, because while the intel display driver does not actually use all 2^18+1 values passed as part of a GAMMA_LUT, it does need the very last slot, which would not get initialized by the old code. This should hopefully create reasonable behaviour with Icelake+ but is untested on the actual Intel hw due to lack of suitable hw. Signed-off-by:
-
If randrp->palette_size is zero, the memcpy() path can read past the end of the randr_crtc's gammaRed/Green/Blue tables if the hw crtc's gamma_size is greater than the randr_crtc's gammaSize. Avoid this by clamping the to-be-copied size to the smaller of both sizes. Note that during regular server startup, the memcpy() path is only taken initially twice, but then a suitable palette is created for use during a session. Therefore during an actual running X-Session, the xf86RandR12CrtcComputeGamma() will be used, which makes sure that data is properly up- or down-sampled for mismatching source and target crtc gamma sizes. This should avoid reading past randr_crtc gamma memory for gpu's with big crtc->gamma_size, e.g., AMD/MALI/KOMEDA 4096 slots, or Intel Icelake and later with 262145 slots. Tested against modesetting-ddx and amdgpu-ddx under screen color depth 24 (8 bpc) and 30 (10 bpc) to make sure that clamping happens properly. This is an alternative fix for the one attempted in commit 617f591f. Signed-off-by:
-
Fix the possible leak of `vs_prog_string` and `fs_prog_string` in case of failure, as reported by covscan. Signed-off-by:
Michel Dänzer <mdaenzer@redhat.com> (cherry picked from commit 2906ee5e)
-
- Sep 21, 2021
-
-
Povilas Kanapickas authored
Signed-off-by:
-
- Sep 15, 2021
-
-
Povilas Kanapickas authored
-
- Sep 10, 2021
-
-
Aaron Plattner authored
The Linux version of xf86EnableIO calls a helper function called hwEnableIO(). Except on Alpha, this function reads /proc/ioports looking for the 'keyboard' and 'timer' ports, extracts the port ranges, and enables access to them. It does this by reading 4 bytes from the string for the start port number and 4 bytes for the last port number, passing those to atoi(). However, it doesn't add a fifth byte for a NUL terminator, so some implementations of atoi() read past the end of this string, triggering an AddressSanitizer error: ==1383==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7fff71fd5b74 at pc 0x7fe1be0de3e0 bp 0x7fff71fd5ae0 sp 0x7fff71fd5288 READ of size 5 at 0x7fff71fd5b74 thread T0 #0 0x7fe1be0de3df in __interceptor_atoi /build/gcc/src/gcc/libsanitizer/asan/asan_interceptors.cpp:520 #1 0x564971adcc45 in hwEnableIO ../hw/xfree86/os-support/linux/lnx_video.c:138 #2 0x564971adce87 in xf86EnableIO ../hw/xfree86/os-support/linux/lnx_video.c:174 #3 0x5649719f6a30 in InitOutput ../hw/xfree86/common/xf86Init.c:439 #4 0x564971585924 in dix_main ../dix/main.c:190 #5 0x564971b6246e in main ../dix/stubmain.c:34 #6 0x7fe1bdab6b24 in __libc_start_main (/usr/lib/libc.so.6+0x27b24) #7 0x564971490e9d in _start (/home/aaron/git/x/xserver/build.asan/hw/xfree86/Xorg+0xb2e9d) Address 0x7fff71fd5b74 is located in stack of thread T0 at offset 100 in frame #0 0x564971adc96a in hwEnableIO ../hw/xfree86/os-support/linux/lnx_video.c:118 This frame has 3 object(s): [32, 40) 'n' (line 120) [64, 72) 'buf' (line 122) [96, 100) 'target' (line 122) <== Memory access at offset 100 overflows this variable HINT: this may be a false positive if your program uses some custom stack unwind mechanism, swapcontext or vfork (longjmp and C++ exceptions *are* supported) SUMMARY: AddressSanitizer: stack-buffer-overflow /build/gcc/src/gcc/libsanitizer/asan/asan_interceptors.cpp:520 in __interceptor_atoi Shadow bytes around the buggy address: 0x10006e3f2b10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x10006e3f2b20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x10006e3f2b30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x10006e3f2b40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x10006e3f2b50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 =>0x10006e3f2b60: 00 00 f1 f1 f1 f1 00 f2 f2 f2 00 f2 f2 f2[04]f3 0x10006e3f2b70: f3 f3 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x10006e3f2b80: 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1 0x10006e3f2b90: f1 f1 f8 f2 00 f2 f2 f2 f8 f3 f3 f3 00 00 00 00 0x10006e3f2ba0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1 0x10006e3f2bb0: f1 f1 00 f3 f3 f3 00 00 00 00 00 00 00 00 00 00 Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user: f7 Container overflow: fc Array cookie: ac Intra object redzone: bb ASan internal: fe Left alloca redzone: ca Right alloca redzone: cb Shadow gap: cc ==1383==ABORTING Fix this by NUL-terminating the string. Fixes: xorg/xserver#1193 (comment 1053306) Signed-off-by:Aaron Plattner <aplattner@nvidia.com>
-
Aaron Plattner authored
GAMMA_LUT sizes other than 1024 cause a crash during startup if the memcpy() calls in xf86RandR12CrtcSetGamma() read past the end of the legacy X11 / XVidMode gamma ramp. This is a problem on Intel ICL / GEN11 platforms because they report a GAMMA_LUT size of 262145. Since it's not clear that the modesetting driver will generate a proper gamma ramp at that size even if xf86RandR12CrtcSetGamma() is fixed, just disable use of GAMMA_LUT for sizes other than 1024 for now. This will cause the modesetting driver to disable the CTM property and fall back to the legacy gamma LUT. Signed-off-by:
-
- Sep 09, 2021
-
-
Povilas Kanapickas authored
Since 8702c938 the pixmap formats are handled in a single place. In the process of conversion the difference between pixmap formats that can be uploaded and those that can be rendered on GL side has been lost. This affects only 1-bit pixmaps: as they aren't supported on GL, but can be converted to a R8 or A8 format for rendering (see glamor_get_tex_format_type_from_pictformat()). To work around this we add a separate flag that specifies whether the format actually supports rendering in GL, convert all checks to use this flag and then add 1-bit pixmap formats that don't support rendering in GL. Fixes: 8702c938 Closes: xorg/xserver#1210 Acked-by:
Adam Jackson <ajax@redhat.com> Signed-off-by:
-
Whenever an unredirected fullscreen window uses pageflipping for a DRI3/Present PresentPixmap() operation and the X-Screen has more than one active output, multiple crtc's need to execute pageflips. Only after the last flip has completed can the PresentPixmap operation as a whole complete. If a sync_flip is requested for the present, then the current implementation will synchronize each pageflip to the vblank of its associated crtc. This provides tear-free image presentation across all outputs, but introduces a different artifact, if not all outputs run at the same refresh rate with perfect synchrony: The slowest output throttles the presentation rate, and present completion is delayed to flip completion of the "latest" output to complete. This means degraded performance, e.g., a dual-display setup with a 144 Hz monitor and a 60 Hz monitor will always be throttled to at most 60 fps. It also means non-constant present rate if refresh cycles drift against each other, creating complex "beat patterns", tremors, stutters and periodic slowdowns - quite irritating! Such a scenario will be especially annoying if one uses multiple outputs in "mirror mode" aka "clone mode". One output will usually be the "production output" with the highest quality and fastest display attached, whereas a secondary mirror output just has a cheaper display for monitoring attached. Users care about perfect and perfectly timed tear-free presentation on the "production output", but cares less about quality on the secondary "mirror output". They are willing to trade quality on secondary outputs away in exchange for better presentation timing on the "production output". One example use case for such production + monitoring displays are neuroscience / medical science applications where one high quality display device is used to present visual animations to test subjects or patients in a fMRI scanner room (production display), whereas an operator monitors the same visual animations from a control room on a lower quality display. Presentation timing needs to be perfect, and animations high-speed and tear-free for the production display, whereas quality and timing don't matter for the monitoring display. This commit gives users the option to choose such a trade-off as opt-in: It adds a new boolean option "AsyncFlipSecondaries" to the device section of xorg.conf. If this option is specified as true, then DRI3 pageflip behaviour changes as follows: 1. The "reference crtc" for a windows PresentPixmap operation does a vblank synced flip, or a DRM_MODE_PAGE_FLIP_ASYNC non-synchronized flip, as requested by the caller, just as in the past. Typically flips will be requested to be vblank synchronized for tear-free presentation. The "reference crtc" is the one chosen by the caller to drive presentation timing (as specified by PresentPixmap()'s "target_msc", "divisor", "remainder" parameters and implemented by vblank events) and to deliver Present completion timestamps (msc and ust) extracted from its pageflip completion event. 2. All other crtc's, which also page-flip in a multi-display configuration, will try to flip with DRM_MODE_PAGE_FLIP_ASYNC, ie. immediately and not synchronized to vblank. This allows the PresentPixmap operation to complete with little delay compared to a single-display present, especially if the different crtc's run at different video refresh rates or their refresh cycles are not perfectly synchronized, but drift against each other. The downside is potential tearing artifacts on all outputs apart from the one of the "reference crtc". Successfully tested on a AMD gpu with single-display, dual-display and triple-display setups, and with single-X-Screen as well as dual-X-Screen "ZaphodHeads" configurations. Please consider merging this commit for the upcoming server 1.21 branch. Signed-off-by:
-
- Sep 07, 2021
-
-
Ignacio Casal authored
If the device is disabled the sprite is NULL so we get a seg fault
-
