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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Wed, 7 Oct 2020 23:22:52 -0700 From: Maciej Żenczykowski <zenczykowski@...il.com> To: Lorenzo Colitti <lorenzo@...gle.com> Cc: "David S . Miller" <davem@...emloft.net>, Linux Network Development Mailing List <netdev@...r.kernel.org>, Eric Dumazet <edumazet@...gle.com>, Willem de Bruijn <willemb@...gle.com>, Sunmeet Gill <sgill@...cinc.com>, Vinay Paradkar <vparadka@....qualcomm.com>, Tyler Wear <twear@...cinc.com>, David Ahern <dsahern@...nel.org> Subject: Re: [PATCH 1/2] net/ipv6: always honour route mtu during forwarding > On Thu, Oct 8, 2020 at 12:31 PM Maciej Żenczykowski > <zenczykowski@...il.com> wrote: > > diff --git a/include/net/ip6_route.h b/include/net/ip6_route.h > > index 2a5277758379..598415743f46 100644 > > --- a/include/net/ip6_route.h > > +++ b/include/net/ip6_route.h > > @@ -311,19 +311,13 @@ static inline bool rt6_duplicate_nexthop(struct fib6_info *a, struct fib6_info * > > static inline unsigned int ip6_dst_mtu_forward(const struct dst_entry *dst) > > { > > struct inet6_dev *idev; > > - unsigned int mtu; > > + unsigned int mtu = dst_metric_raw(dst, RTAX_MTU); > > + if (mtu) > > + return mtu; > > What should happen here if mtu is less than idev->cnf.mtu6? Should the > code pick the minimum? If not: will picking the higher value work, or > will the packet be dropped? I suppose we already have this problem > today if the administrator configures a route with a locked MTU. This feels like a misconfiguration of some sort (ie maybe should be denied at route config time), but honestly it could maybe potentially be useful: for example an ipv6 route out an ipv4 only interface with ebpf doing translation should/could actually be higher (by 20 or even 28) then device mtu. (Note: this is not the Android case, as we translate on ingress, not egress, but a setup could be created that would work, especially if there was no nat44 in the picture and the ipv6 dst address would directly select the end host) And either way... it's the same for v4, and it already behave this way in other places.
Powered by blists - more mailing lists