netdev - Re: [PATCH] ipv4: Cache source address in nexthop entries.

lists.openwall.net		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 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-Id: <20110315.160219.189709250.davem@davemloft.net>
Date:	Tue, 15 Mar 2011 16:02:19 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	ja@....bg
Cc:	netdev@...r.kernel.org
Subject: Re: [PATCH] ipv4: Cache source address in nexthop entries.

From: Julian Anastasov <ja@....bg>
Date: Tue, 15 Mar 2011 12:00:33 +0200 (EET)

> 	I see another problem with nh_saddr. fib_info
> is reused when NHs and some parameters are equal but the
> scope is not part of the fib_info and it is wrong to cache
> route scope in NH or even in fib_info. The problem is
> that we can expose in nh_saddr addresses with wrong
> scope for the route. It happens when two routes with
> different route scope reuse same fib_info.
> 
> 	First thought is that the field fa_scope can be
> moved into fib_scope in struct fib_info, not to use
> nh_cfg_scope. Then fib_find_info can differentiate the
> entries by fib_scope. It means, fib_info will not be reused
> if fib_scope is different. For FIB_RES_PREFSRC I assume we
> can access fib_info from nh->nh_parent safely when
> refreshing nh_saddr.
> 
> 	Here is a script that demonstrates the wrong
> exposing:

Thanks for all of your feedback Julian, I will look into
this very soon.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html