Date: Sun, 25 Jun 2006 00:32:54 +0100 (BST) From: Robert Watson <rwatson@FreeBSD.org> To: Alexander Leidinger <Alexander@Leidinger.net> Cc: cvs-src@freebsd.org, src-committers@freebsd.org, secteam@freebsd.org, cvs-all@freebsd.org Subject: Re: cvs commit: src/sys/compat/linux linux_misc.c Message-ID: <20060625002255.F8526@fledge.watson.org> In-Reply-To: <20060623214521.7b1441a6@Magellan.Leidinger.net> References: <200606231849.k5NIncuF041890@repoman.freebsd.org> <20060623214521.7b1441a6@Magellan.Leidinger.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 23 Jun 2006, Alexander Leidinger wrote: > I realized this may be a little bit misleading... Quite. The term "panic" in the context of a kernel change typically refers to a kernel panic -- i.e., panic(). > The NULL pointer is used as the destination in a copyout. And it writes at > the userland address 0. This will not lead to a kernel panic, but it will do > malicious things to the program which uses the linux times syscall. So this > is not a DoS in any case. The problematic case is when a linux program uses > a NULL pointer in the times syscall conditionally. This may render the > service which uses such a linux program useless sometimes. For programs > which use NULL there every time, this is not a DoS, it's just a normal bug > (e.g. you can't use Oracle 10g Express) which prevents the use of this > program. I think this this is not an appropiate use of the term "malicious". > So this is not a a huge security flaw, it's more a not so small > inconvenience. Since the RELENG_x_y branches are under control of the > secteam, I used the "Security:" mark up to encode the possible need to merge > this (I'm assuming Oracle 10g is important enough that we want our users to > be able to run it). This isn't just not a huge security flaw, it's not a security flaw at all. It is a reliability bug due to a mis-implemented API that results in a clean failure in the presence of a well-characterized case. It doesn't appear to be exploitable to gain privilege, deny service rmeotely, etc. If this is a critical stability fix, it should be treated as an errata patch candidate. In the future, please don't use the "Security" tag for this type of change. However, do feel free to e-mail re@ to talk about whether this is an errata patch candidate, keeping secteam@ in the loop, as they currently own the 6.1 branch. Robert N M Watson Computer Laboratory University of Cambridge
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060625002255.F8526>