All of lore.kernel.org
 help / color / mirror / Atom feed
* [TEST_PATCH]Re: Fw: Oops in register_proc_table (2.6.1-mm4)
       [not found] <OFB49626C9.096C6A6C-ON87256E20.006D3112@us.ibm.com>
@ 2004-01-19 19:49 ` Krishna Kumar
  2004-01-19 23:51   ` Thomas Schlichter
  0 siblings, 1 reply; 8+ messages in thread
From: Krishna Kumar @ 2004-01-19 19:49 UTC (permalink / raw)
  To: akpm; +Cc: netdev, thomas.schlichter, KK

Hi,

Can you test with following patch ?

thanks,

- KK

diff -ruN linux-2.6.0-rc2-bk6/net/ipv6/route.c linux-2.6.0-rc2-bk6.new/net/ipv6/route.c
--- linux-2.6.0-rc2-bk6/net/ipv6/route.c	2004-01-19 11:41:14.000000000 -0800
+++ linux-2.6.0-rc2-bk6.new/net/ipv6/route.c	2004-01-19 11:42:33.000000000 -0800
@@ -1974,6 +1974,7 @@
          	.proc_handler	=	&proc_dointvec_jiffies,
 		.strategy	=	&sysctl_jiffies,
 	},
+	{ .ctl_name = 0 }
 };

 #endif

> OK, I can reproduce this oops now.
>
> 0xc0126f7d in register_proc_table (table=0xc04cc80c, root=0xcff92600) at
> string.h:182
> 182     __asm__ __volatile__(
> (gdb) bt
> #0  0xc0126f7d in register_proc_table (table=0xc04cc80c, root=0xcff92600)
> at string.h:182
> #1  0xc0126fcb in register_proc_table (table=0xc04cd540, root=0xcff92680)
> at sysctl.c:1187
> #2  0xc0126fcb in register_proc_table (table=0xc04cf624, root=0xcff95680)
> at sysctl.c:1187
> #3  0xc0126fcb in register_proc_table (table=0xc0451958, root=0xcffa0380)
> at sysctl.c:1187
> #4  0xc051f727 in sysctl_init () at sysctl.c:854
> #5  0xc0105169 in init (unused=0x0) at init/main.c:557
> (gdb) f 3
> #3  0xc0126fcb in register_proc_table (table=0xc0451958, root=0xcffa0380)
> at sysctl.c:1187
> 1187                            register_proc_table(table->child, de);
> (gdb) p *table
> $1 = {ctl_name = 3, procname = 0xc043394e "net", data = 0x0, maxlen = 0,
> mode = 365, child = 0xc04cf5a0,
>   proc_handler = 0, strategy = 0, de = 0xcff95680, extra1 = 0x0, extra2 =
> 0x0}
> (gdb) f 2
> #2  0xc0126fcb in register_proc_table (table=0xc04cf624, root=0xcff95680)
> at sysctl.c:1187
> 1187                            register_proc_table(table->child, de);
> (gdb) p *table
> $2 = {ctl_name = 12, procname = 0xc0431b88 "ipv6", data = 0x0, maxlen = 0,
> mode = 365,
>   child = 0xc04cd540, proc_handler = 0, strategy = 0, de = 0xcff92680,
> extra1 = 0x0, extra2 = 0x0}
> (gdb) f 1
> #1  0xc0126fcb in register_proc_table (table=0xc04cd540, root=0xcff92680)
> at sysctl.c:1187
> 1187                            register_proc_table(table->child, de);
> (gdb) p *table
> $3 = {ctl_name = 18, procname = 0xc0431402 "route", data = 0x0, maxlen = 0,
> mode = 365,
>   child = 0xc04cc680, proc_handler = 0, strategy = 0, de = 0xcff92600,
> extra1 = 0x0, extra2 = 0x0}
> (gdb) f 0
> #0  0xc0126f7d in register_proc_table (table=0xc04cc80c, root=0xcff92600)
> at string.h:182
> 182     __asm__ __volatile__(
> (gdb) p *table
> $4 = {ctl_name = 1220, procname = 0x927c0 <Address 0x927c0 out of bounds>,
> data = 0x9, maxlen = 60000,
>   mode = 500, child = 0x1000, proc_handler = 0, strategy = 0, de = 0x0,
> extra1 = 0x0, extra2 = 0x0}
>
> It seems that ipv6 is registering something under /proc/net/ipv6/route
> which has a bad ctl_table.procname.  I don't know what it is - the ipv6
> sysctl code overpowered my attention span.
>
> The .config is attached - 2.6.1-mm4 should demonstrate the problem.
>
> Can one of the ip6 guys please look at this?

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [TEST_PATCH]Re: Fw: Oops in register_proc_table (2.6.1-mm4)
  2004-01-19 19:49 ` [TEST_PATCH]Re: Fw: Oops in register_proc_table (2.6.1-mm4) Krishna Kumar
@ 2004-01-19 23:51   ` Thomas Schlichter
  2004-01-20  0:06     ` [PATCH] " Krishna Kumar
  0 siblings, 1 reply; 8+ messages in thread
From: Thomas Schlichter @ 2004-01-19 23:51 UTC (permalink / raw)
  To: Krishna Kumar, akpm; +Cc: netdev, KK

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 611 bytes --]

Hi,

Am Montag, 19. Januar 2004 20:49 schrieb Krishna Kumar:
> Hi,
>
> Can you test with following patch ?

Yes, and it cures the Oops here!

> thanks,

Thank you, too!

> - KK

  Thomas Schlichter

> diff -ruN linux-2.6.0-rc2-bk6/net/ipv6/route.c
> linux-2.6.0-rc2-bk6.new/net/ipv6/route.c ---
> linux-2.6.0-rc2-bk6/net/ipv6/route.c	2004-01-19 11:41:14.000000000 -0800
> +++ linux-2.6.0-rc2-bk6.new/net/ipv6/route.c	2004-01-19 11:42:33.000000000
> -0800 @@ -1974,6 +1974,7 @@
>           	.proc_handler	=	&proc_dointvec_jiffies,
>  		.strategy	=	&sysctl_jiffies,
>  	},
> +	{ .ctl_name = 0 }
>  };
>
>  #endif

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

^ permalink raw reply	[flat|nested] 8+ messages in thread

* [PATCH] Oops in register_proc_table (2.6.1-mm4)
  2004-01-19 23:51   ` Thomas Schlichter
@ 2004-01-20  0:06     ` Krishna Kumar
  2004-01-20  5:11       ` David S. Miller
  0 siblings, 1 reply; 8+ messages in thread
From: Krishna Kumar @ 2004-01-20  0:06 UTC (permalink / raw)
  To: davem, Thomas Schlichter; +Cc: akpm, netdev

Hi Dave,

Please apply the patch below.

Thanks,

- KK

diff -ruN linux-2.6.0-rc2-bk6/net/ipv6/route.c linux-2.6.0-rc2-bk6.new/net/ipv6/route.c
--- linux-2.6.0-rc2-bk6/net/ipv6/route.c	2004-01-19 11:41:14.000000000 -0800
+++ linux-2.6.0-rc2-bk6.new/net/ipv6/route.c	2004-01-19 11:42:33.000000000 -0800
@@ -1974,6 +1974,7 @@
          	.proc_handler	=	&proc_dointvec_jiffies,
 		.strategy	=	&sysctl_jiffies,
 	},
+	{ .ctl_name = 0 }
 };

 #endif

On Tue, 20 Jan 2004, Thomas Schlichter wrote:

> Hi,
>
> Am Montag, 19. Januar 2004 20:49 schrieb Krishna Kumar:
> > Hi,
> >
> > Can you test with following patch ?
>
> Yes, and it cures the Oops here!
>
> > thanks,
>
> Thank you, too!
>
> > - KK
>
>   Thomas Schlichter

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH] Oops in register_proc_table (2.6.1-mm4)
  2004-01-20  0:06     ` [PATCH] " Krishna Kumar
@ 2004-01-20  5:11       ` David S. Miller
  2004-01-20 19:46         ` [PATCH] Uninitialized dst in ip6_dst_lookup Krishna Kumar
  2004-02-05  1:41         ` [PATCH] bug in xfrm_lookup [bugzilla 2017] Krishna Kumar
  0 siblings, 2 replies; 8+ messages in thread
From: David S. Miller @ 2004-01-20  5:11 UTC (permalink / raw)
  To: Krishna Kumar; +Cc: thomas.schlichter, akpm, netdev

On Mon, 19 Jan 2004 16:06:22 -0800 (PST)
Krishna Kumar <krkumar@us.ibm.com> wrote:

> Please apply the patch below.

Applied, thanks Krishna.

^ permalink raw reply	[flat|nested] 8+ messages in thread

* [PATCH] Uninitialized dst in ip6_dst_lookup
  2004-01-20  5:11       ` David S. Miller
@ 2004-01-20 19:46         ` Krishna Kumar
  2004-01-22  6:14           ` David S. Miller
  2004-02-05  1:41         ` [PATCH] bug in xfrm_lookup [bugzilla 2017] Krishna Kumar
  1 sibling, 1 reply; 8+ messages in thread
From: Krishna Kumar @ 2004-01-20 19:46 UTC (permalink / raw)
  To: David S. Miller; +Cc: netdev, KK

Hi Dave,

ip6_dst_lookup() is supposed to fill in the *dst, hence it must not
dereference *dst until it allocates it. However if the passed sk is
NULL and *dst is not set by the caller, the following code will
dereference uninitialized memory :

	if (*dst == NULL)
		*dst = ip6_route_output(sk, fl); >>>>> will not execute
	if ((err = (*dst)->error))  >>>>> dereference bad stack address.
		goto out_err_release;

I am suggesting moving the responsibility of ensuring a good *dst from the
callers to ip6_dst_lookup().

Currently the existing code doesn't cause any problem since this routine
is called either with sk!=NULL or if sk is NULL, the *dst passed is NULL
(tcp_v6_send_reset() and tcp_v6_send_ack() do alloc_skb() which sets all
fields till truesize to NULL). However if some code is added/changed such
that sk is NULL and an uninitialized *dst is passed, we will reference
uninitialized *dst.

Suggesting following patch to handle this case.

thanks,

- KK

diff -ruN linux-2.6.1.bk2/net/ipv6/ip6_output.c linux-2.6.1.bk2.new/net/ipv6/ip6_output.c
--- linux-2.6.1.bk2/net/ipv6/ip6_output.c	2004-01-20 11:12:06.000000000 -0800
+++ linux-2.6.1.bk2.new/net/ipv6/ip6_output.c	2004-01-20 11:13:28.000000000 -0800
@@ -725,6 +725,7 @@
 {
 	int err = 0;

+	*dst = NULL;
 	if (sk) {
 		struct ipv6_pinfo *np = inet6_sk(sk);

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH] Uninitialized dst in ip6_dst_lookup
  2004-01-20 19:46         ` [PATCH] Uninitialized dst in ip6_dst_lookup Krishna Kumar
@ 2004-01-22  6:14           ` David S. Miller
  0 siblings, 0 replies; 8+ messages in thread
From: David S. Miller @ 2004-01-22  6:14 UTC (permalink / raw)
  To: Krishna Kumar; +Cc: netdev, krkumar

On Tue, 20 Jan 2004 11:46:02 -0800 (PST)
Krishna Kumar <krkumar@us.ibm.com> wrote:

> ip6_dst_lookup() is supposed to fill in the *dst, hence it must not
> dereference *dst until it allocates it. However if the passed sk is
> NULL and *dst is not set by the caller, the following code will
> dereference uninitialized memory :
> 
> 	if (*dst == NULL)
> 		*dst = ip6_route_output(sk, fl); >>>>> will not execute
> 	if ((err = (*dst)->error))  >>>>> dereference bad stack address.
> 		goto out_err_release;
> 
> I am suggesting moving the responsibility of ensuring a good *dst from the
> callers to ip6_dst_lookup().

I agree, patch applied.

Thanks.

^ permalink raw reply	[flat|nested] 8+ messages in thread

* [PATCH] bug in xfrm_lookup [bugzilla 2017]
  2004-01-20  5:11       ` David S. Miller
  2004-01-20 19:46         ` [PATCH] Uninitialized dst in ip6_dst_lookup Krishna Kumar
@ 2004-02-05  1:41         ` Krishna Kumar
  2004-02-05  7:12           ` David S. Miller
  1 sibling, 1 reply; 8+ messages in thread
From: Krishna Kumar @ 2004-02-05  1:41 UTC (permalink / raw)
  To: David S. Miller; +Cc: netdev

Hi Dave,

One of my earlier patches had a bug in xfrm_lookup() causin schedule()
to get called though MSG_DONTWAIT was specified. I am going to send
the following patch to the bugzilla user who created this bug report
and ask them to test it. I thought I will let you know of this problem
and I will send you a confirmation once I get a response that the problem
is solved.

Thanks,

- KK

diff -ruN linux-2.6.2/net/xfrm/xfrm_policy.c linux-2.6.2.new/net/xfrm/xfrm_policy.c
--- linux-2.6.2/net/xfrm/xfrm_policy.c	2004-02-04 17:33:51.000000000 -0800
+++ linux-2.6.2.new/net/xfrm/xfrm_policy.c	2004-02-04 17:34:37.000000000 -0800
@@ -775,7 +775,7 @@

 		if (unlikely(nx<0)) {
 			err = nx;
-			if (err == -EAGAIN && !flags) {
+			if (err == -EAGAIN && flags) {
 				DECLARE_WAITQUEUE(wait, current);

 				add_wait_queue(&km_waitq, &wait);

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH] bug in xfrm_lookup [bugzilla 2017]
  2004-02-05  1:41         ` [PATCH] bug in xfrm_lookup [bugzilla 2017] Krishna Kumar
@ 2004-02-05  7:12           ` David S. Miller
  0 siblings, 0 replies; 8+ messages in thread
From: David S. Miller @ 2004-02-05  7:12 UTC (permalink / raw)
  To: Krishna Kumar; +Cc: netdev

On Wed, 4 Feb 2004 17:41:48 -0800 (PST)
Krishna Kumar <krkumar@us.ibm.com> wrote:

> One of my earlier patches had a bug in xfrm_lookup() causin schedule()
> to get called though MSG_DONTWAIT was specified. I am going to send
> the following patch to the bugzilla user who created this bug report
> and ask them to test it. I thought I will let you know of this problem
> and I will send you a confirmation once I get a response that the problem
> is solved.

You patch looks correct so I'll apply it for now, if something is
wrong with it send me a fix relative to this patch.

Thanks.

^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2004-02-05  7:12 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <OFB49626C9.096C6A6C-ON87256E20.006D3112@us.ibm.com>
2004-01-19 19:49 ` [TEST_PATCH]Re: Fw: Oops in register_proc_table (2.6.1-mm4) Krishna Kumar
2004-01-19 23:51   ` Thomas Schlichter
2004-01-20  0:06     ` [PATCH] " Krishna Kumar
2004-01-20  5:11       ` David S. Miller
2004-01-20 19:46         ` [PATCH] Uninitialized dst in ip6_dst_lookup Krishna Kumar
2004-01-22  6:14           ` David S. Miller
2004-02-05  1:41         ` [PATCH] bug in xfrm_lookup [bugzilla 2017] Krishna Kumar
2004-02-05  7:12           ` David S. Miller

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.