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

Message-Id: <1326398262-26660-1-git-send-email-taysom@chromium.org>
Date:	Thu, 12 Jan 2012 11:57:42 -0800
From:	Paul Taysom <taysom@...omium.org>
To:	unlisted-recipients:; (no To-header on input)
Cc:	Paul Taysom <taysom@...gle.com>, Paul Taysom <taysom@...omium.org>,
	Mandeep Baines <msb@...omium.org>, Greg KH <greg@...ah.com>,
	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>
Subject: [PATCH] fs: Fix mod_timer crash when removing USB sticks

From: Paul Taysom <taysom@...gle.com>

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>
Downstream-bug-report: http://crosbug.com/24165
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>
---
 fs/block_dev.c |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/fs/block_dev.c b/fs/block_dev.c
index afe74dd..9f9b617 100644
--- a/fs/block_dev.c
+++ b/fs/block_dev.c
@@ -1,4 +1,4 @@
-/*
+nvalid/*
  *  linux/fs/block_dev.c
  *
  *  Copyright (C) 1991, 1992  Linus Torvalds
@@ -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);

-- 
1.7.7.3

--
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/