Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 20 Jan 2017 09:01:17 -0500
From: Brad Spengler <>
Cc: Jesse Hertz <>,
	Wade Mealing <>
Subject: Re: CVE REQUEST: linux kernel: process with pgid zero
 able to crash kernel

Hi Greg,

Much like you feel it's not your job to inform your own users of 
vulnerabilities you've silently fixed, it's not the job of distros (who 
are actually informing their own users) to do your job of determining 
what kernels a particular fix affects, particularly when you just use it 
as a way of getting your advertisement out there that people should be 
running the latest Linux kernels.  Of course, what you're missing is 
that when it's the distros themselves requesting the CVEs, this skews 
the discussion of vulnerabilities to older kernels, not the much higher 
number present in the latest upstream "stable".

While we're here, how about a CVE for a recent kernel, for a vulnerability
not fixed in any stable kernel yet, and introduced for a pointless mitigation
no less:
This affects upstream >= 4.8 when CONFIG_SLAB_FREELIST_RANDOM is enabled
("for those following along at home")

Or, since VMAP_STACK was introduced haphazardly in 4.9 without doing any 
static analysis beyond a simple grep or smatch it seems, there are probably a 
dozen or so DoSes when CONFIG_DEBUG_SG or CONFIG_DEBUG_VIRTUAL is 
enabled, or potential silent or not so silent memory corruption when 
it's not, as a scatterlist crossing a virtual page boundary will then 
end up accessing a totally unrelated adjacent physical page if a stack 
address was passed into the scatterlist, and these vulnerabilities will 
continue to pop up until something comprehensive is done to prevent 
them.  Emese's written an IPA GCC plugin to find all the ones you've missed,
so we know there still are many that haven't been fixed.
0day alert, not fixed in 4.9 yet:
Not to mention the bugs introduced via fixes for VMAP_STACK:

Or how about a CVE for this huge heap infoleak (and while I'm at it, congrats to
Al for not covering it up for once, maybe he's learning!):
Or this (sgid bit not cleared on tmpfs):

So be careful, if you keep advertising the superiority of upstream LTS 
kernels in this passive aggressive way, you may soon find yourself on 
the other end of such advertisement ;)


On Fri, Jan 20, 2017 at 09:26:35AM +0100, Greg KH wrote:
> On Fri, Jan 20, 2017 at 01:41:52PM +1100, Harshula wrote:
> > Hi Folks,
> > 
> > Red Hat Product Security has been notified of a kernel vulnerability
> > that a local attacker can exploit to crash/panic the kernel and cause a
> > denial of service.
> > 
> > This was reported to Red Hat by Jesse Hertz (CC'd) (reproducer:
> > rt411016):
> > 
> > "A process that is in the same process group as the ``init'' process
> > (group id zero) can crash the Linux 2 kernel with several system calls
> > by passing in a process ID or process group ID of zero. The value zero
> > is a special value that indicates the current process ID or process
> > group. However, in this case it is also the process group ID of the
> > process."
> > 
> > I've been testing whether RHEL is vulnerable and found the following:
> > 
> > * Upstream/mainline is not vulnerable
> Is this true for the mainline kernel tree that RHEL 6 was based on?
> > * RHEL 7 is not vulnerable
> > * RHEL 6 is vulnerable
> > * RHEL 5 is partially vulnerable
> So this is only due to a specific set of patches that were added to RHEL
> 6 and RHEL 5 yet never made it upstream?  I ask as we want to make sure
> some of the older LTS mainline kernels might be affected and it would be
> good to ensure they are not.
> thanks,
> greg k-h

Download attachment "signature.asc" of type "application/pgp-signature" (837 bytes)

Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.