use after free bug in socket code

Hi,

Oliver Hartkopp writes:

> unfortunately i did not get any answer from Urs so far, who originally created
> these lines of code.
> 
> But from what i was able to get from browsing similar code in the Kernel that
> at least sock_orphan() is called in the appropriate socket release functions,
> which is indeed not done by the mentioned PF_CAN protocols right now.
> 
> I assume you already tested this patch (at least with CAN_RAW) successfully,
> right?
> 
Yes.

> If so, i would have no objections to add my Acked-by to these changes.
> 
> Would you like to prepare a proper patch and post it on netdev?
> 
I'll do.
I would also submit a second patch to add an appropriate MODULE_ALIAS
to the protocol drivers, so they can be autoloaded when compiled as
module:

> ps. This code section was stable for more than three years now. Can you tell
> me, how you kicked your system to run into this problem?
> 
I was working on a chip driver for the i.MX25 flexcan controller. The
bug was visible due to CONFIG_DEBUG_SLAB=y which makes sure that
memory is poisoned with a special pattern upon being freed.

The situation where this triggers a bug is when the chip driver's
hard_start_xmit function returns a NETDEV_TX_BUSY and subsequently the
can interface is deconfigured.

Maybe you could try this on different hardware?


Lothar Waßmann

Lothar Waßmann wrote:
> Oliver Hartkopp writes:
>>
>> Would you like to prepare a proper patch and post it on netdev?
>>
> I'll do.

Fine.

> I would also submit a second patch to add an appropriate MODULE_ALIAS
> to the protocol drivers, so they can be autoloaded when compiled as
> module:
> diff -ur linux-2.6.30/net/can/bcm.c linux-2.6.30-karo/net/can/bcm.c
> --- linux-2.6.30/net/can/bcm.c	2009-06-10 05:05:27.000000000 +0200
> +++ linux-2.6.30-karo/net/can/bcm.c	2009-07-12 20:12:38.000000000 +0200
> @@ -75,6 +75,7 @@
>  MODULE_DESCRIPTION("PF_CAN broadcast manager protocol");
>  MODULE_LICENSE("Dual BSD/GPL");
>  MODULE_AUTHOR("Oliver Hartkopp <oliver.hartkopp@volkswagen.de>");
> +MODULE_ALIAS("can-proto-2");
>  
>  /* easy access to can_frame payload */
>  static inline u64 GET_U64(const struct can_frame *cp)
> diff -ur linux-2.6.30/net/can/raw.c linux-2.6.30-karo/net/can/raw.c
> --- linux-2.6.30/net/can/raw.c	2009-06-10 05:05:27.000000000 +0200
> +++ linux-2.6.30-karo/net/can/raw.c	2009-07-12 20:12:29.000000000 +0200
> @@ -62,6 +62,7 @@
>  MODULE_DESCRIPTION("PF_CAN raw protocol");
>  MODULE_LICENSE("Dual BSD/GPL");
>  MODULE_AUTHOR("Urs Thuermann <urs.thuermann@volkswagen.de>");
> +MODULE_ALIAS("can-proto-1");
>  
>  #define MASK_ALL 0
>  

Good idea.

I currently added these aliases somewhere in my /etc/modprobe.d directory. But
if this can be done by the kernel itself, we can reduce the distro-depended
configuation effort.

You can add my

Acked-by: Oliver Hartkopp <oliver@hartkopp.net>

to both discussed patches directly.

> 
>> ps. This code section was stable for more than three years now. Can you tell
>> me, how you kicked your system to run into this problem?
>>
> I was working on a chip driver for the i.MX25 flexcan controller. The
> bug was visible due to CONFIG_DEBUG_SLAB=y which makes sure that
> memory is poisoned with a special pattern upon being freed.

Nice hint! I will enable this in my config also.

> 
> The situation where this triggers a bug is when the chip driver's
> hard_start_xmit function returns a NETDEV_TX_BUSY and subsequently the
> can interface is deconfigured.
> 
> Maybe you could try this on different hardware?

Will do when i'm back at work ;-)

Many Thanks,
Oliver
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Hi,

Oliver Hartkopp writes:
> > The situation where this triggers a bug is when the chip driver's
> > hard_start_xmit function returns a NETDEV_TX_BUSY and subsequently the
> > can interface is deconfigured.
> > 
> > Maybe you could try this on different hardware?
> 
> Will do when i'm back at work ;-)
> 
Should I wait for the results of your tests before submitting the
patches?


Lothar Waßmann

Lothar Waßmann wrote:
> Hi,
> 
> Oliver Hartkopp writes:
>>> The situation where this triggers a bug is when the chip driver's
>>> hard_start_xmit function returns a NETDEV_TX_BUSY and subsequently the
>>> can interface is deconfigured.
>>>
>>> Maybe you could try this on different hardware?
>> Will do when i'm back at work ;-)
>>
> Should I wait for the results of your tests before submitting the
> patches?

A user has reported sporadic kernel panics with a down/up/restart stress
test a while ago on the Socket-CAN mailing list and the patch seems to
solve his problem:

https://lists.berlios.de/pipermail/socketcan-users/2009-July/000985.html

From my point of view you can go ahead.

Thanks.

Wolfgang.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html