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
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:	Fri, 4 Oct 2013 10:58:00 +0100
From:	Oussama Ghorbel <ou.ghorbel@...il.com>
To:	netdev@...r.kernel.org
Subject: Re: The check of upper MTU limit when changing it in ip6 gre tunnel
 seems incorrect.

I have sent this patch to address the issue.

[PATCH] Fix the upper MTU limit in ipv6 GRE tunnel

On Wed, Oct 2, 2013 at 5:44 PM, Oussama Ghorbel <ou.ghorbel@...il.com> wrote:
> The check of upper MTU limit when changing it in ip6 gre tunnel seems incorrect.
> The function in question is:
>
> static int ip6gre_tunnel_change_mtu(struct net_device *dev, int new_mtu)
> {
>     struct ip6_tnl *tunnel = netdev_priv(dev);
>
>     if (new_mtu < 68 ||
>         new_mtu > 0xFFF8 - dev->hard_header_len - tunnel->hlen)
>         return -EINVAL;
>     dev->mtu = new_mtu;
>     return 0;
> }
>
> However the dev->hard_header_len and tunnel->hlen are initialized in
> the following way in ip6gre_tnl_link_config():
>
> int addend = sizeof(struct ipv6hdr) + 4;
> ...
> dev->hard_header_len = rt->dst.dev->hard_header_len + addend;
> ...
> t->hlen = addend; // t is ip6_tnl pointer
>
> As you see the information t->hlen is already included in
> dev->hard_header_len, so why calculate it twice?
>
> Thanks
--
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