linux-ppp.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Guillaume Nault <g.nault@alphalink.fr>
To: Eric Biggers <ebiggers3@gmail.com>
Cc: linux-ppp@vger.kernel.org, Paul Mackerras <paulus@samba.org>,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	syzkaller-bugs@googlegroups.com,
	syzbot <syzbot+16363c99d4134717c05b@syzkaller.appspotmail.com>,
	viro@zeniv.linux.org.uk
Subject: Re: KASAN: use-after-free Read in remove_wait_queue (2)
Date: Wed, 23 May 2018 13:26:18 +0000	[thread overview]
Message-ID: <20180523132618.GA1569@alphalink.fr> (raw)
In-Reply-To: <20180523032958.GE658@sol.localdomain>

On Tue, May 22, 2018 at 08:29:58PM -0700, Eric Biggers wrote:
> On Fri, May 18, 2018 at 06:02:23PM +0200, Guillaume Nault wrote:
> > On Sun, May 13, 2018 at 11:11:55PM -0700, Eric Biggers wrote:
> > > [+ppp list and maintainer]
> > > 
> > > This is a bug in ppp_generic.c; it still happens on Linus' tree and it's easily
> > > reproducible, see program below.  The bug is that the PPPIOCDETACH ioctl doesn't
> > > consider that the file can still be attached to epoll instances even when
> > > ->f_count = 1.
> > 
> > Right. What would it take to remove the file for the epoll instances?
> > Sorry for the naive question, but I'm not familiar with VFS and didn't
> > find a helper function we could call.
> > 
> 
> There is eventpoll_release_file(), but it's not exported to modules.  It might
> work to call it, but it seems like a hack.
> 
> > > Also, the reproducer doesn't test this but I think ppp_poll(),
> > > ppp_read(), and ppp_write() can all race with PPPIOCDETACH, causing
> > > use-after-frees as well.
> > 
> > I also believe so. ppp_release() resets ->private_data, and even though
> > functions like ppp_read() test ->private_data before executing, there's
> > no synchronisation mechanism to ensure that the update is visible
> > before the unit or channel is destroyed. Is that the kind of race you
> > had in mind?
> 
> Yes, though after looking into it more I *think* these additional races aren't
> actually possible, due to the 'f_count < 2' check.  These races could only
> happen with a shared fd table, but in that case fdget() would increment f_count
> for the duration of each operation, resulting in 'f_count >= 2' if both ioctl()
> and something else is running on the same file concurrently.
> 
> Note that this also means PPPIOCDETACH doesn't work at all if called from a
> multithreaded application...
> 
> > 
> > > Any chance that PPPIOCDETACH can simply be removed,
> > > given that it's apparently been "deprecated" for 16 years?
> > > Does anyone use it?
> > 
> > The only users I'm aware of are pppd versions older than ppp-2.4.2
> > (released in November 2003). But even at that time, there were issues
> > with PPPIOCDETACH as pppd didn't seem to react properly when this call
> > failed. An Internet search on the "PPPIOCDETACH file->f_count=" kernel
> > log string, or on the "Couldn't release PPP unit: Invalid argument"
> > error message of pppd, returns several related bug reports.
> > 
> > Originally, PPPIOCDETACH never failed, but testing ->f_count was
> > later introduced to fix crashes when the file descriptor had been
> > duplicated. It seems that this was motivated by polling issues too.
> > 
> > Long story short, it looks like PPPIOCDETACH never has worked well
> > and we have at least two more bugs to fix. Given how it has proven
> > fragile, I wouldn't be surprised if there were even more lurking
> > around. I'd say that it's probably safer to drop it than to add more
> > workarounds and playing wack-a-mole with those bugs.
> 
> IMO, if we can get away with removing it without any users noticing, that would
> be much better than trying to fix it with a VFS-level hack, and probably missing
> some cases.  I'll send a patch to get things started...
> 
Yes, I fully agree. That looks much safer, and given the track record
of this ioctl I very much doubt anyone would depend on it.

      parent reply	other threads:[~2018-05-23 13:26 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <f403043d0f18f879cc056648a875@google.com>
2018-05-14  6:11 ` Eric Biggers
2018-05-18 16:02   ` Guillaume Nault
2018-05-23  3:29     ` Eric Biggers
2018-05-23  3:59       ` [PATCH] ppp: remove the PPPIOCDETACH ioctl Eric Biggers
2018-05-23 13:57         ` Guillaume Nault
2018-05-23 15:56           ` David Miller
2018-05-23 21:17             ` Eric Biggers
2018-05-23 21:37         ` [PATCH v2] " Eric Biggers
2018-05-23 23:04           ` Paul Mackerras
2018-05-24 14:04           ` Guillaume Nault
2018-05-25  2:55           ` David Miller
2018-06-06  9:01           ` Walter Harms
2018-05-23 13:26       ` Guillaume Nault [this message]

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=20180523132618.GA1569@alphalink.fr \
    --to=g.nault@alphalink.fr \
    --cc=ebiggers3@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-ppp@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=paulus@samba.org \
    --cc=syzbot+16363c99d4134717c05b@syzkaller.appspotmail.com \
    --cc=syzkaller-bugs@googlegroups.com \
    --cc=viro@zeniv.linux.org.uk \
    --subject='Re: KASAN: use-after-free Read in remove_wait_queue (2)' \
    /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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).