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] [thread-next>] [day] [month] [year] [list]
Date:	Sun, 01 Apr 2012 17:30:32 -0400 (EDT)
From:	David Miller <davem@...emloft.net>
To:	shmulik.ladkani@...il.com
Cc:	netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
	eric.dumazet@...il.com, kuznet@....inr.ac.ru, jmorris@...ei.org,
	yoshfuji@...ux-ipv6.org, kaber@...sh.net
Subject: Re: [PATCHv1] ipv6: Fix RTM_GETROUTE's interpretation of RTA_IIF
 to be consistent with ipv4

From: Shmulik Ladkani <shmulik.ladkani@...il.com>
Date: Sun, 1 Apr 2012 17:03:45 +0300

> In IPv4, if an RTA_IIF attribute is specified within an RTM_GETROUTE
> message, then a route is searched as if a packet was received on the
> specified 'iif' interface.
> 
> However in IPv6, RTA_IIF is not interpreted in the same way:
> 'inet6_rtm_getroute()' always calls 'ip6_route_output()', regardless the
> RTA_IIF attribute.
> 
> As a result, in IPv6 there's no way to use RTM_GETROUTE in order to look
> for a route as if a packet was received on a specific interface.
> 
> Fix 'inet6_rtm_getroute()' so that RTA_IIF is interpreted as "lookup a
> route as if a packet was received on the specified interface", similar
> to IPv4's 'inet_rtm_getroute()' interpretation.
> 
> Reported-by: Ami Koren <amikoren@...oo.com>
> Signed-off-by: Shmulik Ladkani <shmulik.ladkani@...il.com>

Applied, thanks.

> 1) An alternative: construction of an skb within 'inet6_rtm_getroute()'
>    and then calling 'ip6_route_input()' with the skb as an argument.
>    Thus, no need to split common code of 'ip6_route_input()'.
>    Less elegant IMO.

Agreed.

> 2) Better name for the new common function 'ip6_route_input_lookup()'
>    Will happily accept any better suggestions.

No, it's fine.

> 3) In IPv4 the 'ip_route_input()' call within 'inet_rtm_getroute()'is
>    protected by a 'local_bh_disable()' since dawn of history.
>    Not sure if similar protection needed within 'inet6_rtm_getroute()'.

Since all the code paths are shared more than on the ipv4 side, both
output and input route lookups can be done with and without BH
disabling.
--
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ