netdev - Re: [PATCH net 2/2] net: sched: also drop dst for the packets toward ingress in act

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CADvbK_c7byweHe=ejKe8DPFDXP=ymXC_ps2H49ioaSSmAC+-jQ@mail.gmail.com>
Date:   Wed, 22 Sep 2021 13:29:41 +0800
From:   Xin Long <lucien.xin@...il.com>
To:     Cong Wang <xiyou.wangcong@...il.com>
Cc:     network dev <netdev@...r.kernel.org>,
        David Miller <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        Marcelo Ricardo Leitner <marcelo.leitner@...il.com>,
        Davide Caratti <dcaratti@...hat.com>,
        Hangbin Liu <liuhangbin@...il.com>,
        Jamal Hadi Salim <jhs@...atatu.com>,
        Jiri Pirko <jiri@...nulli.us>
Subject: Re: [PATCH net 2/2] net: sched: also drop dst for the packets toward
 ingress in act_mirred

On Wed, Sep 22, 2021 at 11:53 AM Cong Wang <xiyou.wangcong@...il.com> wrote:
>
> On Tue, Sep 21, 2021 at 12:02 AM Xin Long <lucien.xin@...il.com> wrote:
> >
> > On Tue, Sep 21, 2021 at 2:34 AM Cong Wang <xiyou.wangcong@...il.com> wrote:
> > >
> > > On Mon, Sep 20, 2021 at 7:12 AM Xin Long <lucien.xin@...il.com> wrote:
> > > >
> > > > Without dropping dst, the packets sent from local mirred/redirected
> > > > to ingress will may still use the old dst. ip_rcv() will drop it as
> > > > the old dst is for output and its .input is dst_discard.
> > > >
> > > > This patch is to fix by also dropping dst for those packets that are
> > > > mirred or redirected to ingress in act_mirred.
> > >
> > > Similar question: what about redirecting from ingress to egress?
> > We can do it IF there's any user case needing it.
> > But for now, The problem I've met occurred in ip_rcv() for the user case.
>
> I think input route is different from output route, so essentially we need
> a reset when changing the direction, but I don't see any bugs so far,
> except this one.
Yes, this one seems more reasonable to do this reset when changing
the direction.

Maybe because in common env, it rarely redirects an egress pkt to ingress by TC.
OVS does flow control quite flexibly(complicatedly), when it offloads NAT to TC,
this problem starts showing up.