lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  PHC 
Open Source and information security mailing list archives
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Wed, 3 Oct 2012 23:57:08 +0300 (EEST)
From:	Julian Anastasov <>
To:	David Miller <>
Subject: Re: Possible networking regression in 3.6.0


On Tue, 2 Oct 2012, David Miller wrote:

> From: Julian Anastasov <>
> Date: Wed, 3 Oct 2012 02:24:53 +0300 (EEST)
> > 	Can it be a problem related to fib_info reuse
> > from different routes. For example, when local IP address
> > is created for subnet we have:
> > 
> > broadcast dev DEV  proto kernel  scope link  src
> > dev DEV  proto kernel  scope link  src
> > local dev DEV  proto kernel  scope host  src
> > 
> > 	The "dev DEV  proto kernel  scope link  src" is
> > a reused fib_info structure where we put cached routes.
> > The result can be same fib_info for and
> > RTN_BROADCAST is cached only for input
> > routes. Incoming broadcast to can be cached
> > and can cause problems for traffic forwarded to
> > So, this patch should solve the problem because it
> > separates the broadcast from unicast traffic.
> Now I understand the problem.
> I think the way to fix this is to add cfg->fc_type as another
> thing that fib_info objects are key'd by.
> I think it also would fix your obscure output multicast case too.

	Agreed. I don't see problem with this idea.
It will avoid confusions with rt_type.


Julian Anastasov <>
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to
More majordomo info at

Powered by blists - more mailing lists