Subject: Re: [Coverity] Untrusted user data in kernel
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
To: Jan Kasprzak <kas@fi.muni.cz>
Cc: Marcelo Tosatti <marcelo.tosatti@cyclades.com>,
       Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
       jaharkes@cs.cmu.edu, Andrew Morton <akpm@osdl.org>,
       acme@conectiva.com.br, davem@redhat.com, nathans@sgi.com
In-Reply-To: <20050106091844.GB6961@fi.muni.cz>
References: <1103247211.3071.74.camel@localhost.localdomain>
	 <20050105120423.GA13662@logos.cnet> <20050105161653.GF13455@fi.muni.cz>
	 <20050105140549.GA14622@logos.cnet>  <20050106091844.GB6961@fi.muni.cz>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Message-Id: <1105018573.24896.191.camel@localhost.localdomain>
Mime-Version: 1.0
Date: Thu, 06 Jan 2005 16:29:30 +0000
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 808
Lines: 18


> 	The SDLA_CLEAR ioctl (the sdla_clear(dev) function) tries
> to clear exactly 65536 bytes (hardcoded at sdla.c:sdla_clear() line 140).
> So the mem.len should be <= 65536 bytes, and even mem.addr + mem.len
> should be <= 65536 bytes.
> 
> 	So I propose the following patch (maybe the constant 65536 should
> be defined in sdla.h and used both in sdla_xfer() and sdla_clear()):

I'd propose they are set to CAP_SYS_RAWIO for those specific
debugging/firmware load operations. They allow access to that level
potentially anyway. That solves the problem cleanly.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/