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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Wed, 3 Oct 2012 02:24:53 +0300 (EEST)
From:	Julian Anastasov <>
To:	Eric Dumazet <>
cc:	David Miller <>,,,, Dave Jones <>
Subject: Re: Possible networking regression in 3.6.0


On Tue, 2 Oct 2012, Eric Dumazet wrote:

> > David, shouldnt we use a nh_rth_forward instead of a nh_rth_input in
> > __mkroute_input() ?
> > 
> > (And change rt_cache_route() as well ?)
> > 
> > I am testing a patch right now.
> Yeah, this patch seems to fix the bug for me.
> [PATCH] ipv4: properly cache forward routes
> commit d2d68ba9fe8 (ipv4: Cache input routes in fib_info nexthops.)
> introduced a regression for forwarding.
> This was hard to reproduce but the symptom was that packets were
> delivered to local host instead of being forwarded.
> Add a separate cache (nh_rth_forward) to solve the problem.

	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.

	And the ip_route_input_slow caching will work for
local and broadcast input routes (above routes 1 and 3) just
because they differ in scope and use different fib_info.

	Another possible failure is for output routes:

multicast fib_info
with unicast fib_info

	The multicast sets RTCF_MULTICAST | RTCF_LOCAL
and can cause problems for generated unicast traffic on
fib_info reuse. Depends on the scope, for multicast it is
usually scope global, so may be it is difficult to happen
in practice.

	__mkroute_output works for local/unicast routes
because they differ in scope.

> Many thanks to Chris Clayton for his patience and help.
> Reported-by: Chris Clayton <>
> Bisected-by: Chris Clayton <>
> Reported-by: Dave Jones <>
> Signed-off-by: Eric Dumazet <>
> ---
>  include/net/ip_fib.h     |    1 +
>  net/ipv4/fib_semantics.c |    1 +
>  net/ipv4/route.c         |   16 ++++++++--------
>  3 files changed, 10 insertions(+), 8 deletions(-)


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