netdev - Re: [PATCH net] selftests: pmtu: Fix encapsulating device in pmtu_vti6_link_change

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]

Date:   Tue, 28 May 2019 17:15:21 -0700 (PDT)
From:   David Miller <davem@...emloft.net>
To:     sbrivio@...hat.com
Cc:     xmu@...hat.com, netdev@...r.kernel.org
Subject: Re: [PATCH net] selftests: pmtu: Fix encapsulating device in
 pmtu_vti6_link_change_mtu

From: Stefano Brivio <sbrivio@...hat.com>
Date: Mon, 27 May 2019 19:42:23 +0200

> In the pmtu_vti6_link_change_mtu test, both local and remote addresses
> for the vti6 tunnel are assigned to the same address given to the dummy
> interface that we use as encapsulating device with a known MTU.
> 
> This works as long as the dummy interface is actually selected, via
> rt6_lookup(), as encapsulating device. But if the remote address of the
> tunnel is a local address too, the loopback interface could also be
> selected, and there's nothing wrong with it.
> 
> This is what some older -stable kernels do (3.18.z, at least), and
> nothing prevents us from subtly changing FIB implementation to revert
> back to that behaviour in the future.
> 
> Define an IPv6 prefix instead, and use two separate addresses as local
> and remote for vti6, so that the encapsulating device can't be a
> loopback interface.
> 
> Reported-by: Xiumei Mu <xmu@...hat.com>
> Fixes: 1fad59ea1c34 ("selftests: pmtu: Add pmtu_vti6_link_change_mtu test")
> Signed-off-by: Stefano Brivio <sbrivio@...hat.com>

Applied.