My thoughts on Slackware, life and everything

Month: October 2010 (Page 1 of 2)

Another glibc multilib update

Barely a week has passed, and we have yet another local root hole in glibc that needed patching. The Slackware ChangeLog said it like this:

a/glibc-solibs-2.12.1-x86_64-3.txz: Rebuilt.
Patched “The GNU C library dynamic linker will dlopen arbitrary DSOs
during setuid loads.” This security issue allows a local attacker to
gain root by specifying an unsafe DSO in the library search path to be
used with a setuid binary in LD_AUDIT mode.
Bug found by Tavis Ormandy (with thanks to Ben Hawkes and Julien Tinnes).
For more information, see:
(* Security fix *)

Of course, I was out of town for a few days when this happened, so it took a little longer to build updated multilib versions for glibc.

But… they are available now for your 64-bit Slackware 13.0, 13.1 and -current. Grab them here: If you need guidance, read the README or better even, check out the Wiki page on Slackware multilib.

I hope this is the last hole for a while, it sucks having to rebuild all of this.

Mirrors: and


New multilib glibc packages fix local root hole

New glibc packages for Slackware arrived on the mirrors last night. They close a serious local root hole. From the ChangeLog:

Patched “dynamic linker expands $ORIGIN in setuid library search path”.
This security issue allows a local attacker to gain root if they can create
a hard link to a setuid root binary.  Thanks to Tavis Ormandy.
For more information, see:
(* Security fix *)

I have already created new multilib versions of the updated glibc packages for Slackware64-current, get them here: or mirrored here: and here:

When I return from work, I will also create I have also created updates to my multilib glibc packages for Slackware64 13.0 and 13.1. Stay posted, I will write a note in the comments section of this article.


Compositing hard lock in KDE 4.5

People have written about their computer locking up with KDE 4.5.x in Slackware.

These locks seem to be caused by the open source video drivers that are part of X.Org. These drivers incorrectly advertise some OpenGL capabilities when the KDE compositing manager queries them. As a result, the KDE window manager tries to enable non-working functionality in “3d desktop effects” which results in a hard lock of X.Org.

There was some talk about this when I first released KDE 4.5.1 packages, see the comments section of and some developer talk can be found here:

Today I installed Slackware-current on an “old” ThinkPad T41 with an onboard Radeon RV250 (Mobility FireGL 9000) graphics chip. I experienced the hard lock there for the first time.

This is what I did to get KDE running (after forcedly shutting down the machine by pressing the OFF button for 8 seconds…): edit the KDE Window Manager configuration file:


In that file, look up the section called “[Compositing]” and then add these lines (perhaps in your case you have to modify, not add lines):


That first line disables the functionality checks so that if you enable “3d effects” manually you have a good chance of it actually going to work because KDE is not going to query your graphics drivers and just assumes it’ll work. As a result you will see an error about not being able to use the “blur effect” which is exactly where the query would result in incorrect data – the error message is not fatal though.

The second line disables the “3d effects” entirely, allowing KDE to start properly.


New multilib packages for 64-bit Slackware-current

As you may have noticed already, there are interesting updates in the Slackware ChangeLog.txt !

A new kernel, and new glibc plus gcc packages means there has to be an updated set of multilib packages too or else you bunch of hybrid lovers would be left out in the cold.

Well actually there is an update to my multilib packages too! . The is a new directory with goodies for your consumption.

For installation/upgrade instructions see the multilib README or even better, read my Wiki article at (which has not yet been updated with package versions for slackware64-current, but that will change soon).

In the slackware64-compat32 subdirectory I added the set of packages which have been generated by the script, i.e. that directory contains all the support libraries you need (along with my gcc/glibc and compat32-tools packages) to turn your Slackware64-current into a multilib system.

Good luck! Eric


Fast mirror at

Rsync access offered through rsync://

« Older posts

© 2024 Alien Pastures

Theme by Anders NorenUp ↑