netdev - Re: [PATCH net-next 2/2] act_mirred: use the backlog for nested calls to mirred ingress

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:   Mon, 23 Jan 2023 14:22:43 -0300
From:   Marcelo Ricardo Leitner <marcelo.leitner@...il.com>
To:     Davide Caratti <dcaratti@...hat.com>
Cc:     jhs@...atatu.com, jiri@...nulli.us, lucien.xin@...il.com,
        netdev@...r.kernel.org, pabeni@...hat.com, wizhao@...hat.com,
        xiyou.wangcong@...il.com
Subject: Re: [PATCH net-next 2/2] act_mirred: use the backlog for nested
 calls to mirred ingress

On Fri, Jan 20, 2023 at 06:01:40PM +0100, Davide Caratti wrote:
> William reports kernel soft-lockups on some OVS topologies when TC mirred
> egress->ingress action is hit by local TCP traffic [1].
> The same can also be reproduced with SCTP (thanks Xin for verifying), when
> client and server reach themselves through mirred egress to ingress, and
> one of the two peers sends a "heartbeat" packet (from within a timer).
> 
> Enqueueing to backlog proved to fix this soft lockup; however, as Cong
> noticed [2], we should preserve - when possible - the current mirred
> behavior that counts as "overlimits" any eventual packet drop subsequent to
> the mirred forwarding action [3]. A compromise solution might use the
> backlog only when tcf_mirred_act() has a nest level greater than one:
> change tcf_mirred_forward() accordingly.
> 
> Also, add a kselftest that can reproduce the lockup and verifies TC mirred
> ability to account for further packet drops after TC mirred egress->ingress
> (when the nest level is 1).
> 
>  [1] https://lore.kernel.org/netdev/33dc43f587ec1388ba456b4915c75f02a8aae226.1663945716.git.dcaratti@redhat.com/
>  [2] https://lore.kernel.org/netdev/Y0w%2FWWY60gqrtGLp@pop-os.localdomain/
>  [3] such behavior is not guaranteed: for example, if RPS or skb RX
>      timestamping is enabled on the mirred target device, the kernel
>      can defer receiving the skb and return NET_RX_SUCCESS inside
>      tcf_mirred_forward().
> 
> Reported-by: William Zhao <wizhao@...hat.com>
> CC: Xin Long <lucien.xin@...il.com>
> Signed-off-by: Davide Caratti <dcaratti@...hat.com>

Reviewed-by: Marcelo Ricardo Leitner <marcelo.leitner@...il.com>