linux-kernel - Re: [BUG - btrfs] kernel oops in extent_range

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, 20 Jan 2012 14:54:41 -0600
From:	Mitch Harder <mitch.harder@...ayonlinux.org>
To:	Vincent Vanackere <vincent.vanackere@...il.com>
Cc:	linux-btrfs@...r.kernel.org,
	Linux kernel mailing list <linux-kernel@...r.kernel.org>
Subject: Re: [BUG - btrfs] kernel oops in extent_range_uptodate

On Fri, Jan 20, 2012 at 10:48 AM, Vincent Vanackere
<vincent.vanackere@...il.com> wrote:
> On 01/19/2012 05:24 PM, Mitch Harder wrote:
>>
>> On Thu, Jan 19, 2012 at 8:42 AM, Vincent Vanackere
>> <vincent.vanackere@...il.com>  wrote:
>>>
>>> Hi,
>>>
>>> With the most current git kernel
>>> (90a4c0f51e8e44111a926be6f4c87af3938a79c3)
>>> I'm still getting the same reproducible kernel panic when trying to read
>>> a
>>> particular file stored on a btrfs filesystem (as seen in the log there
>>> are
>>> indeed disk media errors on this disk).
>>> I'd like the "software" part of this to be fixed - btrfs should
>>> definitely
>>> not oops even in case of media error - before sending the disk to RMA. Is
>>> there anything I can do to make progress on this ?
>>>
>> Is this kernel compiled with "Compile the kernel with debug info" (in
>> the "Kernel hacking  --->" configuration section)?
>>
>> It would be nice to have the specific line of code passing the NULL
>> pointer.
>
>
> The kernel was compiled with debug information but modern linux distribution
> make it really hard to keep your debug information it seems :-(

I see where the find_get_page(...) function called in
extent_range_uptodate has the potential to return a NULL value.

Could you try the following patch, and if it solves your oops and
shows the included warning in your dmesg log, I'll simplify the patch
to drop the printk and submit it to the list.

I only included the printk since your current error log is ambiguous
regarding the specific point where we're getting the NULL pointer
dereference, but I'll pull it out if it works.

diff --git a/fs/btrfs/extent_io.c b/fs/btrfs/extent_io.c
index 9d09a4f..35c3a2a 100644
--- a/fs/btrfs/extent_io.c
+++ b/fs/btrfs/extent_io.c
@@ -3909,6 +3909,13 @@ int extent_range_uptodate(struct extent_io_tree *tree,
 	while (start <= end) {
 		index = start >> PAGE_CACHE_SHIFT;
 		page = find_get_page(tree->mapping, index);
+		if (unlikely(!page)) {
+			if (printk_ratelimit())
+ 				printk(KERN_WARNING
+ 				       "btrfs: NULL page in "
+ 				       "extent_range_uptodate()\n");
+			return 1;
+		}
 		uptodate = PageUptodate(page);
 		page_cache_release(page);
 		if (!uptodate) {
--
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/