netdev - Re: [PATCH net-next v5 03/11] tcp: use drop reasons in cookie check for ipv4

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: <CAL+tcoDCOJCX8NerEpu_0gxhdPCABADRKSpBAJEXohTXBBqTSQ@mail.gmail.com>
Date: Fri, 16 Feb 2024 09:28:26 +0800
From: Jason Xing <kerneljasonxing@...il.com>
To: Kuniyuki Iwashima <kuniyu@...zon.com>
Cc: davem@...emloft.net, dsahern@...nel.org, edumazet@...gle.com, 
	kernelxing@...cent.com, kuba@...nel.org, netdev@...r.kernel.org, 
	pabeni@...hat.com
Subject: Re: [PATCH net-next v5 03/11] tcp: use drop reasons in cookie check
 for ipv4

On Fri, Feb 16, 2024 at 5:09 AM Kuniyuki Iwashima <kuniyu@...zon.com> wrote:
>
> From: Jason Xing <kerneljasonxing@...il.com>
> Date: Thu, 15 Feb 2024 09:20:19 +0800
> > From: Jason Xing <kernelxing@...cent.com>
> >
> > Now it's time to use the prepared definitions to refine this part.
> > Four reasons used might enough for now, I think.
> >
> > Signed-off-by: Jason Xing <kernelxing@...cent.com>
> > --
> > v5:
> > Link: https://lore.kernel.org/netdev/CANn89i+iELpsoea6+C-08m6+=JkneEEM=nAj-28eNtcOCkwQjw@mail.gmail.com/
> > Link: https://lore.kernel.org/netdev/632c6fd4-e060-4b8e-a80e-5d545a6c6b6c@kernel.org/
> > 1. Use SKB_DROP_REASON_IP_OUTNOROUTES instead of introducing a new one (Eric, David)
> > 2. Reuse SKB_DROP_REASON_NOMEM to handle failure of request socket allocation (Eric)
> > 3. Reuse NO_SOCKET instead of introducing COOKIE_NOCHILD
> > ---
> >  net/ipv4/syncookies.c | 18 +++++++++++++-----
> >  1 file changed, 13 insertions(+), 5 deletions(-)
> >
> > diff --git a/net/ipv4/syncookies.c b/net/ipv4/syncookies.c
> > index 38f331da6677..aeb61c880fbd 100644
> > --- a/net/ipv4/syncookies.c
> > +++ b/net/ipv4/syncookies.c
> > @@ -421,8 +421,10 @@ struct sock *cookie_v4_check(struct sock *sk, struct sk_buff *skb)
> >               if (IS_ERR(req))
> >                       goto out;
> >       }
> > -     if (!req)
> > +     if (!req) {
> > +             SKB_DR_SET(reason, NOMEM);
>
> NOMEM is not appropriate when mptcp_subflow_init_cookie_req() fails.

Thanks for your careful check. It's true. I didn't check the MPTCP
path about how to handle it.

It also means that what I did to the cookie_v6_check() is also wrong.

[...]
> >       /* Try to redo what tcp_v4_send_synack did. */
> >       req->rsk_window_clamp = tp->window_clamp ? :dst_metric(&rt->dst, RTAX_WINDOW);
> > @@ -476,10 +482,12 @@ struct sock *cookie_v4_check(struct sock *sk, struct sk_buff *skb)
> >       /* ip_queue_xmit() depends on our flow being setup
> >        * Normal sockets get it right from inet_csk_route_child_sock()
> >        */
> > -     if (ret)
> > +     if (ret) {
> >               inet_sk(ret)->cork.fl.u.ip4 = fl4;
> > -     else
> > +     } else {
> > +             SKB_DR_SET(reason, NO_SOCKET);
>
> This also seems wrong to me.
>
> e.g. syn_recv_sock() could fail with sk_acceptq_is_full(sk),
> then the listener is actually found.

Initially I thought using a not-that-clear name could be helpfull,
though. NO_SOCKET here means no child socket can be used if I add a
new description to SKB_DROP_REASON_NO_SOCKET.

If the idea is proper, how about using NO_SOCKET for the first point
you said to explain that there is no request socket that can be used?

If not, for both of the points you mentioned, it seems I have to add
back those two new reasons (perhaps with a better name updated)?
1. Using SKB_DROP_REASON_REQSK_ALLOC for the first point (request
socket allocation in cookie_v4/6_check())
2. Using SKB_DROP_REASON_GET_SOCK for the second point (child socket
fetching in cookie_v4/6_check())

Now I'm struggling with the name and whether I should introduce some
new reasons like what I did in the old version of the series :S

If someone comes up with a good name or a good way to explain them,
please tell me, thanks!

also cc Eric, David

Thanks,
Jason

>
>
> >               goto out_drop;
> > +     }
> >  out:
> >       return ret;
> >  out_free:
> > --
> > 2.37.3
> >