LWN: Comments on "A privilege escalation flaw in udev" https://lwn.net/Articles/329266/ This is a special feed containing comments posted to the individual LWN article titled "A privilege escalation flaw in udev". en-us Wed, 15 Oct 2025 18:16:33 +0000 Wed, 15 Oct 2025 18:16:33 +0000 https://www.rssboard.org/rss-specification lwn@lwn.net A privilege escalation flaw in udev https://lwn.net/Articles/330029/ https://lwn.net/Articles/330029/ smithj <div class="FormattedComment"> FYI, I updated udev only on various RHEL5 boxen from 5.1 to 5.3, with weird patch levels in-between. I've yet to see any problems.<br> <p> Your milage may vary.<br> </div> Fri, 24 Apr 2009 18:43:47 +0000 A privilege escalation flaw in udev https://lwn.net/Articles/329977/ https://lwn.net/Articles/329977/ nix <div class="FormattedComment"> It can be tricky to get LVM aligned properly for LVM-atop-RAID, and if you <br> get it wrong you get a silent substantial slowdown...<br> <p> (RAID-atop-LVM is not prone to this because you don't get the same excess <br> RMW cycles.)<br> <p> </div> Fri, 24 Apr 2009 10:37:38 +0000 A privilege escalation flaw in udev https://lwn.net/Articles/329831/ https://lwn.net/Articles/329831/ jimparis That is not true. Go look at Kay's commit. It adds the <tt>SO_PASSCRED</tt> option to the socket and adds an explicit check for <tt>(cred->uid != 0)</tt>. As the LWN writeup indicated, 'either patch "alone would be sufficient" to fix the problem'. And your statement about him being quick to notify others is misleading at best. There has <b>still</b> not been a single posting on the udev mailing list about this problem! Thu, 23 Apr 2009 17:08:55 +0000 A privilege escalation flaw in udev https://lwn.net/Articles/329812/ https://lwn.net/Articles/329812/ janfrode <div class="FormattedComment"> And just to be on the paranoid safe side I asked Red Hat support, and they confirmed it should be safe to upgrade on any RHEL5 update levels.<br> </div> Thu, 23 Apr 2009 16:07:20 +0000 A privilege escalation flaw in udev https://lwn.net/Articles/329799/ https://lwn.net/Articles/329799/ Tet <div class="FormattedComment"> I'd say LVM fixed that inconvenience long ago, and the benefits of multiple filesystems are still there. I can't really understand why anyone would go with a single large root filesystem.<br> </div> Thu, 23 Apr 2009 15:24:40 +0000 A privilege escalation flaw in udev https://lwn.net/Articles/329767/ https://lwn.net/Articles/329767/ BenHutchings No, that commit does what it says. The <a href="http://git.kernel.org/?p=linux/hotplug/udev.git;a=commit;h=e86a923d508c2aed371cdd958ce82489cf2ab615">commit that fixed this bug</a> was made by Scott James Remnant and has the subject "libudev: monitor - ignore messages from unusual sources". This is not entirely explicit, but it may not have immediately occurred to him that this was a severe security flaw. I can say that he was fairly quick to notify others about it. Thu, 23 Apr 2009 14:12:54 +0000 A privilege escalation flaw in udev https://lwn.net/Articles/329763/ https://lwn.net/Articles/329763/ nix <div class="FormattedComment"> This looks like a reason why a /sys/block entry containing a device node for each device rather than just a textual representation of (major, minor) might be useful: but that was already rejected :/<br> </div> Thu, 23 Apr 2009 13:56:08 +0000 A privilege escalation flaw in udev https://lwn.net/Articles/329762/ https://lwn.net/Articles/329762/ Ross <div class="FormattedComment"> It's useful for chroot()ed filesystems or to fix /dev problems from another installation by mounting <br> under /mnt or wherever. The kernel shouldn't "know" that /dev is special.<br> <p> I believe that installers also create these files in /tmp if you want another example.<br> </div> Thu, 23 Apr 2009 13:52:01 +0000 A privilege escalation flaw in udev https://lwn.net/Articles/329755/ https://lwn.net/Articles/329755/ cesarb <div class="FormattedComment"> I have seen that sentence in every single security advisory they issue, so it is probably just a boilerplate sentence (of course, one can expect there are reasons for them adding that boilerplate).<br> </div> Thu, 23 Apr 2009 13:25:45 +0000 A privilege escalation flaw in udev https://lwn.net/Articles/329746/ https://lwn.net/Articles/329746/ etienne_lorrain@yahoo.fr <div class="FormattedComment"> <font class="QuotedText">&gt; Can anyone think of a reason why mknod() allows *anyone*</font><br> <font class="QuotedText">&gt; to create device nodes outside /dev?</font><br> <p> How would you ask ioctl like BLKBSZGET, BLKSSZGET, BLKGETSIZE,<br> BLKGETSIZE64, HDIO_GETGEO_BIG, to the file system which contains<br> a file given as parameter?<br> As an example:<br> <a href="http://www.mirrorservice.org/sites/download.sourceforge.net/pub/sourceforge/g/gu/gujin/gujin-2.5.tar.gz/gujin/showmap.c?extract=true">http://www.mirrorservice.org/sites/download.sourceforge.n...</a><br> <p> There is maybe a better solution (without having to guess the mount<br> point *name*) - I am listening...<br> </div> Thu, 23 Apr 2009 11:52:08 +0000 A privilege escalation flaw in udev https://lwn.net/Articles/329740/ https://lwn.net/Articles/329740/ kaber <div class="FormattedComment"> A few minor notes on netlink and this bug:<br> <p> - netlink supports 2^32-1 groups in recent kernel versions<br> <p> - the proper way to check that a message is from the kernel is to check for a PID of zero. Its also worth noting that netlink PIDs are just numerical identifiers with a badly chosen name, they have no direct relationship to process PIDs.<br> <p> - regarding other netlink users: the exactly same bug was present in iproute and IIRC the *swan keying daemons a couple of years ago. I'd expect it to be present in more software using netlink.<br> <p> Netlink for userspace to userspace communication seems like a pretty useless feature, unfortunately we can't remove it or require receiving processes to optionally enable it for compatibility reasons.<br> <p> </div> Thu, 23 Apr 2009 11:10:32 +0000 A privilege escalation flaw in udev https://lwn.net/Articles/329735/ https://lwn.net/Articles/329735/ janfrode The Red Hat errata for this fix says: <pre> Before applying this update, make sure that all previously-released errata relevant to your system have been applied. </pre> Is that just the normal cop out, or are there any reasons to worry upgrading udev on a RHEL5u0 will break something.. ? Thu, 23 Apr 2009 08:45:02 +0000 A privilege escalation flaw in udev https://lwn.net/Articles/329720/ https://lwn.net/Articles/329720/ jimparis <div class="FormattedComment"> Kay's commit message is:<br> "libudev: monitor - unify socket message handling"<br> <p> It would be nice to at least hint at the fact that this fixes a critical security flaw... the release notes for udev 141 didn't even suggest that there was any reason to upgrade: <a href="http://lwn.net/Articles/328340/">http://lwn.net/Articles/328340/</a><br> <p> That's pathetic.<br> </div> Thu, 23 Apr 2009 07:09:49 +0000 reboot? https://lwn.net/Articles/329719/ https://lwn.net/Articles/329719/ jabby <div class="FormattedComment"> so, no reboot is necessary for the kernel to use the new udev?<br> </div> Thu, 23 Apr 2009 07:03:51 +0000 A privilege escalation flaw in udev https://lwn.net/Articles/329687/ https://lwn.net/Articles/329687/ smithj <div class="FormattedComment"> The RHEL update for this issue automatically restarts udev. I would imagine other vendors either do the same or that /etc/init.d/udev restart (or similar) would be safe to execute on an in-production system.<br> </div> Thu, 23 Apr 2009 00:42:46 +0000 A privilege escalation flaw in udev https://lwn.net/Articles/329684/ https://lwn.net/Articles/329684/ dlang <div class="FormattedComment"> there is a mount option to deny the ability to use device nodes on a filesystem, but it's seldom used nowdays (the benifit from splitting up the filesystem into many slices is outweighed by the inconvienience of dealing with the many slices)<br> </div> Thu, 23 Apr 2009 00:39:14 +0000 A privilege escalation flaw in udev https://lwn.net/Articles/329680/ https://lwn.net/Articles/329680/ jreiser <i>Can anyone think of a reason why mknod() allows *anyone* to create device nodes outside /dev?</i> <p>Before there was kernel-level virtualization (vmware, xen, kvm, ...) there were partial virtualization environments which needed devices. If you have a machine with trusted users only and/or global protection, then <tt>mknod()</tt> can be handy for experiments. Thu, 23 Apr 2009 00:05:31 +0000 A privilege escalation flaw in udev https://lwn.net/Articles/329658/ https://lwn.net/Articles/329658/ nix <div class="FormattedComment"> Can anyone think of a reason why mknod() allows *anyone* to create device <br> nodes outside /dev? (Or, more generally, why isn't a special mount option <br> required to create device nodes on a filesystem? The ability to create <br> device nodes absolutely anywhere is a 'feature' of Unix that I've never <br> seen be of actual use to anyone except attackers.)<br> <p> This would have fixed the NFS problem, at least, although not the udev <br> hole (as udev would have created the node in /dev, which would have had <br> that flag...)<br> <p> (More evilly still, if you indicate this in the superblock and have it be <br> set at mkfs time --- also not problematic for your average system with a <br> tmpfs /dev --- this lets us recycle the now-unused st_rdev field in the <br> inode for something else. Not a huge saving, true, but it *is* a saving, <br> and there are a *lot* of inodes on your average system.)<br> <p> </div> Wed, 22 Apr 2009 22:40:53 +0000 A privilege escalation flaw in udev https://lwn.net/Articles/329655/ https://lwn.net/Articles/329655/ Trou.fr <div class="FormattedComment"> The most clever way to exploit this vulnerability is to leverage the fact that since udev 116, it is possible to specify a command to be run in the message sent via the netlink socket.<br> <p> So on udev &gt; 116, you have arbitrary command execution as root, for any users, 100% reliable, not arch specific.<br> <p> One of the most important vulnerabilities in years on GNU/Linux systems imho.<br> </div> Wed, 22 Apr 2009 22:29:45 +0000 A privilege escalation flaw in udev https://lwn.net/Articles/329649/ https://lwn.net/Articles/329649/ arjan <div class="FormattedComment"> yes but it does that in a tiny database in /dev ... so persistent between udev restarts...<br> </div> Wed, 22 Apr 2009 21:46:46 +0000 A privilege escalation flaw in udev https://lwn.net/Articles/329641/ https://lwn.net/Articles/329641/ jengelh <div class="FormattedComment"> Maybe, but none that I know would be relevant to interruption like upgrade.<br> </div> Wed, 22 Apr 2009 21:12:23 +0000 A privilege escalation flaw in udev https://lwn.net/Articles/329622/ https://lwn.net/Articles/329622/ pranith <div class="FormattedComment"> doesnt udevd keep track of all the devices it created??<br> </div> Wed, 22 Apr 2009 19:16:36 +0000 A privilege escalation flaw in udev https://lwn.net/Articles/329612/ https://lwn.net/Articles/329612/ proski <div class="FormattedComment"> Upgrading udev should not cause any downtime.<br> </div> Wed, 22 Apr 2009 18:28:16 +0000 A privilege escalation flaw in udev https://lwn.net/Articles/329611/ https://lwn.net/Articles/329611/ tzafrir <div class="FormattedComment"> Kill udevd :-(<br> <p> On a server system it should work.<br> </div> Wed, 22 Apr 2009 18:25:53 +0000 A privilege escalation flaw in udev https://lwn.net/Articles/329599/ https://lwn.net/Articles/329599/ pheldens <div class="FormattedComment"> Is there a quick fix to fix a running system without downtime?<br> <p> </div> Wed, 22 Apr 2009 18:05:53 +0000 rootness checking https://lwn.net/Articles/329541/ https://lwn.net/Articles/329541/ sladen <a href="http://linux-vserver.org/">Linux-Vserver</a> container instances are a case where <code>uid=0</code> is root, possibly <code>CAP_NET_ADMIN</code>, but <em>not</em> <code>CAP_SYS_ADMIN</code>. Wed, 22 Apr 2009 15:22:42 +0000