linux-kernel - Re: [PATCH] fs: Fix mod_timer crash when removing USB sticks

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]

Date:	Fri, 16 Mar 2012 12:43:00 -0700
From:	Greg KH <greg@...ah.com>
To:	Paul Taysom <taysom@...gle.com>
Cc:	Paul Taysom <taysom@...omium.org>,
	Mandeep Baines <msb@...omium.org>,
	Jens Axboe <axboe@...nel.dk>, Theodore Tso <tytso@...gle.com>,
	Andrew Morton <akpm@...gle.com>, linux-usb@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	Alexander Viro <viro@...iv.linux.org.uk>,
	linux-fsdevel@...r.kernel.org, stable@...nel.org
Subject: Re: [PATCH] fs: Fix mod_timer crash when removing USB sticks

On Fri, Mar 16, 2012 at 12:29:15PM -0700, Paul Taysom wrote:
> On Fri, Mar 16, 2012 at 10:36 AM, Greg KH <greg@...ah.com> wrote:
> >
> > On Thu, Jan 12, 2012 at 01:57:11PM -0800, Paul Taysom wrote:
> > > A USB stick with a ext file system on it, would occasionally crash
> > > when the stick was pulled.
> > >
> > > The problem was a timer was being set on the Backing Device Interface,
> > > bdi, after the USB device had been removed and the bdi had been
> > > unregistered. The bdi would then be later reinitialized by zeroing
> > > the timer without removing from the timer from the timer queue.
> > > This would eventually result in a kernel crash (NULL ptr dereference).
> > >
> > > When the bdi is unregistered, the dev field is set to NULL. This
> > > indication is used by bdi_unregister to only unregister the device
> > > once.
> > >
> > > Fix: When the backing device is invalidated, the mapping
> > > backing_dev_info
> > > should be redirected to the default_backing_dev_info.
> > >
> > > Created 3 USB sticks with ext2, ext4 and one with both apple and DOS
> > > file systems on it. Inserted and removed USB sticks many times in random
> > > order. With out the bug fix, the kernel would soon crash. With the fix,
> > > it did not. Ran on both stumpy and amd64-generic.
> > >
> > > Signed-off-by: Paul Taysom <taysom@...omium.org>
> > > Cc: Mandeep Baines <msb@...omium.org>
> > > Cc: Greg KH <greg@...ah.com>
> > > Cc: Jens Axboe <axboe@...nel.dk>
> > > Cc: Theodore Tso <tytso@...gle.com>
> > > Cc: Andrew Morton <akpm@...gle.com>
> > > Cc: <linux-usb@...r.kernel.org>
> > > Cc: <linux-kernel@...r.kernel.org>
> > > Cc: Alexander Viro <viro@...iv.linux.org.uk>
> > > Cc: <linux-fsdevel@...r.kernel.org>
> > > Cc: <stable@...nel.org>
> > > ---
> > >  fs/block_dev.c |    1 +
> > >  1 files changed, 1 insertions(+), 0 deletions(-)
> > >
> > > diff --git a/fs/block_dev.c b/fs/block_dev.c
> > > index afe74dd..322cd05 100644
> > > --- a/fs/block_dev.c
> > > +++ b/fs/block_dev.c
> > > @@ -110,6 +110,7 @@ void invalidate_bdev(struct block_device *bdev)
> > >        * But, for the strange corners, lets be cautious
> > >        */
> > >       cleancache_flush_inode(mapping);
> > > +     mapping->backing_dev_info = &default_backing_dev_info;
> > >  }
> > >  EXPORT_SYMBOL(invalidate_bdev);
> >
> > What ever happened to this patch?  Is it still needed?  Can you still
> > reproduce the problem on Linus's tree and older kernels?
> >
> 
> 
> Never heard anything back.  Ted supplied a partial fix in 3.2.6 (I
> believe) for just the ext4 file system. Who should I follow up with?

If the fix went into the 3.2-stable tree, then it's in Linus's tree
already, which is good.

But, what about all of the other filesystems you hit this on, do we need
to make the same change to all of them?  If so, that kind of implies
your original patch is the correct one :)

As for who to poke, Ted, Al, Jens, what should we do here?

thanks,

greg k-h
--
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/