Unable to handle kernel NULL pointer dereference at virtual address 00000000 after conntrack -I

Unable to handle kernel NULL pointer dereference at virtual address 00000000 after conntrack -I

[Krzysztof Oledzki]

[-- 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

Re: Unable to handle kernel NULL pointer dereference at virtual address 00000000 after conntrack -I

[Pablo Neira]

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

Re: Unable to handle kernel NULL pointer dereference at virtual address 00000000 after conntrack -I

[Krzysztof Oledzki]

[-- 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

Re: Unable to handle kernel NULL pointer dereference at virtual address 00000000 after conntrack -I

[Pablo Neira]

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

Re: Unable to handle kernel NULL pointer dereference at virtual address 00000000 after conntrack -I

[Krzysztof Oledzki]

[-- 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

Re: Unable to handle kernel NULL pointer dereference at virtual address 00000000 after conntrack -I

[Krzysztof Oledzki]

[-- 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)

Re: Unable to handle kernel NULL pointer dereference at virtual address 00000000 after conntrack -I

[Pablo Neira]

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