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:	Mon, 21 Jul 2008 14:06:27 +0400
From:	Evgeniy Polyakov <johnpol@....mipt.ru>
To:	Pekka Enberg <penberg@...helsinki.fi>
Cc:	Ingo Molnar <mingo@...e.hu>, linux-kernel@...r.kernel.org,
	netdev@...r.kernel.org, Vegard Nossum <vegard.nossum@...il.com>,
	"Rafael J. Wysocki" <rjw@...k.pl>, cl@...ux-foundation.org,
	davem@...emloft.net
Subject: Re: [bug, netconsole, SLUB] BUG skbuff_head_cache: Poison overwritten

Hi.

On Mon, Jul 21, 2008 at 12:52:45PM +0300, Pekka Enberg (penberg@...helsinki.fi) wrote:
> On Mon, Jul 21, 2008 at 12:41 PM, Ingo Molnar <mingo@...e.hu> wrote:
> > update about this problem: just triggered another colorful crash, see
> > below. This was with the 4K object dump patch already, maybe the dump
> > gives a clue?
> 
> ...to point out the obvious:
> 
> > =============================================================================
> > BUG skbuff_head_cache: Poison overwritten
> > -----------------------------------------------------------------------------
> >
> > INFO: 0xf7ccc100-0xf7ccc103. First byte 0x0 instead of 0x6b
> > INFO: Allocated in __alloc_skb+0x30/0x10e age=1 cpu=1 pid=1
> > INFO: Freed in __kfree_skb+0x63/0x66 age=1 cpu=0 pid=0
> > INFO: Slab 0xc1c34ca0 objects=16 used=1 fp=0xf7ccc100 flags=0x400000c3
> > INFO: Object 0xf7ccc100 @offset=256 fp=0xf7ccc200
> >
> > Bytes b4 0xf7ccc0f0:  5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZZZZZZZZZ
> >  Object 0xf7ccc100:  00 00 00 00 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b ....kkkkkkkkkkkk
> 
> Use after free where first four bytes are zeroed.

Not that obvious...
skb->next is cleared in lots of places, in xmit network helper
for example, but since rest of the packet was not modified, it
means given skb was not freed, so it will not help.

Ingo do you see other similar dumps with last byte modified?
That's the one which can help to determine the reason.

-- 
	Evgeniy Polyakov
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ