linux-kernel - Re: BUG: scheduling while atomic in f

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 for Android: free password hash cracker in your pocket

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

Date:   Wed, 28 Sep 2016 18:31:55 +0200
From:   Michal Nazarewicz <mina86@...a86.com>
To:     Chen Yu <chenyu56@...wei.com>,
        Felipe Balbi <felipe.balbi@...ux.intel.com>,
        gregkh@...uxfoundation.org
Cc:     wangbinghui@...ilicon.com, linux-kernel@...r.kernel.org,
        linux-usb@...r.kernel.org, John Stultz <john.stultz@...aro.org>,
        Amit Pundir <amit.pundir@...aro.org>,
        Guodong Xu <guodong.xu@...aro.org>
Subject: Re: BUG: scheduling while atomic in f_fs when gadget remove driver

On Wed, Sep 28 2016, Chen Yu wrote:
> I will try to fix it, but I'm engaged in other tasks and can not spend
> much time on it.
>
> Do you have any suggestions about how to fix it?

epfile->ep is protected by ffs->eps_lock which brings us to realisation
that there is another bug in the code and we need to do this:

------- >8 -------------------------------------------------------------
>From 0ce6cc5e2440800243eff06c6952cba0f976da2f Mon Sep 17 00:00:00 2001
From: Michal Nazarewicz <mina86@...a86.com>
Date: Wed, 28 Sep 2016 18:10:42 +0200
Subject: [PATCH] usb: gadget: f_fs: edit epfile->ep under lock

epfile->ep is protected by ffs->eps_lock (not epfile->mutex) so clear it
while holding the spin lock.

Signed-off-by: Michal Nazarewicz <mina86@...a86.com>
Fixes: 9353afbbfa7b ("buffer data from ‘oversized’ OUT requests")
---
 drivers/usb/gadget/function/f_fs.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/gadget/function/f_fs.c b/drivers/usb/gadget/function/f_fs.c
index 0aeed85..759f5d4 100644
--- a/drivers/usb/gadget/function/f_fs.c
+++ b/drivers/usb/gadget/function/f_fs.c
@@ -1725,17 +1725,17 @@ static void ffs_func_eps_disable(struct ffs_function *func)
 	unsigned long flags;
 
 	do {
-		if (epfile)
-			mutex_lock(&epfile->mutex);
 		spin_lock_irqsave(&func->ffs->eps_lock, flags);
 		/* pending requests get nuked */
 		if (likely(ep->ep))
 			usb_ep_disable(ep->ep);
 		++ep;
+		if (epfile)
+			epfile->ep = NULL;
 		spin_unlock_irqrestore(&func->ffs->eps_lock, flags);
 
 		if (epfile) {
-			epfile->ep = NULL;
+			mutex_lock(&epfile->mutex);
 			kfree(epfile->read_buffer);
 			epfile->read_buffer = NULL;
 			mutex_unlock(&epfile->mutex);
------- >8 -------------------------------------------------------------

With that done, the only thing which needs a mutex is
epfile->read_buffer.

The read_buffer pointer shouldn’t be that big of an issue (it could be
protected by the same eps_lock).  The real problem is freeing the
memory.

We cannot do it while __ffs_epfile_read_buffered is reading data from
it.  We cannot blindly schedule it to happen later either since in the
meanwhile __ffs_epfile_read_buffered could have freed it.

-- 
Best regards
ミハウ “𝓶𝓲𝓷𝓪86” ナザレヴイツ
«If at first you don’t succeed, give up skydiving»