netdev - Re: [PATCH net-next 1/6] ipv4: route: Ignore output interface in FIB lookup for PMTU route

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20200804075247.3db502f3@elisabeth>
Date:   Tue, 4 Aug 2020 07:52:47 +0200
From:   Stefano Brivio <sbrivio@...hat.com>
To:     David Ahern <dsahern@...il.com>
Cc:     "David S. Miller" <davem@...emloft.net>,
        Florian Westphal <fw@...len.de>,
        Aaron Conole <aconole@...hat.com>,
        Numan Siddique <nusiddiq@...hat.com>,
        Jakub Kicinski <kuba@...nel.org>,
        Pravin B Shelar <pshelar@....org>,
        Roopa Prabhu <roopa@...ulusnetworks.com>,
        Nikolay Aleksandrov <nikolay@...ulusnetworks.com>,
        Lourdes Pedrajas <lu@...o.net>, netdev@...r.kernel.org
Subject: Re: [PATCH net-next 1/6] ipv4: route: Ignore output interface in
 FIB lookup for PMTU route

On Mon, 3 Aug 2020 17:30:46 -0600
David Ahern <dsahern@...il.com> wrote:

> On 8/3/20 2:52 PM, Stefano Brivio wrote:
> > diff --git a/net/ipv4/route.c b/net/ipv4/route.c
> > index a01efa062f6b..c14fd8124f57 100644
> > --- a/net/ipv4/route.c
> > +++ b/net/ipv4/route.c
> > @@ -1050,6 +1050,7 @@ static void ip_rt_update_pmtu(struct dst_entry *dst, struct sock *sk,
> >  	struct flowi4 fl4;
> >  
> >  	ip_rt_build_flow_key(&fl4, sk, skb);
> > +	fl4.flowi4_oif = 0;	/* Don't make lookup fail for encapsulations */
> >  	__ip_rt_update_pmtu(rt, &fl4, mtu);
> >  }
> >  
> 
> Can this be limited to:
> 	if (skb &&
> 	    netif_is_bridge_port(skb->dev) || netif_is_ovs_port(skb->dev))
> 		fl4.flowi4_oif = 0;
> 
> I'm not sure we want to reset oif for all MTU updates.

I think that generally speaking we might, because this is about the
*path* MTU after all, so the output interface doesn't look very
relevant.

On the other hand, I couldn't find any other case where this makes a
difference, and I guess it's better to eventually find out about those
other cases if any, rather than fixing things by accident possibly in
the wrong way.

Changed in v2, thanks.

-- 
Stefano