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.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ