From: Al Viro <viro@zeniv.linux.org.uk>
To: Mukesh Ojha <mojha@codeaurora.org>
Cc: "dmitry.torokhov@gmail.com" <dmitry.torokhov@gmail.com>,
linux-input@vger.kernel.org, linux-kernel@vger.kernel.org,
Gaurav Kohli <gkohli@codeaurora.org>,
Peter Hutterer <peter.hutterer@who-t.net>,
Martin Kepplinger <martink@posteo.de>,
"Paul E. McKenney" <paulmck@linux.ibm.com>
Subject: Re: [PATCH v2] Input: uinput: Avoid Object-Already-Free with a global lock
Date: Wed, 24 Apr 2019 14:07:11 +0100 [thread overview]
Message-ID: <20190424130711.GP2217@ZenIV.linux.org.uk> (raw)
In-Reply-To: <5614f04f-827d-1668-9ed0-60d93e110b8e@codeaurora.org>
On Wed, Apr 24, 2019 at 05:40:40PM +0530, Mukesh Ojha wrote:
>
> Al,
>
> i tried to put traceprintk inside ioctl after fdget and fdput on a simple
> call of open => ioctl => close
in a loop, and multithreaded, presumably?
> on /dev/uinput.
>
> uinput-532 [002] .... 45.312044: SYSC_ioctl: 2 <= f_count
> > <After fdget()
> uinput-532 [002] .... 45.312055: SYSC_ioctl: 2
> <After fdput()
> uinput-532 [004] .... 45.313766: uinput_open: uinput: 1
> uinput-532 [004] .... 45.313783: SYSC_ioctl: 1
> uinput-532 [004] .... 45.313788: uinput_ioctl_handler:
> uinput: uinput_ioctl_handler, 1
> uinput-532 [004] .... 45.313835: SYSC_ioctl: 1
> uinput-532 [004] .... 45.313843: uinput_release: uinput: 0
>
>
> So while a ioctl is running the f_count is 1, so a fput could be run and do
> atomic_long_dec_and_test
> this could call release right ?
Look at ksys_ioctl():
int ksys_ioctl(unsigned int fd, unsigned int cmd, unsigned long arg)
{
int error;
struct fd f = fdget(fd);
an error or refcount bumped
if (!f.file)
return -EBADF;
not an error, then. We know that ->release() won't be called
until we drop the reference we've just acquired.
error = security_file_ioctl(f.file, cmd, arg);
if (!error)
error = do_vfs_ioctl(f.file, fd, cmd, arg);
... and we are done with calling ->ioctl(), so
fdput(f);
... we drop the reference we'd acquired.
Seeing refcount 1 inside ->ioctl() is possible, all right:
CPU1: ioctl(2) resolves fd to struct file *, refcount 2
CPU2: close(2) rips struct file * from descriptor table and does fput() to drop it;
refcount reaches 1 and fput() is done; no call of ->release() yet.
CPU1: we get arouund to ->ioctl(), where your trace sees refcount 1
CPU1: done with ->ioctl(), drop our reference. *NOW* refcount gets to 0, and
->release() is called.
IOW, in your trace fput() has already been run by close(2); having somebody else
do that again while we are in ->ioctl() would be a bug (to start with, where
did they get that struct file * and why wasn't that reference contributing to
struct file refcount?)
In all cases we only call ->release() once all references gone - both
the one(s) in descriptor tables and any transient ones acquired by
fdget(), etc.
I would really like to see a reproducer for the original use-after-free report...
next prev parent reply other threads:[~2019-04-24 13:07 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-10 7:59 [PATCH v2] Input: uinput: Avoid Object-Already-Free with a global lock Mukesh Ojha
2019-04-15 10:05 ` Mukesh Ojha
2019-04-18 1:43 ` dmitry.torokhov
[not found] ` <bb92c3f2-faf1-04ec-4c67-3aba56c507a9@codeaurora.org>
[not found] ` <a4d1a2f3-1db7-e300-9569-7b7a2fadd64e@codeaurora.org>
2019-04-19 7:11 ` dmitry.torokhov
2019-04-19 8:43 ` Mukesh Ojha
2019-04-23 3:28 ` dmitry.torokhov
[not found] ` <17f4a0be-ab04-8537-9197-32fbca807f3f@codeaurora.org>
2019-04-23 8:49 ` dmitry.torokhov
2019-04-23 11:06 ` Al Viro
2019-04-23 12:15 ` Al Viro
2019-04-24 12:10 ` Mukesh Ojha
2019-04-24 13:07 ` Al Viro [this message]
2019-04-24 14:09 ` Mukesh Ojha
2019-04-24 22:56 ` Al Viro
2019-05-01 7:50 ` Mukesh Ojha
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190424130711.GP2217@ZenIV.linux.org.uk \
--to=viro@zeniv.linux.org.uk \
--cc=dmitry.torokhov@gmail.com \
--cc=gkohli@codeaurora.org \
--cc=linux-input@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=martink@posteo.de \
--cc=mojha@codeaurora.org \
--cc=paulmck@linux.ibm.com \
--cc=peter.hutterer@who-t.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.