Unknown Attribute 5/conntrack -L

Unknown Attribute 5/conntrack -L

[Krzysztof Oledzki]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 234 bytes --]

Hello,

What does "Unknown Attribute 5" mean? I can see this error when running 
"conntrack -L".

I have current version of conntrack/libnetfilter_conntrack/libnfnetlink 
taken from SVN.

Best regards,

 			Krzysztof Olędzki

Re: Unknown Attribute 5/conntrack -L

[Pablo Neira]

Krzysztof Oledzki wrote:
> Hello,
> 
> What does "Unknown Attribute 5" mean? I can see this error when running 
> "conntrack -L".
> 
> I have current version of conntrack/libnetfilter_conntrack/libnfnetlink 
> taken from SVN.

Please refresh your working copy. Does the problem still remain? 
Appreciate a more detailed description of the problem. Thanks!

-- 
Pablo

Re: Unknown Attribute 5/conntrack -L

[Krzysztof Oledzki]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 530 bytes --]



On Sun, 30 Oct 2005, Pablo Neira wrote:

> Krzysztof Oledzki wrote:
>> Hello,
>> 
>> What does "Unknown Attribute 5" mean? I can see this error when running 
>> "conntrack -L".
>> 
>> I have current version of conntrack/libnetfilter_conntrack/libnfnetlink 
>> taken from SVN.
>
> Please refresh your working copy. Does the problem still remain?

No. It is fixed now. Thank you. :)

Best regards,

 			Krzysztof Olędzki

PS: Would you find some time to look at http://bugzilla.kernel.org/show_bug.cgi?id=5438

Re: Unknown Attribute 5/conntrack -L

[Pablo Neira]

Krzysztof Oledzki wrote:
>>> What does "Unknown Attribute 5" mean? I can see this error when 
>>> running "conntrack -L".
>>>
>>> I have current version of 
>>> conntrack/libnetfilter_conntrack/libnfnetlink taken from SVN.
>>
>> Please refresh your working copy. Does the problem still remain?
> 
> No. It is fixed now. Thank you. :)

Great ;)

> PS: Would you find some time to look at 
> http://bugzilla.kernel.org/show_bug.cgi?id=5438

Can you still trigger that oops with the current working copy from SVN?

-- 
Pablo

Re: Unknown Attribute 5/conntrack -L

[Krzysztof Oledzki]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 548 bytes --]



On Mon, 31 Oct 2005, Pablo Neira wrote:
<CUT>
>> PS: Would you find some time to look at 
>> http://bugzilla.kernel.org/show_bug.cgi?id=5438
>
> Can you still trigger that oops with the current working copy from SVN?

IMHO this is a kernel bug. And to be clear: there is no problem with new 
version of userspace application/libraries.

The problem apperas only with _old_ library. There were a lot of API 
changes and probably kernel does not properly validate user data 
(boudaries?).


Best regards,


 			Krzysztof Olędzki

Re: Unknown Attribute 5/conntrack -L

[Pablo Neira]

Krzysztof Oledzki wrote:
> On Mon, 31 Oct 2005, Pablo Neira wrote:
> <CUT>
> 
>>> PS: Would you find some time to look at 
>>> http://bugzilla.kernel.org/show_bug.cgi?id=5438
>>
>>
>> Can you still trigger that oops with the current working copy from SVN?
> 
> IMHO this is a kernel bug. And to be clear: there is no problem with new 
> version of userspace application/libraries.
> 
> The problem apperas only with _old_ library. There were a lot of API 
> changes and probably kernel does not properly validate user data 
> (boudaries?).

Since the old libnfnetlink_conntrack release, some changes have been 
introduced in kernel space. The corresponding changes to the userspace 
libraries were applied to keep both in sync. To be frank, I'd worry 
about fixing the current bugs, focus on the new libraries and do the 
first 1.0 official release asap.

-- 
Pablo

Re: Unknown Attribute 5/conntrack -L

[Krzysztof Oledzki]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1087 bytes --]



On Mon, 31 Oct 2005, Pablo Neira wrote:

> Krzysztof Oledzki wrote:
>> On Mon, 31 Oct 2005, Pablo Neira wrote:
>> <CUT>
>> 
>>>> PS: Would you find some time to look at 
>>>> http://bugzilla.kernel.org/show_bug.cgi?id=5438
>>> 
>>> 
>>> Can you still trigger that oops with the current working copy from SVN?
>> 
>> IMHO this is a kernel bug. And to be clear: there is no problem with new 
>> version of userspace application/libraries.
>> 
>> The problem apperas only with _old_ library. There were a lot of API 
>> changes and probably kernel does not properly validate user data 
>> (boudaries?).
>
> Since the old libnfnetlink_conntrack release, some changes have been 
> introduced in kernel space. The corresponding changes to the userspace 
> libraries were applied to keep both in sync. To be frank, I'd worry about 
> fixing the current bugs, focus on the new libraries and do the first 1.0 
> official release asap.

OK, this can wait. I'll remind about this problem after the first 
1.0 official release.

Best regards,

 			Krzysztof Olędzki

Re: Unknown Attribute 5/conntrack -L

[Yasuyuki KOZAKAI]

[-- Attachment #1: Type: Text/Plain, Size: 1444 bytes --]


Hi,

From: Krzysztof Oledzki <olenf@ans.pl>
Date: Mon, 31 Oct 2005 15:46:10 +0100 (CET)

> On Mon, 31 Oct 2005, Pablo Neira wrote:
> 
> > Krzysztof Oledzki wrote:
> >> On Mon, 31 Oct 2005, Pablo Neira wrote:
> >> <CUT>
> >> 
> >>>> PS: Would you find some time to look at 
> >>>> http://bugzilla.kernel.org/show_bug.cgi?id=5438
> >>> 
> >>> 
> >>> Can you still trigger that oops with the current working copy from SVN?
> >> 
> >> IMHO this is a kernel bug. And to be clear: there is no problem with new 
> >> version of userspace application/libraries.
> >> 
> >> The problem apperas only with _old_ library. There were a lot of API 
> >> changes and probably kernel does not properly validate user data 
> >> (boudaries?).

I'm not sure it's the reason of oops, but at least attached patch fixes
double free after netlink_unicast(). Krzysztof, could you try this ?


> > Since the old libnfnetlink_conntrack release, some changes have been 
> > introduced in kernel space. The corresponding changes to the userspace 
> > libraries were applied to keep both in sync. To be frank, I'd worry about 
> > fixing the current bugs, focus on the new libraries and do the first 1.0 
> > official release asap.
> 
> OK, this can wait. I'll remind about this problem after the first 
> 1.0 official release.

I don't think so. Deti reports similer oops on 2.6.14 which has been already
out, so this should be fixed asap.

Regards,

-- Yasuyuki Kozakai

[-- Attachment #2: ct-netlink-double-free.patch --]
[-- Type: Text/Plain, Size: 1794 bytes --]

[NETFILTER] fix double free after netlink_unicast() in ctnetlink

It's not necessary to free skb if netlink_unicast() failed.

Signed-off-by: Yasuyuki Kozakai <yasuyuki.kozakai@toshiba.co.jp>

---
commit 1d9b24503bcaf3c5c809a05822bbbbaacc657781
tree af11ba2c560f1f642cc7ac3c8c8c8b883ef24b1e
parent 991ce06b3db463c6cdf8d5a0b0d70bf22c499fef
author Yasuyuki Kozakai <yasuyuki.kozakai@toshiba.co.jp> Tue, 01 Nov 2005 03:37:24 +0900
committer Yasuyuki Kozakai <yasuyuki.kozakai@toshiba.co.jp> Tue, 01 Nov 2005 03:37:24 +0900

 net/ipv4/netfilter/ip_conntrack_netlink.c |   19 +++++++------------
 1 files changed, 7 insertions(+), 12 deletions(-)

diff --git a/net/ipv4/netfilter/ip_conntrack_netlink.c b/net/ipv4/netfilter/ip_conntrack_netlink.c
--- a/net/ipv4/netfilter/ip_conntrack_netlink.c
+++ b/net/ipv4/netfilter/ip_conntrack_netlink.c
@@ -815,7 +815,7 @@ ctnetlink_get_conntrack(struct sock *ctn
 				  IPCTNL_MSG_CT_NEW, 1, ct);
 	ip_conntrack_put(ct);
 	if (err <= 0)
-		goto out;
+		goto free;
 
 	err = netlink_unicast(ctnl, skb2, NETLINK_CB(skb).pid, MSG_DONTWAIT);
 	if (err < 0)
@@ -824,9 +824,9 @@ ctnetlink_get_conntrack(struct sock *ctn
 	DEBUGP("leaving\n");
 	return 0;
 
+free:
+	kfree_skb(skb2);
 out:
-	if (skb2)
-		kfree_skb(skb2);
 	return -1;
 }
 
@@ -1322,21 +1322,16 @@ ctnetlink_get_expect(struct sock *ctnl, 
 				      nlh->nlmsg_seq, IPCTNL_MSG_EXP_NEW,
 				      1, exp);
 	if (err <= 0)
-		goto out;
+		goto free;
 
 	ip_conntrack_expect_put(exp);
 
-	err = netlink_unicast(ctnl, skb2, NETLINK_CB(skb).pid, MSG_DONTWAIT);
-	if (err < 0)
-		goto free;
-
-	return err;
+	return netlink_unicast(ctnl, skb2, NETLINK_CB(skb).pid, MSG_DONTWAIT);
 
+free:
+	kfree_skb(skb2);
 out:
 	ip_conntrack_expect_put(exp);
-free:
-	if (skb2)
-		kfree_skb(skb2);
 	return err;
 }
 

Re: Unknown Attribute 5/conntrack -L

[Deti Fliegl]

Hi Yasuyuki,

> I'm not sure it's the reason of oops, but at least attached patch fixes
> double free after netlink_unicast(). Krzysztof, could you try this ?
Tried it with 2.6.14 - after 20 minutes of calling conntrack -L in an 
endless loop (with ~20000 entries and 800Mbit/s load) it happened again:

<4>Badness in __kfree_skb at net/core/skbuff.c:330
<4>
<4>Call Trace:<ffffffff802a2f77>{__kfree_skb+167} 
<ffffffff802bb597>{netlink_recvmsg+279}
<4>       <ffffffff8029cb2b>{sock_recvmsg+315} 
<ffffffff8019b457>{update_atime+151}
<4>       <ffffffff8015ddfa>{do_generic_mapping_read+1098} 
<ffffffff80161311>{buffered_rmqueue+529}
<4>       <ffffffff8012fbe5>{activate_task+149} 
<ffffffff8013003b>{try_to_wake_up+1083}
<4>       <ffffffff8014b2f0>{autoremove_wake_function+0} 
<ffffffff8029e38b>{sys_recvmsg+395}
<4>       <ffffffff8018e477>{pipe_writev+1319} 
<ffffffff80181208>{vfs_write+344}
<4>       <ffffffff80181343>{sys_write+83} 
<ffffffff8010dc4e>{system_call+126}
<4>
<4>Badness in __kfree_skb at net/core/skbuff.c:330
<4>
<4>Call Trace:<ffffffff802a2f77>{__kfree_skb+167} 
<ffffffff802bb597>{netlink_recvmsg+279}
<4>       <ffffffff8029cb2b>{sock_recvmsg+315} 
<ffffffff8019b457>{update_atime+151}
<4>       <ffffffff8015ddfa>{do_generic_mapping_read+1098} 
<ffffffff80161311>{buffered_rmqueue+529}
<4>       <ffffffff8012fbe5>{activate_task+149} 
<ffffffff8013003b>{try_to_wake_up+1083}
<4>       <ffffffff8014b2f0>{autoremove_wake_function+0} 
<ffffffff8029e38b>{sys_recvmsg+395}
<4>       <ffffffff8018e477>{pipe_writev+1319} 
<ffffffff80181208>{vfs_write+344}
<4>       <ffffffff80181343>{sys_write+83} 
<ffffffff8010dc4e>{system_call+126}
<4>
<4>Badness in __kfree_skb at net/core/skbuff.c:330
<4>
<4>Call Trace:<ffffffff802a2f77>{__kfree_skb+167} 
<ffffffff802bb597>{netlink_recvmsg+279}
<4>       <ffffffff8029cb2b>{sock_recvmsg+315} 
<ffffffff8019b457>{update_atime+151}
<4>       <ffffffff8015ddfa>{do_generic_mapping_read+1098} 
<ffffffff80161311>{buffered_rmqueue+529}
<4>       <ffffffff8012fbe5>{activate_task+149} 
<ffffffff8013003b>{try_to_wake_up+1083}
<4>       <ffffffff8014b2f0>{autoremove_wake_function+0} 
<ffffffff8029e38b>{sys_recvmsg+395}
<4>       <ffffffff8018e477>{pipe_writev+1319} 
<ffffffff80181208>{vfs_write+344}
<4>       <ffffffff80181343>{sys_write+83} 
<ffffffff8010dc4e>{system_call+126}
<4>
<3>scheduling while atomic: conntrack/0xffffff00/32033
<4>
<4>Call Trace:<ffffffff8031d67d>{schedule+125} 
<ffffffff80181208>{vfs_write+344}
<4>       <ffffffff80181343>{sys_write+83} 
<ffffffff8010dcb8>{sysret_careful+13}
<4>


> I don't think so. Deti reports similer oops on 2.6.14 which has been already
> out, so this should be fixed asap.
good idea.

Deti

Re: Unknown Attribute 5/conntrack -L

[Harald Welte]

[-- Attachment #1: Type: text/plain, Size: 728 bytes --]

On Tue, Nov 01, 2005 at 04:02:07AM +0900, Yasuyuki KOZAKAI wrote:

> I'm not sure it's the reason of oops, but at least attached patch fixes
> double free after netlink_unicast(). Krzysztof, could you try this ?

thanks yasyuki.  I'll submit this to mainline, since it is a bugfix,
even if it doesn't fix the problem that was reported originally. 

-- 
- Harald Welte <laforge@netfilter.org>                 http://netfilter.org/
============================================================================
  "Fragmentation is like classful addressing -- an interesting early
   architectural error that shows how much experimentation was going
   on while IP was being designed."                    -- Paul Vixie

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Unknown Attribute 5/conntrack -L

[Krzysztof Oledzki]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 5435 bytes --]



On Tue, 1 Nov 2005, Yasuyuki KOZAKAI wrote:

>
> Hi,
>
> From: Krzysztof Oledzki <olenf@ans.pl>
> Date: Mon, 31 Oct 2005 15:46:10 +0100 (CET)
>
>> On Mon, 31 Oct 2005, Pablo Neira wrote:
>>
>>> Krzysztof Oledzki wrote:
>>>> On Mon, 31 Oct 2005, Pablo Neira wrote:
>>>> <CUT>
>>>>
>>>>>> PS: Would you find some time to look at
>>>>>> http://bugzilla.kernel.org/show_bug.cgi?id=5438
>>>>>
>>>>>
>>>>> Can you still trigger that oops with the current working copy from SVN?
>>>>
>>>> IMHO this is a kernel bug. And to be clear: there is no problem with new
>>>> version of userspace application/libraries.
>>>>
>>>> The problem apperas only with _old_ library. There were a lot of API
>>>> changes and probably kernel does not properly validate user data
>>>> (boudaries?).
>
> I'm not sure it's the reason of oops, but at least attached patch fixes
> double free after netlink_unicast(). Krzysztof, could you try this ?

Tested. Kernel still generates BUG & oopses:

------------[ cut here ]------------
kernel BUG at kernel/sched.c:2819!
invalid operand: 0000 [#1]
PREEMPT
Modules linked in: bonding
CPU:    0
EIP:    0060:[<c011a828>]    Not tainted VLI
EFLAGS: 00010086   (2.6.14)
EIP is at add_preempt_count+0x28/0x40
eax: c03e1d95   ebx: c15c9a54   ecx: 00000001   edx: dc8c2000
esi: df55fd00   edi: 00000292   ebp: dc8c2000   esp: dc8c2000
ds: 007b   es: 007b   ss: 0068
Process conntrack (pid: 298, threadinfo=dc8c1000 task=dce60a90)
Stack:
Call Trace:
  =======================
  [<c03b36f0>] sock_rfree+0x0/0x20
  =======================
Unable to handle kernel NULL pointer dereference at virtual address 00000006
  printing eip:
c0103f2e
*pde = 00000000
Oops: 0000 [#2]
PREEMPT
Modules linked in: bonding
CPU:    0
EIP:    0060:[<c0103f2e>]    Not tainted VLI
EFLAGS: 00010097   (2.6.14)
EIP is at show_trace+0x2e/0x90
eax: 00000ffd   ebx: 00000006   ecx: 00000000   edx: 00000001
esi: 00000006   edi: 00000000   ebp: 00000068   esp: dc8c1e60
ds: 007b   es: 007b   ss: 0068
Process conntrack (pid: 298, threadinfo=dc8c1000 task=dce60a90)
Stack: c04f258e c03b36f0 dc8c2000 00000000 00000000 c0104010 00000000 dc8c2000
        c063d760 dc8c1fcc 00000000 c01041af 00000000 dc8c2000 0000012a dc8c1000
        dce60a90 00010086 c05654a2 00000001 00000000 dc8c1fcc c04f267e dc8c2000
Call Trace:
  [<c03b36f0>] sock_rfree+0x0/0x20
  [<c0104010>] show_stack+0x80/0xa0
  [<c01041af>] show_registers+0x15f/0x1d0
  [<c01043c7>] die+0xf7/0x1a0
  [<c0104720>] do_invalid_op+0x0/0xd0
  [<c01047d2>] do_invalid_op+0xb2/0xd0
  [<c011a828>] add_preempt_count+0x28/0x40
  [<c0103ccf>] error_code+0x4f/0x54
  [<c03e1d95>] netlink_sendskb+0x25/0x60
  [<c011a828>] add_preempt_count+0x28/0x40
Code: 83 ec 08 8b 5c 24 1c 89 df 89 de 81 e7 00 f0 ff ff 8d b6 00 00 00 00 8d bf 00 00 00 00 39 fe 76 49 8d 87 fd 0f 00 00 39
  <6>note: conntrack[298] exited with preempt_count 3
Unable to handle kernel paging request at virtual address 08a80920
  printing eip:
c0120a9c
*pde = 00000000
Oops: 0002 [#3]
PREEMPT
Modules linked in: bonding
CPU:    0
EIP:    0060:[<c0120a9c>]    Not tainted VLI
EFLAGS: 00010246   (2.6.14)
EIP is at do_exit+0x1ec/0x490
eax: 08a80840   ebx: 08a80840   ecx: 00000001   edx: dc8c1000
esi: dce60a90   edi: dc8c1000   ebp: 0000000b   esp: dc8c1d68
ds: 007b   es: 007b   ss: 0068
Process conntrack (pid: 298, threadinfo=dc8c1000 task=dce60a90)
Stack: dffeea80 c0661af8 0000012a 00000003 00000001 dc8c1000 dc8c1e2c c04f3d93
        0000000e c010446f dce60a90 00000001 dc8c1da0 00000002 dc8c1e2c c04f3d93
        00000000 000000ff 0000000b 0000000e c04f3d31 00000006 00000000 0000000e
Call Trace:
  [<c010446f>] die+0x19f/0x1a0
  [<c04b59de>] do_page_fault+0x2ee/0x623
  [<c04b56f0>] do_page_fault+0x0/0x623
  [<c0103ccf>] error_code+0x4f/0x54
  [<c0103f2e>] show_trace+0x2e/0x90
  [<c03b36f0>] sock_rfree+0x0/0x20
  [<c0104010>] show_stack+0x80/0xa0
  [<c01041af>] show_registers+0x15f/0x1d0
  [<c01043c7>] die+0xf7/0x1a0
  [<c0104720>] do_invalid_op+0x0/0xd0
  [<c01047d2>] do_invalid_op+0xb2/0xd0
  [<c011a828>] add_preempt_count+0x28/0x40
  [<c0103ccf>] error_code+0x4f/0x54
  [<c03e1d95>] netlink_sendskb+0x25/0x60
  [<c011a828>] add_preempt_count+0x28/0x40
Code: 00 85 c0 0f 85 00 01 00 00 8b 46 04 8b 40 04 8b 58 24 85 db 74 40 b8 01 00 00 00 e8 6f 9d ff ff e8 8a 76 15 00 c1 e0 05
  <1>Fixing recursive fault but reboot is needed!
scheduling while atomic: conntrack/0x00000004/298
  [<c04b3e72>] schedule+0x632/0x640
  [<c0105509>] do_IRQ+0x59/0x80
  [<c0120cc7>] do_exit+0x417/0x490
  [<c010446f>] die+0x19f/0x1a0
  [<c04b59de>] do_page_fault+0x2ee/0x623
  [<c04b56f0>] do_page_fault+0x0/0x623
  [<c0103ccf>] error_code+0x4f/0x54
  [<c0120a9c>] do_exit+0x1ec/0x490
  [<c010446f>] die+0x19f/0x1a0
  [<c04b59de>] do_page_fault+0x2ee/0x623
  [<c04b56f0>] do_page_fault+0x0/0x623
  [<c0103ccf>] error_code+0x4f/0x54
  [<c0103f2e>] show_trace+0x2e/0x90
  [<c03b36f0>] sock_rfree+0x0/0x20
  [<c0104010>] show_stack+0x80/0xa0
  [<c01041af>] show_registers+0x15f/0x1d0
  [<c01043c7>] die+0xf7/0x1a0
  [<c0104720>] do_invalid_op+0x0/0xd0
  [<c01047d2>] do_invalid_op+0xb2/0xd0
  [<c011a828>] add_preempt_count+0x28/0x40
  [<c0103ccf>] error_code+0x4f/0x54
  [<c03e1d95>] netlink_sendskb+0x25/0x60
  [<c011a828>] add_preempt_count+0x28/0x40


Best regards,

 				Krzysztof Olędzki