netdev - Re: [PATCH net] ipv4: tcp: Fix SO

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:   Tue, 30 Jun 2020 20:45:13 -0400
From:   Willem de Bruijn <willemdebruijn.kernel@...il.com>
To:     Martin KaFai Lau <kafai@...com>
Cc:     Willem de Bruijn <willemdebruijn.kernel@...il.com>,
        Network Development <netdev@...r.kernel.org>,
        David Miller <davem@...emloft.net>,
        Kernel Team <kernel-team@...com>
Subject: Re: [PATCH net] ipv4: tcp: Fix SO_MARK in RST and ACK packet

On Tue, Jun 30, 2020 at 7:46 PM Martin KaFai Lau <kafai@...com> wrote:
>
> On Tue, Jun 30, 2020 at 07:20:46PM -0400, Willem de Bruijn wrote:
> > On Tue, Jun 30, 2020 at 6:18 PM Martin KaFai Lau <kafai@...com> wrote:
> > >
> > > When testing a recent kernel (5.6 in our case), the skb->mark of the
> > > IPv4 TCP RST pkt does not carry the mark from sk->sk_mark.  It is
> > > discovered by the bpf@tc that depends on skb->mark to work properly.
> > > The same bpf prog has been working in the earlier kernel version.
> > > After reverting commit c6af0c227a22 ("ip: support SO_MARK cmsg"),
> > > the skb->mark is set and seen by bpf@tc properly.
> > >
> > > We have noticed that in IPv4 TCP RST but it should also
> > > happen to the ACK based on tcp_v4_send_ack() is also depending
> > > on ip_send_unicast_reply().
> > >
> > > This patch tries to fix it by initializing the ipc.sockc.mark to
> > > fl4.flowi4_mark.
> > >
> > > Fixes: c6af0c227a22 ("ip: support SO_MARK cmsg")
> > > Cc: Willem de Bruijn <willemb@...gle.com>
> > > Signed-off-by: Martin KaFai Lau <kafai@...com>
> > > ---
> > >  net/ipv4/ip_output.c | 1 +
> > >  1 file changed, 1 insertion(+)
> > >
> > > diff --git a/net/ipv4/ip_output.c b/net/ipv4/ip_output.c
> > > index 090d3097ee15..033512f719ec 100644
> > > --- a/net/ipv4/ip_output.c
> > > +++ b/net/ipv4/ip_output.c
> > > @@ -1703,6 +1703,7 @@ void ip_send_unicast_reply(struct sock *sk, struct sk_buff *skb,
> > >         sk->sk_bound_dev_if = arg->bound_dev_if;
> > >         sk->sk_sndbuf = sysctl_wmem_default;
> > >         sk->sk_mark = fl4.flowi4_mark;
> > > +       ipc.sockc.mark = fl4.flowi4_mark;
> > >         err = ip_append_data(sk, &fl4, ip_reply_glue_bits, arg->iov->iov_base,
> > >                              len, 0, &ipc, &rt, MSG_DONTWAIT);
> > >         if (unlikely(err)) {
> >
> > Yes, this total sense. I missed these cases.
> >
> > Slight modification, the line above then no longer needs to be set.
> > That line was added in commit bf99b4ded5f8 ("tcp: fix mark propagation
> > with fwmark_reflect enabled"). Basically, it pretends that the socket
> > has a mark associated, but sk here is always the (netns) global
> > control sock. So your BPF program was depending on fwmark_reflect?
> Make sense.  I was also tempting to remove the line above.
> Thanks for the commit pointer.
>
> No, the BPF program does not depend on fwmark_reflect.  It depends
> on the sk->sk_mark set by a user space process.

Then I don't fully understand, as ip_send_unicast_reply is only called
with the per-netns percpu ctl_sk.

> I was also considering to do ipcm_init_sk() but then rolled back
> because of the global control sock here.
>
> >
> > ipv6 seems to work differently enough not to have this problem,
> > tcp_v6_send_response passing fl6.flowi6_mark directly to ip6_xmit.
> > This was added in commit commit 92e55f412cff ("tcp: don't annotate
> > mark on control socket from tcp_v6_send_response()").
> Correct. IPv6 does it differently, so the same problem is
> not observed in IPv6.
>
> >
> > But I do see the same pattern where a socket mark is set from a
> > reflected value in icmp_reply and __icmp_send. Those almost certainly
> > need updating too. I can do that separately if you prefer. I even
> > placed ipcm_init right below this sk_mark initialization without
> > considering ipcm_init_sk. D'oh.
> Good point.  I think it will only be a few lines change altogether,
> so it makes little sense to break up the fix.  I will toss mine and
> wait for yours ;)

Will do. Want to double check my initial rushed reading first.

> Thanks for your help!

Not at all. Apologies for the breakage.. Thanks for the initial fix!