[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAP145phM81D08ZaeKXXtWNQQktGSuXRR85TY_=jhQYcdruGTpA@mail.gmail.com>
Date: Tue, 15 Dec 2015 04:48:25 +0100
From: Robert Święcki <robert@...ecki.net>
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
> > 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.
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)
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.
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.
