netdev - Re: [PATCH net 1/3] udp: check for encap using encap

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]

Message-ID: <6fbf2c3d-d42a-ecae-7fff-9efd0b58280a@novek.ru>
Date:   Mon, 12 Jul 2021 13:32:40 +0100
From:   Vadim Fedorenko <vfedorenko@...ek.ru>
To:     Paolo Abeni <pabeni@...hat.com>, David Ahern <dsahern@...nel.org>,
        Willem de Bruijn <willemb@...gle.com>,
        Xin Long <lucien.xin@...il.com>
Cc:     Jakub Kicinski <kuba@...nel.org>,
        "David S. Miller" <davem@...emloft.net>, netdev@...r.kernel.org
Subject: Re: [PATCH net 1/3] udp: check for encap using encap_enable

On 12.07.2021 09:37, Paolo Abeni wrote:
> Hello,
> 
> On Mon, 2021-07-12 at 03:55 +0300, Vadim Fedorenko wrote:
>> Usage of encap_type as a flag to determine encapsulation of udp
>> socket is not correct because there is special encap_enable field
>> for this check. Many network drivers use this field as a flag
>> instead of correctly indicate type of encapsulation. Remove such
>> usage and update all checks to use encap_enable field
> 
> Uhmm... this looks quite dangerous to me. Apparently l2tp and gtp clear
> 'encap_type' to prevent the rx path pushing pkts into the encap on
> shutdown. Will such tunnel's shutdown be safe with the above?
>
I think it's safe because all the code that checks for encap_enabled checks for
encap_rcv before invoking it and l2tp clears this handler. A bit different
situation with gtp where no clearing is done while encap destroy, so I think
the same approach could be done to clear the receive handler.

I also realised that there could be some imbalance on udp_encap_needed_key in
case of l2tp and gtp. I will try to investigate it a bit more.

>> Fixes: 60fb9567bf30 ("udp: implement complete book-keeping for encap_needed")
> 
> IMHO this not fix. Which bug are you observing that is addressed here?
> 
I thought that introduction of encap_enabled should go further to switch the
code to check this particular flag and leave encap_type as a description of
specific type (or subtype) of used encapsulation. That's why I added Fixes tag.
Correct me if I'm wrong on this assumption