netdev - Re: VRF Issue Since kernel 5

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, 5 Apr 2020 10:52:30 -0600
From:   David Ahern <dsahern@...il.com>
To:     Maximilian Bosch <maximilian@...sch.me>, netdev@...r.kernel.org
Subject: Re: VRF Issue Since kernel 5

On 4/2/20 5:02 PM, Maximilian Bosch wrote:
> Hi!
> 
>> I do not see how this worked on 4.19. My comment above is a fundamental
>> property of VRF and has been needed since day 1. That's why 'ip vrf
>> exec' exists.
> 
> I'm afraid I have to disagree here: first of all, I created a
> regression-test in NixOS for this purpose a while ago[1]. The third test-case
> (lines 197-208) does basically what I demonstrated in my previous emails
> (opening SSH connetions through a local VRF). This worked fine until we
> bumped our default kernel to 5.4.x which is the reason why this testcase
> is temporarily commented out.

I do not have access to a NixOS install, nor the time to create one.
Please provide a set of ip commands to re-create the test that work with
Ubuntu, debian or fedora.


> After skimming through the VRF-related changes in 4.20 and 5.0 (which
> might've had some relevant changes as you suggested previously), I
> rebuilt the kernels 5.4.29 and 5.5.13 with
> 3c82a21f4320c8d54cf6456b27c8d49e5ffb722e[2] reverted on top and the
> commented-out testcase works fine again. In other words, my usecase
> seems to have worked before and the mentioned commit appears to cause
> the "regression".

The vyatta folks who made the changes will take a look.