[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <566FC653.1070001@stressinduktion.org>
Date: Tue, 15 Dec 2015 08:50:43 +0100
From: Hannes Frederic Sowa <hannes@...essinduktion.org>
To: oss-security@...ts.openwall.com
Cc: guoyonggang@....cn, cve-assign@...re.org
Subject: Re: Re: CVE request - Android kernel - IPv6 connect
cause a denial of service
Hi,
On 15.12.2015 04:48, Robert Święcki wrote:
>>> Use CVE-2015-8543 for the originally identified bug. We realize that,
>>> for example,
>>> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/log/net/ipv4/af_inet.c
>>> has not yet been changed. If Linux kernel developers determine that
>>> multiple independent bugs result in situations where
>>> sk->sk_prot->get_port is NULL above, then it is possible that
>>> additional CVE IDs will be assigned later.
>>
>> The following patch fixes this issue:
>>
>> https://git.kernel.org/cgit/linux/kernel/git/davem/net.git/commit/?id=79462ad02e861803b3840cc782248c7359451cd9
>>
>> It is queued up for -stable.
>>
>
> Not sure if it's important for you, but the description of this diff
> may not be exactly correct:
>
> a) ... as root ..
>
> If a given kernel supports CLONE_NEWUSER then everybody can create
> SOCK_RAW sockets. And CLONE_NEWUSER seems to be enabled with most
> modern Linux distros.
Yep, that is true. You can create a new user namespace and a new
net-namespace in which an ordinary user is allowed to use raw sockets.
> b). .. could simply crash the kernel ..
>
> It'll cause GPF in the supervisor mode, and it seems that with most of
> supported CPU architectures under Linux, this will actually cause
> SIGSEGV to be sent to the user-land counterpart of the kernel thread
> which caused such GPF. So, it's not really crash of the kernel in most
> cases (may depend on sysctl and CPU architecture in use though).
> However, given that such GPF can happen when the socket struct seems
> to be locked, this could potentially cause some kernel dead-locks with
> subsequent accesses to sk (may result in unkillable processes and
> similar artifacts)
This is what I meant by simply crashing the kernel. :) In most kernel
crashes we hold some locks or are in a rcu critical section, which makes
the rest of kernel execution pretty much indeterministic.
Red Hat kernel always set panic_on_ooops because of this.
> Also, it could be potentially turned into a privilege escalation
> problem if there was a way to map the NULL page. Under x86/x86-64 I
> reviewed the code (install_special_mapping() and friends from mmap.c)
> and it seems to be correctly protected. But if anybody is using any
> alternative CPU architecture, I'd suggest looking at their
> arch-specific vdso/vvar mapping code. In case the address is
> controllable by user, this could likely allow for mapping of the NULL
> page and pwning the kernel.
Even on x86_64 a NULL address should be installable if you lower
/proc/sys/vm/mmap_min_addr as root before. Some software might need this.
Thanks for the following up. Unfortunately I can't edit the commit
anymore but it will be hopefully useful for the description of the CVE
entry.
Bye,
Hannes
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.
