Re: Re: CVE request - Android kernel - IPv6 connect cause a denial of service

[Hannes Frederic Sowa <hannes () stressinduktion org>]

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