Re: destroy_conntrack GPF in 3.7.9

[Dave Jones <davej@redhat.com>]

On Wed, Mar 06, 2013 at 10:59:55AM -0500, Dave Jones wrote:
 > I know 3.7.9 is EOL, but this code doesn't look like it's changed in current.
 > (unless the cause/fix was in code unrelated to these paths)
 > 
 > A user reported the following GPF..
 > 
 >         /* To make sure we don't get any weird locking issues here:
 >          * destroy_conntrack() MUST NOT be called with a write lock
 >          * to nf_conntrack_lock!!! -HW */
 >         rcu_read_lock();
 >         l4proto = __nf_ct_l4proto_find(nf_ct_l3num(ct), nf_ct_protonum(ct));
 >     1378:       0f b6 b3 86 00 00 00    movzbl 0x86(%rbx),%esi
 >     137f:       0f b7 7b 72             movzwl 0x72(%rbx),%edi
 >     1383:       e8 00 00 00 00          callq  1388 <destroy_conntrack+0x78>
 >         if (l4proto && l4proto->destroy)
 >     1388:       48 85 c0                test   %rax,%rax
 >     138b:       74 0e                   je     139b <destroy_conntrack+0x8b>
 >     138d:       48 8b 40 28             mov    0x28(%rax),%rax    <-----  HERE
 >     1391:       48 85 c0                test   %rax,%rax
 >     1394:       74 05                   je     139b <destroy_conntrack+0x8b>
 >                 l4proto->destroy(ct);
 >     1396:       48 89 df                mov    %rbx,%rdi
 >     1399:       ff d0                   callq  *%rax
 > 
 > 
 > l4proto (%rax) is garbage (0x50626b6b7876376c) which looks a little like ascii,
 > but P>kkxv7l doesn't mean much to me.
 > 
 > https://bugzilla.redhat.com/show_bug.cgi?id=917792 is the original report, but
 > there aren't any further details yet.

I just realised I reported this last September against 3.6

https://bugzilla.redhat.com/show_bug.cgi?id=859346
shows what looks like a use after free.  l4proto got freed somewhere.

	Dave