similar to: [ANNOUNCE] xorg-server 1.16.4

X.Org Security Advisory: Feb 10, 2015 - CVE-2015-0255 Information leak in the XkbSetGeometry request of X servers =========================================================== Description: ============ Olivier Fourdan from Red Hat has discovered a protocol handling issue in the way the X server code base handles the XkbSetGeometry request. The issue stems from the server trusting the client to

Ok, here's what I think we should release as 1.17. I plan on doing that in a few days (Monday? Tuesday?), unless there's some good reason not to. Let me know if there's some critical (i.e. crashing) fixes that I've missed somehow. And, again, I think we can run a shorter 1.18 cycle, given the pent-up list of fixes. Sorry for not getting this wrapped up sooner. Turns out that

Fixes for CVE 2015-0255. See Peter's associated email for more details. Keith Packard (1): Release 1.17.1 Olivier Fourdan (2): xkb: Don't swap XkbSetGeometry data in the input buffer xkb: Check strings length against request size git tag: xorg-server-1.17.1 http://xorg.freedesktop.org/archive/individual/xserver/xorg-server-1.17.1.tar.bz2 MD5:

CentOS Errata and Bugfix Advisory 2019:3972 Upstream details at : https://access.redhat.com/errata/RHBA-2019:3972 The following updated files have been uploaded and are currently syncing to the mirrors: ( sha256sum Filename ) x86_64: 6a534a09885aeea9c44eed75f2c21159ef33a8fe43c47df641513bfd19c69702 libipa_hbac-1.16.4-21.el7_7.1.i686.rpm

CentOS Errata and Bugfix Advisory 2020:3349 Upstream details at : https://access.redhat.com/errata/RHBA-2020:3349 The following updated files have been uploaded and are currently syncing to the mirrors: ( sha256sum Filename ) x86_64: 951fc236cc64f56e35cbac9230458a0b7e9f02ce0ca94111f13b21728f3b01d6 libipa_hbac-1.16.4-37.el7_8.4.i686.rpm

CentOS Errata and Bugfix Advisory 2020:2090 Upstream details at : https://access.redhat.com/errata/RHBA-2020:2090 The following updated files have been uploaded and are currently syncing to the mirrors: ( sha256sum Filename ) x86_64: 0aa0d9c046431d5db4c05752d276e33cb0a23e56b14a0c005c171fbee77b7f46 libipa_hbac-1.16.4-37.el7_8.3.i686.rpm

CentOS Errata and Bugfix Advisory 2020:0844 Upstream details at : https://access.redhat.com/errata/RHBA-2020:0844 The following updated files have been uploaded and are currently syncing to the mirrors: ( sha256sum Filename ) x86_64: c00490e2d307df37a1d4aec5a2c1c94e89a9a6d0aec252e04fa3319155df8dbe libipa_hbac-1.16.4-21.el7_7.3.i686.rpm

Send CentOS-announce mailing list submissions to centos-announce at centos.org To subscribe or unsubscribe via the World Wide Web, visit https://lists.centos.org/mailman/listinfo/centos-announce or, via email, send a message with subject or body 'help' to centos-announce-request at centos.org You can reach the person managing the list at centos-announce-owner at centos.org When

Send CentOS-announce mailing list submissions to centos-announce at centos.org To subscribe or unsubscribe via the World Wide Web, visit https://lists.centos.org/mailman/listinfo/centos-announce or, via email, send a message with subject or body 'help' to centos-announce-request at centos.org You can reach the person managing the list at centos-announce-owner at centos.org When

Hi! I have a server running CentOS 7.7 (1908) with all current patches installed. I think this server should be a quite standard installation with no specialities On this server I have fail2ban with an apache and openvpn configuration. I'm using firewalld to manage the firewall rules. Fail2an is configured to use firewalld: [root at server ~]# ll /etc/fail2ban/jail.d/ insgesamt 12

I have managed to find out what happened in the yum update and it turns out it was a mess. It looks like the server ran out of memory in the middle and things then started to fail. Any advice on how to recover from this would be greatly appreciated The log below shows: [root at vps2 ~]# yum history info 22 Loaded plugins: fastestmirror, langpacks Repository mariadb is listed more than once in

> On 1/22/20 3:57 PM, Gary Stainburn wrote: >> I have managed to find out what happened in the yum update and it turns >> out it was a mess. It looks like the server ran out of memory in the >> middle and things then started to fail. Any advice on how to recover >> from this would be greatly appreciated >> >> The log below shows: >> >> [root at

On 1/22/20 3:57 PM, Gary Stainburn wrote: > I have managed to find out what happened in the yum update and it turns out it was a mess. It looks like the server ran out of memory in the middle and things then started to fail. Any advice on how to recover from this would be greatly appreciated > > The log below shows: > > [root at vps2 ~]# yum history info 22 > Loaded plugins:

Le 18/08/2020 ? 03:00, Gunnar Niels a ?crit?: > I'm asking where the results of the yum-cron job are actually written to so > I can see what it did. Well, that's your answer. Here's the content of an email sent by Yum-Cron. So you everything that happened under the hood: The following updates will be applied on nestor.microlinux.lan:

Here's 1.18 RC1. Let's figure out when to release this during XDC. Aaron Plattner (3): xfree86: Fix xf86_check_platform_slot's handling of PCI xfree86: Add GPU screens even if there are no active GDevs xfree86: Bump video driver ABI version to 20 Adam Jackson (27): glamor: Fix up indentation xf86Crtc: right-of placement by default. dmx: Fix the

Here's the 1.17 release -- just a few patches since the last RC. Thanks to all for making this a really fun release to work on! Adel Gadllah (1): dri2: Set vdpau driver name if ddx does not provide any driver name Dave Airlie (2): randr: attempt to fix primary on slave output (v2) config/udev: Respect seat assignments when assigned devices Keith Packard (1): Update

On Fri, Mar 20, 2015 at 6:02 PM, Megaf <mmegaf at gmail.com> wrote: > Hi Ladies and Gentlemans. > > I'd like to report a possible bug and ask for help in solving it. > > I have a Mid 2010 Macbook Pro running Debian Jessie. > The bug seems to happen at random, but mainly when using a 3D application > with other apps running, such as Chromium (Chrome) and Iceweasel

Thanks for the help so far, I have already solved the main problem, but sadly it seems I can't find out the last step. I hope you can help me there... Here ist the important part: It is trying to load some nvidia module, although i have already done apt-get purge nvidia* [ 4.636] (II) LoadModule: "glx" [ 4.638] (II) Loading /usr/lib/xorg/modules/extensions/libglx.so [

https://bugs.freedesktop.org/show_bug.cgi?id=82714 --- Comment #8 from Bruno <bonbons at sysophe.eu> --- Created attachment 114731 --> https://bugs.freedesktop.org/attachment.cgi?id=114731&action=edit dmesg with 3.19 but runpm=0 Same kernel, kernel log starting at loading nouveau with `modprobe nouveau debug=debug runpm=0` and running Xorg on top of it: Xorg.0.log tail: [

Here's 1.19-RC2, which should be pretty close to 1.19. The only serious bug I'm aware of at this point is a crash in FlushAllOutput: https://bugzilla.redhat.com/show_bug.cgi?id=1382444 Adam Jackson (5): glamor: Fall back to software for CopyPlane if we need to xephyr: Don't crash if the server advertises zero xv adaptors test: Re-enable a couple of GetImage