linux-kernel - [PATCH 0/2] Fix async io races

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

Date:	Fri, 11 Mar 2016 10:35:32 -0600
From:	Seth Forshee <seth.forshee@...onical.com>
To:	fuse-devel@...ts.sourceforge.net
Cc:	Miklos Szeredi <miklos@...redi.hu>, m.loschwitz@...eleven.de,
	robert@...byte.com, seth.forshee@...onical.com,
	linux-kernel@...r.kernel.org
Subject: [PATCH 0/2] Fix async io races

These patches are fixes for the problems reported at
https://sourceforge.net/p/fuse/mailman/message/34537139/. The first
patch is one of those that Robert posted on that thread, and the second
is a different patch that Robert and I agree represents a more robust
solution to the race.

The first race is that a is_sync_kiocb() is called on an iocb that could
have been freed if async io has already completed. The fix in this case
is simple and obvious: cache the result before starting io.

In the second case aio completion results in waking a waiting task
followed by unlocking the fuse_io_priv object. The waiting task will
free that object once awoken though, so it's possible for the object to
be freed before spin_unlock() is called. The simple fix is to move the
unlock to before the wake, but really this problem suggests a more
fundamental problem in the lifecycle of fuse_io_priv objects. The
request count in this object is serving two purposes, to count
outstanding aio requests to the fuse server and to serve as a reference
count in the object. For synchronous io these roles come into conflict.
The task which submits io must wait for all requests to the fuse server
to finish and then retrieve the result of the operation from the
fuse_io_priv object, yet it will not be woken until the outstanding
request count reaches 0. This means the task must release its reference
to the object before waiting, which leads to a somewhat confusing set of
rules for when it is safe to free the object.

This becomes much more straightforward if a separate reference count is
maintained for fuse_io_priv objects. Then the waiting task can hold a
reference while waiting, and there is no ambiguity about whether or not
it is safe to free an object. The second patch implements this solution.

Thanks,
Seth

Robert Doebbelin (1):
  fuse: do not use iocb after it may have been freed

Seth Forshee (1):
  fuse: Add reference counting for fuse_io_priv

 fs/fuse/cuse.c   | 12 ++++++++++--
 fs/fuse/file.c   | 47 +++++++++++++++++++++++++++++++++++++----------
 fs/fuse/fuse_i.h | 15 +++++++++++++++
 3 files changed, 62 insertions(+), 12 deletions(-)