linux-kernel - [PATCH 5/5] usb: f_fs: avoid race condition with ffs_epfile_io

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: <1451943701-18212-5-git-send-email-mina86@mina86.com>
Date:	Mon,  4 Jan 2016 22:41:41 +0100
From:	Michal Nazarewicz <mina86@...a86.com>
To:	Felipe Balbi <balbi@...com>, "Du, Changbin" <changbin.du@...el.com>
Cc:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Al Viro <viro@...iv.linux.org.uk>,
	Robert Baldyga <r.baldyga@...sung.com>,
	linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org,
	Michal Nazarewicz <mina86@...a86.com>
Subject: [PATCH 5/5] usb: f_fs: avoid race condition with ffs_epfile_io_complete

From: "Du, Changbin" <changbin.du@...el.com>

ffs_epfile_io and ffs_epfile_io_complete runs in different context, but
there is no synchronization between them.

consider the following scenario:
1) ffs_epfile_io interrupted by sigal while
wait_for_completion_interruptible
2) then ffs_epfile_io set ret to -EINTR
3) just before or during usb_ep_dequeue, the request completed
4) ffs_epfile_io return with -EINTR

In this case, ffs_epfile_io tell caller no transfer success but actually
it may has been done. This break the caller's pipe.

Below script can help test it (adbd is the process which lies on f_fs).
while true
do
   pkill -19 adbd #SIGSTOP
   pkill -18 adbd #SIGCONT
   sleep 0.1
done

To avoid this, just dequeue the request first. After usb_ep_dequeue, the
request must be done or canceled.

With this change, we can ensure no race condition in f_fs driver. But
actually I found some of the udc driver has analogical issue in its
dequeue implementation. For example,
1) the dequeue function hold the controller's lock.
2) before driver request controller  to stop transfer, a request
   completed.
3) the controller trigger a interrupt, but its irq handler need wait
   dequeue function to release the lock.
4) dequeue function give back the request with negative status, and
   release lock.
5) irq handler get lock but the request has already been given back.

So, the dequeue implementation should take care of this case. IMO, it
can be done as below steps to dequeue a already started request,
1) request controller to stop transfer on the given ep. HW know the
   actual transfer status.
2) after hw stop transfer, driver scan if there are any completed one.
3) if found, process it with real status. if no, the request can
   canceled.

Signed-off-by: "Du, Changbin" <changbin.du@...el.com>
[mina86@...a86.com: rebased on top of refactoring patches]
Signed-off-by: Michal Nazarewicz <mina86@...a86.com>
---
 drivers/usb/gadget/function/f_fs.c | 12 +++++++++---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/gadget/function/f_fs.c b/drivers/usb/gadget/function/f_fs.c
index 63fe693..8cfce10 100644
--- a/drivers/usb/gadget/function/f_fs.c
+++ b/drivers/usb/gadget/function/f_fs.c
@@ -778,6 +778,7 @@ static ssize_t ffs_epfile_io(struct file *file, struct ffs_io_data *io_data)
 		ret = -EINVAL;
 	} else if (!io_data->aio) {
 		DECLARE_COMPLETION_ONSTACK(done);
+		bool interrupted = false;

 		req = ep->req;
 		req->buf      = data;
@@ -793,9 +794,14 @@ static ssize_t ffs_epfile_io(struct file *file, struct ffs_io_data *io_data)
 		spin_unlock_irq(&epfile->ffs->eps_lock);

 		if (unlikely(wait_for_completion_interruptible(&done))) {
-			ret = -EINTR;
+			/*
+			 * To avoid race condition with ffs_epfile_io_complete,
+			 * dequeue the request first then check
+			 * status. usb_ep_dequeue API should guarantee no race
+			 * condition with req->complete callback.
+			 */
 			usb_ep_dequeue(ep->ep, req);
-			goto error_mutex;
+			interrupted = ep->status < 0;
 		}

 		/*
@@ -804,7 +810,7 @@ static ssize_t ffs_epfile_io(struct file *file, struct ffs_io_data *io_data)
 		 * rounded up to maxpacketsize), we may end up with more data
 		 * then user space has space for.
 		 */
-		ret = ep->status;
+		ret = interrupted ? -EINTR : ep->status;
 		if (io_data->read && ret > 0) {
 			ret = copy_to_iter(data, ret, &io_data->data);
 			if (!ret)
-- 
2.6.0.rc2.230.g3dd15c0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/