From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from imap1.codethink.co.uk ([176.9.8.82]:46860 "EHLO imap1.codethink.co.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932388AbdJQOgR (ORCPT ); Tue, 17 Oct 2017 10:36:17 -0400 Message-ID: <1508250970.22379.65.camel@codethink.co.uk> Subject: Re: Patch "USB: devio: Don't corrupt user memory" has been added to the 4.4-stable tree From: Ben Hutchings To: dan.carpenter@oracle.com, stern@rowland.harvard.edu Cc: stable@vger.kernel.org, stable-commits@vger.kernel.org, Greg Kroah-Hartman Date: Tue, 17 Oct 2017 15:36:10 +0100 In-Reply-To: <150754871438113@kroah.com> References: <150754871438113@kroah.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: stable-owner@vger.kernel.org List-ID: On Mon, 2017-10-09 at 13:31 +0200, gregkh@linuxfoundation.org wrote: [...] > From: Dan Carpenter > > commit fa1ed74eb1c233be6131ec92df21ab46499a15b6 upstream. > > The user buffer has "uurb->buffer_length" bytes.  If the kernel has more > information than that, we should truncate it instead of writing past > the end of the user's buffer.  I added a WARN_ONCE() to help the user > debug the issue. [...] Users should not be able to provoke a WARN_ON at will, that's a DoS (log spam, possible panic). And this truncated user buffer length is also used for allocation of the kernel buffer. Are you totally sure that this can't result in a kernel buffer overrun (or leak)? This fix seems worse than continuing to allow userspace to shoot itself in the foot. Ben. -- Ben Hutchings Software Developer, Codethink Ltd.