linux-kernel - RE: [PATCH V2] usb: gadget: f_fs: don't free buffer prematurely

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]

Message-ID: <02E7334B1630744CBDC55DA8586225837F7FB506@ORSMSX102.amr.corp.intel.com>
Date:   Wed, 20 Mar 2019 17:30:40 +0000
From:   "Yang, Fei" <fei.yang@...el.com>
To:     Josh Gao <jmgao@...gle.com>
CC:     "balbi@...nel.org" <balbi@...nel.org>,
        "gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
        Jerry Zhang <zhangjerry@...gle.com>,
        "andrzej.p@...labora.com" <andrzej.p@...labora.com>,
        "plr.vincent@...il.com" <plr.vincent@...il.com>,
        "Shen, JingX" <jingx.shen@...el.com>,
        John Stultz <john.stultz@...aro.org>,
        "linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH V2] usb: gadget: f_fs: don't free buffer prematurely

> On Tue, Mar 19, 2019 at 10:56 PM Josh Gao <jmgao@...gle.com> wrote:
> >
> > On Tue, Mar 19, 2019 at 10:32 PM <fei.yang@...el.com> wrote:
> > >
> > > From: Fei Yang <fei.yang@...el.com>
> > >
> > > The following kernel panic happens due to the io_data buffer gets 
> > > deallocated before the async io is completed. Add a check for the 
> > > case where io_data buffer should be deallocated by ffs_user_copy_worker.
> >
> > It looks like this happened because data got renamed to io_data, which 
> > made the `data = NULL` marked with "Do not kfree the buffer in this 
> > function" not do what it was hoping. This should probably either 
> > delete the assignment above or fix the assignment to refer to io_data? 
> > (EIOCBQUEUED presumably can't come from
> > elsewhere?)
> 
> (except ffs_free_buffer doesn't check for null, so probably the former)

I don’t see EIOCBQUEUED coming from anywhere else in the context of epfile_io, but you are right it's hard
to be 100% sure about that.
Maybe I should simply check for (data == NULL) so that the original logic remains intact,
If (data)
	ffs_free_buffer(io_data);