Le jeudi 27 mai 2010 à 12:27 -0700, Linus Torvalds a écrit :

On Thu, 27 May 2010, Ingo Molnar wrote:

quoted

FYI, this boot crash in arp_error_report() started triggering in -tip testing:

[  113.285384] BUG: unable to handle kernel paging request at 6b6b6b87

That's the POISON_FREE signature, with an offset of 28 (0x1c).

And it looks like the whole function got captured in the Code: sequence. 
It looks like this:

   0:	55                   	push   %ebp
   1:	89 e5                	mov    %esp,%ebp
   3:	53                   	push   %ebx
   4:	0f 1f 44 00 00       	nopl   0x0(%eax,%eax,1)
   9:	89 d3                	mov    %edx,%ebx
   b:	89 d0                	mov    %edx,%eax
   d:	e8 fa fb ff ff       	call   0xfffffc0c		# skb_dst()
  12:	85 c0                	test   %eax,%eax		# dst
  14:	74 12                	je     0x28
  16:	8b 40 40             	mov    0x40(%eax),%eax		# dst->ops
  19:	85 c0                	test   %eax,%eax
  1b:	74 0b                	je     0x28
  1d:*	8b 50 1c             	mov    0x1c(%eax),%edx     <-- trapping instruction
  20:	85 d2                	test   %edx,%edx
  22:	74 04                	je     0x28
  24:	89 d8                	mov    %ebx,%eax
  26:	ff d2                	call   *%edx			# dst->ops->link_failure()
  28:	89 d8                	mov    %ebx,%eax
  2a:	e8 9b 50 fa ff       	call   0xfffa50ca		# skb_free()
  2f:	5b                   	pop    %ebx
  30:	5d                   	pop    %ebp
  31:	c3                   	ret    

Where most of it is "dst_link_failure()" being inlined (that last "callq" 
is the call to kfree_skb().

Looks like 'dst' points to free'd memory, so when we load a pointer from 
it (the dst->ops) field, we get 0x6b6b6b6b, and then when we try to load
dst->ops->link_failure it oopses.

tl;dr: that

	struct dst_entry *dst = skb_dst(skb);

in dst_link_failure seems to result in a stale skb.

		Linus
--

I am looking at this bug report, as I am probably at fault, please give
me one or two hour ;)

Thanks