linux-kernel - Re: BUG:: NULL ptr de-ref in drop

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20120524144925.GA8975@quack.suse.cz>
Date:	Thu, 24 May 2012 16:49:25 +0200
From:	Jan Kara <jack@...e.cz>
To:	Sam Portolla <samportolla@...oo.com>
Cc:	":" <linux-kernel@...r.kernel.org>
Subject: Re: BUG:: NULL ptr de-ref in drop_buffers

On Fri 18-05-12 23:41:31, Sam Portolla wrote:
> Hi,
> 
> Please include my email address above in the reply as not a subscriber; reporting a bug and looking for a fix please.
> 
> 
> Seen a previous discussion of this in 2.6.26 under bug 395849, but it does not mention a fix.
> 
> In this case, the issue happened on 2.6.23 GNU/Linux w/ x86_64 arch. 
  That is a really old kernel ;)

> Logs showing the issue followed by some analysis:
> 
> Unable to handle kernel NULL pointer dereference at 0000000000000000 RIP: 
>  [<ffffffff802b3e69>] drop_buffers+0x29/0x120
> 
> RIP: 0010:[<ffffffff802b3e69>]  [<ffffffff802b3e69>] drop_buffers+0x29/0x120
> RSP: 0000:ffff81026033bb00  EFLAGS: 00010207
> RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffff81025c48c7d8
> RDX: 0000000000000000 RSI: ffff81026033bb40 RDI: ffff81026fb7c238
> RBP: ffff81026033bb30 R08: 00000000ffffffff R09: 0000000000000001
> R10: 0000000000000000 R11: 0000000000000003 R12: ffff81024ecc4000
> R13: ffff81025c48c7d8 R14: ffff81026fb7c238 R15: ffff81026033bb40
> FS:  0000000000000000(0000) GS:ffff810267703400(0000) knlGS:0000000000000000
> CS:  0010 DS: 0018 ES: 0018 CR0: 000000008005003b
> CR2: 0000000000000000 CR3: 000000002b8a4000 CR4: 00000000000006e0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> Process kswapd0 (pid: 322, threadinfo ffff810260338000, task ffff810262108000)
> Stack:  ffff81026f9ac638 ffff81026fb7c238 ffff81025c48c7d8 ffff81025c48c7d8
>  ffff81026033bd90 0000000000000001 ffff81026033bb60 ffffffff802b41c6
>  0000000000000000 ffff81026fb7c238 ffff81026033be80 ffff81025c48c7d8
> Call Trace:
>  [<ffffffff802b41c6>] try_to_free_buffers+0x46/0xb0
>  [<ffffffff80264c8e>] try_to_release_page+0x2e/0x50
>  [<ffffffff8026bf73>] shrink_page_list+0x533/0x6f0
>  [<ffffffff8026aa09>] release_pages+0x189/0x1c0
>  [<ffffffff8026c273>] isolate_lru_pages+0xd3/0x1e0
>  [<ffffffff8026c523>] shrink_inactive_list+0x163/0x410
>  [<ffffffff8026cde5>] shrink_zone+0xf5/0x140
>  [<ffffffff8026d507>] kswapd+0x387/0x540
>  [<ffffffff802475e0>] autoremove_wake_function+0x0/0x40
>  [<ffffffff8026d180>] kswapd+0x0/0x540
>  [<ffffffff80246ef8>] kthread+0x68/0xa0
>  [<ffffffff80229e24>] schedule_tail+0x54/0xc0
>  [<ffffffff8020d058>] child_rip+0xa/0x12
>  [<ffffffff80246e90>] kthread+0x0/0xa0
>  [<ffffffff8020d04e>] child_rip+0x0/0x12
> 
> #### from GDB, the bh pointer in the 1st do/while loop in the drop_buffers() is NULL.
> 
> 
> struct buffer_head *head(%r12)
> This the 1st do/while loop:
> 
> 0xffffffff802b3e69 <drop_buffers+41>:   mov    (%rbx),%eax
> 
> 0xffffffff802b3e8d <drop_buffers+77>:   mov    0x8(%rbx),%rbx
> 0xffffffff802b3e91 <drop_buffers+81>:   cmp    %r12,%rbx
> 0xffffffff802b3e94 <drop_buffers+84>:   jne    0xffffffff802b3e69 <drop_buffers+41>
> 
> RBX: 0000000000000000
> 
> 
> 2825                    bh = bh->b_this_page;
> 2826            } while (bh != head);
> 
> In this do/while loop, the bh is NULL as %rbx
  I see. Reports of this problem appear from time to time - page which
should have buffers attached (had PagePrivate bit set just a moment ago) but
it does not have any. But usually this is completely unreproducible so it's
not clear whether it's caused by a memory bit-flip or some real problem.
Also the fact that you saw the problem with 2.6.23 does not relly make it
very attractive to debug. Sorry.

  But if you can reproduce the problem, especially with newer kernel, I'd
be interested in hearing it.

								Honza
-- 
Jan Kara <jack@...e.cz>
SUSE Labs, CR
--
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/