* Unable to handle kernel NULL pointer dereference at virtual address 00000000 after conntrack -I
@ 2005-11-03 13:14 Krzysztof Oledzki
2005-11-03 19:55 ` Pablo Neira
0 siblings, 1 reply; 7+ messages in thread
From: Krzysztof Oledzki @ 2005-11-03 13:14 UTC (permalink / raw)
To: Pablo Neira; +Cc: netfilter-devel
[-- Attachment #1: Type: TEXT/PLAIN, Size: 2398 bytes --]
Hello,
# conntrack -I --orig-src 1.2.3.4 --orig-dst 1.2.3.5 --reply-src 2.3.4.5 --reply-dst 2.3.4.5 -p tcp --orig-port-src 1 --orig-port-dst 2 --reply-port-src 3 --reply-port-dst 4 -t 32323 -u ASSURED
Unable to handle kernel NULL pointer dereference at virtual address 00000000
printing eip:
c0429a29
*pde = 00000000
Oops: 0000 [#1]
PREEMPT
Modules linked in: bonding
CPU: 0
EIP: 0060:[<c0429a29>] Not tainted VLI
EFLAGS: 00010282 (2.6.14)
EIP is at nfattr_to_tcp+0x9/0x90
eax: c2dcbb60 ebx: dbcc0320 ecx: 00000001 edx: 00000000
esi: 00000006 edi: c0594a00 ebp: c2dcbb60 esp: c2dcbb34
ds: 007b es: 007b ss: 0068
Process conntrack (pid: 13870, threadinfo=c2dcb000 task=d97415a0)
Stack: c042816e 00000006 dbcc0320 00000006 00000000 c042dfbc c2dcbb60 dbcc0320
d9b074a0 00000004 00000000 00000000 d692e920 00000000 00000007 c6429ea4
c6429ea4 d9b07414 d9b07400 c01233d3 d9b07414 c2dcbc70 c0594a00 d9b07400
Call Trace:
[<c042816e>] ip_conntrack_proto_find_get+0x7e/0xb0
[<c042dfbc>] ctnetlink_create_conntrack+0x18c/0x2c0
[<c01233d3>] local_bh_enable+0x33/0xa0
[<c042e1ee>] ctnetlink_new_conntrack+0xfe/0x4e0
[<c011a963>] __wake_up+0x53/0x80
[<c01bb2ee>] journal_stop+0x18e/0x280
[<c0454131>] nfnetlink_rcv+0x271/0x2c7
[<c03e2c8b>] netlink_data_ready+0x6b/0x70
[<c03e1da2>] netlink_sendskb+0x32/0x60
[<c03e28db>] netlink_sendmsg+0x20b/0x310
[<c01ac708>] ext3_mark_iloc_dirty+0x28/0x40
[<c01b1094>] __ext3_journal_stop+0x24/0x50
[<c03b073a>] sock_sendmsg+0xda/0x100
[<c0186696>] __mark_inode_dirty+0x1a6/0x1b0
[<c017d7a6>] update_atime+0x96/0xb0
[<c02777a6>] copy_from_user+0x46/0x80
[<c01339f0>] autoremove_wake_function+0x0/0x60
[<c03b21bf>] sys_sendmsg+0x18f/0x1f0
[<c014522e>] __alloc_pages+0x2fe/0x480
[<c014a909>] lru_cache_add_active+0x39/0x70
[<c0150910>] do_anonymous_page+0x100/0x160
[<c0150ea0>] __handle_mm_fault+0xf0/0x1a0
[<c02777a6>] copy_from_user+0x46/0x80
[<c03b2662>] sys_socketcall+0x242/0x260
[<c04b5700>] do_page_fault+0x0/0x623
[<c0103215>] syscall_call+0x7/0xb
Code: ff b8 ff ff ff ff eb e2 31 c0 eb 97 8d b6 00 00 00 00 31 c0 e9 3b ff ff ff 89 f6 8d bc 27 00 00 00 00 83 ec 14 8b 44 24 18 8b 10 <0f> b7 02 83 c2 04 89 54 24 08 83 e8 04 89 44 24 0c b8 01 00 00
# uname -r
2.6.14
Best regards,
Krzysztof Olędzki
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Unable to handle kernel NULL pointer dereference at virtual address 00000000 after conntrack -I
2005-11-03 13:14 Unable to handle kernel NULL pointer dereference at virtual address 00000000 after conntrack -I Krzysztof Oledzki
@ 2005-11-03 19:55 ` Pablo Neira
2005-11-03 20:23 ` Krzysztof Oledzki
2005-11-06 0:05 ` Krzysztof Oledzki
0 siblings, 2 replies; 7+ messages in thread
From: Pablo Neira @ 2005-11-03 19:55 UTC (permalink / raw)
To: Krzysztof Oledzki; +Cc: netfilter-devel
Krzysztof Oledzki wrote:
> # conntrack -I --orig-src 1.2.3.4 --orig-dst 1.2.3.5 --reply-src 2.3.4.5
> --reply-dst 2.3.4.5 -p tcp --orig-port-src 1 --orig-port-dst 2
> --reply-port-src 3 --reply-port-dst 4 -t 32323 -u ASSURED
--state option is missing: Unfortunately conntrack forgot to check it
that such parameter was missing and ctnetlink didn't do that check
either. That's why it resulted in an oops :(
I've just applied a patch for conntrack, refresh your working copy. So
you won't be able to reproduce that oops anymore.
Anyway I'll send a patch for ctnetlink, that checking must be done in
kernel space as well.
--
Pablo
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Unable to handle kernel NULL pointer dereference at virtual address 00000000 after conntrack -I
2005-11-03 19:55 ` Pablo Neira
@ 2005-11-03 20:23 ` Krzysztof Oledzki
2005-11-04 18:12 ` Pablo Neira
2005-11-06 0:05 ` Krzysztof Oledzki
1 sibling, 1 reply; 7+ messages in thread
From: Krzysztof Oledzki @ 2005-11-03 20:23 UTC (permalink / raw)
To: Pablo Neira; +Cc: netfilter-devel
[-- Attachment #1: Type: TEXT/PLAIN, Size: 851 bytes --]
On Thu, 3 Nov 2005, Pablo Neira wrote:
> Krzysztof Oledzki wrote:
>> # conntrack -I --orig-src 1.2.3.4 --orig-dst 1.2.3.5 --reply-src 2.3.4.5
>> --reply-dst 2.3.4.5 -p tcp --orig-port-src 1 --orig-port-dst 2
>> --reply-port-src 3 --reply-port-dst 4 -t 32323 -u ASSURED
>
> --state option is missing: Unfortunately conntrack forgot to check it
> that such parameter was missing and ctnetlink didn't do that check
> either. That's why it resulted in an oops :(
>
> I've just applied a patch for conntrack, refresh your working copy. So
> you won't be able to reproduce that oops anymore.
>
> Anyway I'll send a patch for ctnetlink, that checking must be done in
> kernel space as well.
Thank you. When are you going to release the 1.0 version? How much time
I have left for testing? ;)
Best regards,
Krzysztof Olędzki
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Unable to handle kernel NULL pointer dereference at virtual address 00000000 after conntrack -I
2005-11-03 20:23 ` Krzysztof Oledzki
@ 2005-11-04 18:12 ` Pablo Neira
0 siblings, 0 replies; 7+ messages in thread
From: Pablo Neira @ 2005-11-04 18:12 UTC (permalink / raw)
To: Krzysztof Oledzki; +Cc: netfilter-devel
Krzysztof Oledzki wrote:
> On Thu, 3 Nov 2005, Pablo Neira wrote:
>
>> Krzysztof Oledzki wrote:
>>
>>> # conntrack -I --orig-src 1.2.3.4 --orig-dst 1.2.3.5 --reply-src 2.3.4.5
>>> --reply-dst 2.3.4.5 -p tcp --orig-port-src 1 --orig-port-dst 2
>>> --reply-port-src 3 --reply-port-dst 4 -t 32323 -u ASSURED
>>
>>
>> --state option is missing: Unfortunately conntrack forgot to check it
>> that such parameter was missing and ctnetlink didn't do that check
>> either. That's why it resulted in an oops :(
>>
>> I've just applied a patch for conntrack, refresh your working copy. So
>> you won't be able to reproduce that oops anymore.
>>
>> Anyway I'll send a patch for ctnetlink, that checking must be done in
>> kernel space as well.
>
> Thank you. When are you going to release the 1.0 version? How much time
> I have left for testing? ;)
Good question. I wanted to do it before 2.6.14, but it seems that time
run up. So my proposed alternative is doing it as soon as there are no
known bugs in ctnetlink, I don't want people complaining about crashing
kernels because of this stuff *sigh*. And of course, once there are no
complains about conntrack/libnetfilter_conntrack for some days at the
same time.
--
Pablo
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Unable to handle kernel NULL pointer dereference at virtual address 00000000 after conntrack -I
2005-11-03 19:55 ` Pablo Neira
2005-11-03 20:23 ` Krzysztof Oledzki
@ 2005-11-06 0:05 ` Krzysztof Oledzki
2005-11-06 2:30 ` Krzysztof Oledzki
1 sibling, 1 reply; 7+ messages in thread
From: Krzysztof Oledzki @ 2005-11-06 0:05 UTC (permalink / raw)
To: Pablo Neira; +Cc: netfilter-devel
[-- Attachment #1: Type: TEXT/PLAIN, Size: 3051 bytes --]
On Thu, 3 Nov 2005, Pablo Neira wrote:
> Krzysztof Oledzki wrote:
>> # conntrack -I --orig-src 1.2.3.4 --orig-dst 1.2.3.5 --reply-src 2.3.4.5
>> --reply-dst 2.3.4.5 -p tcp --orig-port-src 1 --orig-port-dst 2
>> --reply-port-src 3 --reply-port-dst 4 -t 32323 -u ASSURED
>
> --state option is missing: Unfortunately conntrack forgot to check it
> that such parameter was missing and ctnetlink didn't do that check
> either. That's why it resulted in an oops :(
>
> I've just applied a patch for conntrack, refresh your working copy. So
> you won't be able to reproduce that oops anymore.
>
> Anyway I'll send a patch for ctnetlink, that checking must be done in
> kernel space as well.
Simmilar problem, this time ICMP related:
# conntrack -I -s=192.168.0.88 -d=192.168.31.255 -r=192.168.31.255 -q=192.168.0.88 -p icmp -t 4 -u ASSURED --icmp-type 1 --icmp-code 3
Unable to handle kernel NULL pointer dereference at virtual address 00000004
printing eip:
c042b7a4
*pde = 00000000
Oops: 0000 [#1]
PREEMPT
Modules linked in: bonding
CPU: 0
EIP: 0060:[<c042b7a4>] Not tainted VLI
EFLAGS: 00010282 (2.6.14)
EIP is at icmp_nfattr_to_tuple+0x34/0x40
eax: 00000000 ebx: c41fac34 ecx: c41fac34 edx: c41fabf4
esi: c41fac70 edi: c0594ae0 ebp: dfadd000 esp: c41fab94
ds: 007b es: 007b ss: 0068
Process conntrack (pid: 1922, threadinfo=c41fa000 task=c5b0c030)
Stack: c042e584 c41fabf4 c41fac34 dfadd030 00000018 00000000 00000400 00000000
c01bad7d c473f3ec dfadd018 dfadd02c c01c1dfc c41fac3c 00000000 00000282
00000001 00000046 c011a963 c15e8b3c 00000003 00000001 c41fa000 00000282
Call Trace:
[<c042e584>] ctnetlink_new_conntrack+0x494/0x4e0
[<c01bad7d>] journal_dirty_metadata+0xfd/0x250
[<c01c1dfc>] journal_add_journal_head+0x7c/0x120
[<c011a963>] __wake_up+0x53/0x80
[<c01bb2ee>] journal_stop+0x18e/0x280
[<c014014d>] find_get_page+0x3d/0x60
[<c0454121>] nfnetlink_rcv+0x271/0x2c7
[<c03e2c8b>] netlink_data_ready+0x6b/0x70
[<c03e1da2>] netlink_sendskb+0x32/0x60
[<c03e28db>] netlink_sendmsg+0x20b/0x310
[<c01ac708>] ext3_mark_iloc_dirty+0x28/0x40
[<c01b1094>] __ext3_journal_stop+0x24/0x50
[<c03b073a>] sock_sendmsg+0xda/0x100
[<c01865ca>] __mark_inode_dirty+0xda/0x1b0
[<c017d7a6>] update_atime+0x96/0xb0
[<c02777a6>] copy_from_user+0x46/0x80
[<c01339f0>] autoremove_wake_function+0x0/0x60
[<c03b21bf>] sys_sendmsg+0x18f/0x1f0
[<c014522e>] __alloc_pages+0x2fe/0x480
[<c014a909>] lru_cache_add_active+0x39/0x70
[<c0150910>] do_anonymous_page+0x100/0x160
[<c0150ea0>] __handle_mm_fault+0xf0/0x1a0
[<c02777a6>] copy_from_user+0x46/0x80
[<c03b2662>] sys_socketcall+0x242/0x260
[<c04b56f0>] do_page_fault+0x0/0x623
[<c0103215>] syscall_call+0x7/0xb
Code: 42 10 85 c0 74 06 83 7a 14 00 75 0b b8 ff ff ff ff c3 90 8d 74 26 00 0f b6 40 04 88 41 0c 8b 42 14 0f b6 40 04 88 41 0d 8b 42 0c <66> 0f b6 40 04 66 89 41 04 31 c0 c3 55 31 c0 57 56 53 83 ec 40
Best regards,
Krzysztof Olędzki
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Unable to handle kernel NULL pointer dereference at virtual address 00000000 after conntrack -I
2005-11-06 0:05 ` Krzysztof Oledzki
@ 2005-11-06 2:30 ` Krzysztof Oledzki
2005-11-06 2:57 ` Pablo Neira
0 siblings, 1 reply; 7+ messages in thread
From: Krzysztof Oledzki @ 2005-11-06 2:30 UTC (permalink / raw)
To: Pablo Neira; +Cc: netfilter-devel
[-- Attachment #1: Type: TEXT/PLAIN, Size: 2949 bytes --]
On Sun, 6 Nov 2005, Krzysztof Oledzki wrote:
>
>
> On Thu, 3 Nov 2005, Pablo Neira wrote:
>
>> Krzysztof Oledzki wrote:
>>> # conntrack -I --orig-src 1.2.3.4 --orig-dst 1.2.3.5 --reply-src 2.3.4.5
>>> --reply-dst 2.3.4.5 -p tcp --orig-port-src 1 --orig-port-dst 2
>>> --reply-port-src 3 --reply-port-dst 4 -t 32323 -u ASSURED
>>
>> --state option is missing: Unfortunately conntrack forgot to check it
>> that such parameter was missing and ctnetlink didn't do that check
>> either. That's why it resulted in an oops :(
>>
>> I've just applied a patch for conntrack, refresh your working copy. So
>> you won't be able to reproduce that oops anymore.
>>
>> Anyway I'll send a patch for ctnetlink, that checking must be done in
>> kernel space as well.
>
> Simmilar problem, this time ICMP related:
>
> # conntrack -I -s=192.168.0.88 -d=192.168.31.255 -r=192.168.31.255
> -q=192.168.0.88 -p icmp -t 4 -u ASSURED --icmp-type 1 --icmp-code 3
>
> Unable to handle kernel NULL pointer dereference at virtual address 00000004
> printing eip:
OK. This patch (check-icmpid.patch) should fix it:
[NETFILTER] Check for ICMP_ID in icmp_nfattr_to_tuple
This patch fixes an userspace triggered oops. If there is no ICMP_ID
info the reference to attr will be NULL.
Signed-out-by: Krzysztof Piotr Oledzki <ole@ans.pl>
--- a/net/ipv4/netfilter/ip_conntrack_proto_icmp.c 2005-11-06 02:17:29.000000000 +0100
+++ b/net/ipv4/netfilter/ip_conntrack_proto_icmp.c 2005-11-06 02:18:45.000000000 +0100
@@ -296,7 +296,8 @@
struct ip_conntrack_tuple *tuple)
{
if (!tb[CTA_PROTO_ICMP_TYPE-1]
- || !tb[CTA_PROTO_ICMP_CODE-1])
+ || !tb[CTA_PROTO_ICMP_CODE-1]
+ || !tb[CTA_PROTO_ICMP_ID-1])
return -1;
tuple->dst.u.icmp.type =
Anyway, libnetfilter_conntrack_icmp.c should also be fixed. Currently
ICMP_ID is not addedd if TYPE is not 8 (ICMP ECHO). I beleve we should
simply skip this check (libnetfilter_conntrack_icmp-icmpid.patch):
Index: extensions/libnetfilter_conntrack_icmp.c
===================================================================
--- extensions/libnetfilter_conntrack_icmp.c (revision 4480)
+++ extensions/libnetfilter_conntrack_icmp.c (working copy)
@@ -38,10 +38,12 @@
&t->l4dst.icmp.code, sizeof(u_int8_t));
nfnl_addattr_l(&req->nlh, size, CTA_PROTO_ICMP_TYPE,
&t->l4dst.icmp.type, sizeof(u_int8_t));
- /* This is an ICMP echo */
- if (t->l4dst.icmp.type == 8)
- nfnl_addattr_l(&req->nlh, size, CTA_PROTO_ICMP_ID,
- &t->l4src.icmp.id, sizeof(u_int16_t));
+
+ /* The ID only makes sense for type=8 (ECHO) but we always
+ * want to set it or else kernel will reject such messages.
+ */
+ nfnl_addattr_l(&req->nlh, size, CTA_PROTO_ICMP_ID,
+ &t->l4src.icmp.id, sizeof(u_int16_t));
}
static int print_proto(char *buf, struct nfct_tuple *t)
Best regards,
Krzysztof Olędzki
[-- Attachment #2: Type: TEXT/PLAIN, Size: 659 bytes --]
[NETFILTER] Check for ICMP_ID in icmp_nfattr_to_tuple
This patch fixes an userspace triggered oops. If there is no ICMP_ID
info the reference to attr will be NULL.
Signed-out-by: Krzysztof Piotr Oledzki <ole@ans.pl>
--- a/net/ipv4/netfilter/ip_conntrack_proto_icmp.c 2005-11-06 02:17:29.000000000 +0100
+++ b/net/ipv4/netfilter/ip_conntrack_proto_icmp.c 2005-11-06 02:18:45.000000000 +0100
@@ -296,7 +296,8 @@
struct ip_conntrack_tuple *tuple)
{
if (!tb[CTA_PROTO_ICMP_TYPE-1]
- || !tb[CTA_PROTO_ICMP_CODE-1])
+ || !tb[CTA_PROTO_ICMP_CODE-1]
+ || !tb[CTA_PROTO_ICMP_ID-1])
return -1;
tuple->dst.u.icmp.type =
[-- Attachment #3: Type: TEXT/PLAIN, Size: 892 bytes --]
Index: extensions/libnetfilter_conntrack_icmp.c
===================================================================
--- extensions/libnetfilter_conntrack_icmp.c (revision 4480)
+++ extensions/libnetfilter_conntrack_icmp.c (working copy)
@@ -38,10 +38,12 @@
&t->l4dst.icmp.code, sizeof(u_int8_t));
nfnl_addattr_l(&req->nlh, size, CTA_PROTO_ICMP_TYPE,
&t->l4dst.icmp.type, sizeof(u_int8_t));
- /* This is an ICMP echo */
- if (t->l4dst.icmp.type == 8)
- nfnl_addattr_l(&req->nlh, size, CTA_PROTO_ICMP_ID,
- &t->l4src.icmp.id, sizeof(u_int16_t));
+
+ /* The ID only makes sense for type=8 (ECHO) but we always
+ * want to set it or else kernel will reject such messages.
+ */
+ nfnl_addattr_l(&req->nlh, size, CTA_PROTO_ICMP_ID,
+ &t->l4src.icmp.id, sizeof(u_int16_t));
}
static int print_proto(char *buf, struct nfct_tuple *t)
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Unable to handle kernel NULL pointer dereference at virtual address 00000000 after conntrack -I
2005-11-06 2:30 ` Krzysztof Oledzki
@ 2005-11-06 2:57 ` Pablo Neira
0 siblings, 0 replies; 7+ messages in thread
From: Pablo Neira @ 2005-11-06 2:57 UTC (permalink / raw)
To: Krzysztof Oledzki; +Cc: netfilter-devel
Krzysztof Oledzki wrote:
> [NETFILTER] Check for ICMP_ID in icmp_nfattr_to_tuple
>
> This patch fixes an userspace triggered oops. If there is no ICMP_ID
> info the reference to attr will be NULL.
>
> Signed-out-by: Krzysztof Piotr Oledzki <ole@ans.pl>
>
> --- a/net/ipv4/netfilter/ip_conntrack_proto_icmp.c 2005-11-06
> 02:17:29.000000000 +0100
> +++ b/net/ipv4/netfilter/ip_conntrack_proto_icmp.c 2005-11-06
> 02:18:45.000000000 +0100
> @@ -296,7 +296,8 @@
> struct ip_conntrack_tuple *tuple)
> {
> if (!tb[CTA_PROTO_ICMP_TYPE-1]
> - || !tb[CTA_PROTO_ICMP_CODE-1])
> + || !tb[CTA_PROTO_ICMP_CODE-1]
> + || !tb[CTA_PROTO_ICMP_ID-1])
> return -1;
>
> tuple->dst.u.icmp.type =
>
> Anyway, libnetfilter_conntrack_icmp.c should also be fixed. Currently
> ICMP_ID is not addedd if TYPE is not 8 (ICMP ECHO). I beleve we should
> simply skip this check (libnetfilter_conntrack_icmp-icmpid.patch):
The patch looks fine. I'll pass this patch to Harald, I don't want to
get it lost.
> Index: extensions/libnetfilter_conntrack_icmp.c
> ===================================================================
> --- extensions/libnetfilter_conntrack_icmp.c (revision 4480)
> +++ extensions/libnetfilter_conntrack_icmp.c (working copy)
> @@ -38,10 +38,12 @@
> &t->l4dst.icmp.code, sizeof(u_int8_t));
> nfnl_addattr_l(&req->nlh, size, CTA_PROTO_ICMP_TYPE,
> &t->l4dst.icmp.type, sizeof(u_int8_t));
> - /* This is an ICMP echo */
> - if (t->l4dst.icmp.type == 8)
> - nfnl_addattr_l(&req->nlh, size, CTA_PROTO_ICMP_ID,
> - &t->l4src.icmp.id, sizeof(u_int16_t));
> +
> + /* The ID only makes sense for type=8 (ECHO) but we always
> + * want to set it or else kernel will reject such messages.
> + */
I removed this comment, I inserted by myself and it's bogus. The ID
makes sense for *some* ICMP messages, not just for type=8.
> + nfnl_addattr_l(&req->nlh, size, CTA_PROTO_ICMP_ID,
> + &t->l4src.icmp.id, sizeof(u_int16_t));
> }
>
I'm going to apply it now. Thanks.
--
Pablo
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2005-11-06 2:57 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2005-11-03 13:14 Unable to handle kernel NULL pointer dereference at virtual address 00000000 after conntrack -I Krzysztof Oledzki
2005-11-03 19:55 ` Pablo Neira
2005-11-03 20:23 ` Krzysztof Oledzki
2005-11-04 18:12 ` Pablo Neira
2005-11-06 0:05 ` Krzysztof Oledzki
2005-11-06 2:30 ` Krzysztof Oledzki
2005-11-06 2:57 ` Pablo Neira
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.