linux-kernel - Re: [GIT PULL] USB/PHY driver patches for 4.17-rc1

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] [day] [month] [year] [list]

Date:   Fri, 6 Apr 2018 01:04:43 +0100
From:   Al Viro <viro@...IV.linux.org.uk>
To:     Christoph Hellwig <hch@...radead.org>
Cc:     Lars-Peter Clausen <lars@...afoo.de>,
        Kees Cook <keescook@...omium.org>,
        Greg KH <gregkh@...uxfoundation.org>,
        Felipe Balbi <felipe.balbi@...ux.intel.com>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        LKML <linux-kernel@...r.kernel.org>, linux-usb@...r.kernel.org
Subject: Re: [GIT PULL] USB/PHY driver patches for 4.17-rc1

On Thu, Apr 05, 2018 at 12:31:11AM -0700, Christoph Hellwig wrote:
> On Thu, Apr 05, 2018 at 09:19:28AM +0200, Lars-Peter Clausen wrote:
> > On 04/05/2018 08:31 AM, Kees Cook wrote:
> > > On Wed, Apr 4, 2018 at 3:31 AM, Greg KH <gregkh@...uxfoundation.org> wrote:
> > >> Lars-Peter Clausen (2):
> > >>       usb: gadget: ffs: Execute copy_to_user() with USER_DS set
> > > 
> > > https://git.kernel.org/linus/4058ebf33cb0be88ca516f968eda24ab7b6b93e4
> > > 
> > > Isn't there a better way to do this without the set_fs() usage? We've
> > > been try to eliminate it in the kernel. I thought there was a safer
> > > way to use iters now?
> > 
> > The problem is use_mm(). It needs to be accompanied with set_fs(DS_USER) to
> > work reliably. This has simply been missing for this particular instance of
> > use_mm().
> 
> To me it seems like use_mm() should do set_fs(USER_DS) and unuse_mm()
> should do set_fs(KERNEL_DS) to get drivers outo of this mess.  I'll see
> if I can come up with patches for the next merge window.

Yes on the former, not quite on the latter (we need to go back to the state
before use_mm()).  Said that, drm users of use_mm() look rather fishy and
might be worth a good look...