Fwd: Possible bug in net/ipv4/route.c?
in [Kernel]
|
Prev: fujitsu-laptop: remove unnecessary input_free_device calls
Next: [PATCH] tracing: Allow to disable cmdline recording
From: Eric Dumazet on 5 Jul 2010 09:40 Le lundi 05 juillet 2010 à 21:22 +0800, Herbert Xu a écrit : > On Mon, Jul 05, 2010 at 02:59:14PM +0200, Eric Dumazet wrote: > > > > Why do we clear full 48 bytes skb->cb[] in skb_alloc(), if no protocol > > stack should rely it being zero ? > > Unless a protocol is allocating the skb itself, then the fact > that skb_alloc clears skb->cb is no guarantee that the skb->cb > will be zero. I see. We could : Avoid this memset(skb->cb, 0, sizeof(skb->cb)) in fastpath. or in debug mode, poison it to trigger errors more often. Thanks -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Herbert Xu on 5 Jul 2010 10:50 On Mon, Jul 05, 2010 at 03:34:58PM +0200, Eric Dumazet wrote: > > I see. We could : > > Avoid this memset(skb->cb, 0, sizeof(skb->cb)) in fastpath. Yeah I think this might work. Although skb's are used in all sorts of esoteric places (such as netlink which may not even be related to networking) so I can't guarantee that every alloc_skb caller does the right thing. Thanks, -- Email: Herbert Xu <herbert(a)gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Henrique de Moraes Holschuh on 5 Jul 2010 16:10 On Mon, 05 Jul 2010, Eric Dumazet wrote: > Le lundi 05 juillet 2010 � 21:22 +0800, Herbert Xu a �crit : > > On Mon, Jul 05, 2010 at 02:59:14PM +0200, Eric Dumazet wrote: > > > > > > Why do we clear full 48 bytes skb->cb[] in skb_alloc(), if no protocol > > > stack should rely it being zero ? > > > > Unless a protocol is allocating the skb itself, then the fact > > that skb_alloc clears skb->cb is no guarantee that the skb->cb > > will be zero. > > I see. We could : > > Avoid this memset(skb->cb, 0, sizeof(skb->cb)) in fastpath. Any chances of skb->cb being leaked to userspace or the network, due to driver bugs or other such oddities? -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Eric Dumazet on 5 Jul 2010 16:20
Le lundi 05 juillet 2010 à 17:07 -0300, Henrique de Moraes Holschuh a écrit : > On Mon, 05 Jul 2010, Eric Dumazet wrote: > > Le lundi 05 juillet 2010 à 21:22 +0800, Herbert Xu a écrit : > > > On Mon, Jul 05, 2010 at 02:59:14PM +0200, Eric Dumazet wrote: > > > > > > > > Why do we clear full 48 bytes skb->cb[] in skb_alloc(), if no protocol > > > > stack should rely it being zero ? > > > > > > Unless a protocol is allocating the skb itself, then the fact > > > that skb_alloc clears skb->cb is no guarantee that the skb->cb > > > will be zero. > > > > I see. We could : > > > > Avoid this memset(skb->cb, 0, sizeof(skb->cb)) in fastpath. > > Any chances of skb->cb being leaked to userspace or the network, due to > driver bugs or other such oddities? > Not "a priori", but a bug is always possible ;) cb[] is internal use only, should not be sent to network or user land. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |