linux-kernel - RE: [PATCH] usb: gadget: f_fs: report error if excess data received

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 17 May 2016 02:53:48 +0000
From:	"Du, Changbin" <changbin.du@...el.com>
To:	Michal Nazarewicz <mina86@...a86.com>,
	Felipe Balbi <felipe.balbi@...ux.intel.com>,
	Alan Stern <stern@...land.harvard.edu>
CC:	Al Viro <viro@...iv.linux.org.uk>,
	"gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
	"rui.silva@...aro.org" <rui.silva@...aro.org>,
	"k.opasiak@...sung.com" <k.opasiak@...sung.com>,
	"lars@...afoo.de" <lars@...afoo.de>,
	"linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH] usb: gadget: f_fs: report error if excess data received

> There appears to be no kfifo support for iov_iter though, so I just went
> with a simple buffer.
> 
> I haven’t looked at the patch too carefully so this is an RFC rather
> than an actual patch at this point.  It does compile at least.
> 
> Regardless, the more I thin about it, the more I’m under the impression
> that the whole rounding up in f_fs was a mistake.  And the more I’m
> leaning towards ignoring the excess data set by the host.
> 
> ---------- >8 ----------------------------------------------------------
> Subject: usb: gadget: f_fs: buffer data from ‘oversized’ OUT requests
> 
> f_fs rounds up read(2) requests to a multiple of a max packet size
> which means that host may provide more data than user has space for.
> So far, the excess data has been silently ignored.
> 
> This introduces a buffer for a tail of such requests so that they are
> returned on next read instead of being ignored.
> 

Congratulations finally reach an agreement, thanks Alan Stern and Michal.
Here just have a comment - the buffered data need be dropped when the
epfile is closed, because it means the session is terminated.