netdev - Re: [PATCH] sctp: check assoc before SCTP_ADDR_{MADE

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: <CABUN9aCuoA+CXLujUxXyiKWQPkwq9_eOXNqOR=MK7dPY++Fxng@mail.gmail.com>
Date:   Wed, 13 May 2020 22:11:05 +0200
From:   Jonas Falkevik <jonas.falkevik@...il.com>
To:     Marcelo Ricardo Leitner <marcelo.leitner@...il.com>
Cc:     Vlad Yasevich <vyasevich@...il.com>,
        Neil Horman <nhorman@...driver.com>,
        "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>, linux-sctp@...r.kernel.org,
        netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
        Xin Long <lucien.xin@...il.com>
Subject: Re: [PATCH] sctp: check assoc before SCTP_ADDR_{MADE_PRIM,ADDED} event

On Wed, May 13, 2020 at 6:01 PM Marcelo Ricardo Leitner
<marcelo.leitner@...il.com> wrote:
>
> On Wed, May 13, 2020 at 04:52:16PM +0200, Jonas Falkevik wrote:
> > Do not generate SCTP_ADDR_{MADE_PRIM,ADDED} events for SCTP_FUTURE_ASSOC assocs.
>
> How did you get them?
>

I think one case is when receiving INIT chunk in sctp_sf_do_5_1B_init().
Here a closed association is created, sctp_make_temp_assoc().
Which is later used when calling sctp_process_init().
In sctp_process_init() one of the first things are to call
sctp_assoc_add_peer()
on the closed / temp assoc.

sctp_assoc_add_peer() are generating the SCTP_ADDR_ADDED event on the socket
for the potentially new association.

$ cat sctp.bpftrace
#!/usr/local/bin/bpftrace

BEGIN
{
   printf("Tracing sctp_assoc_add_peer\n");
   printf("Hit Ctrl-C to end.\n");
}

kprobe:sctp_assoc_add_peer
{
   @[kstack]=count();
}

$ sudo bpftrace sctp.bpftrace
Attaching 2 probes...
Tracing sctp_assoc_add_peer
Hit Ctrl-C to end.
^C

@[
   sctp_assoc_add_peer+1
   sctp_process_init+77
   sctp_sf_do_5_1B_init+615
   sctp_do_sm+132
   sctp_endpoint_bh_rcv+256
   sctp_rcv+2379
   ip_protocol_deliver_rcu+393
   ip_local_deliver_finish+68
   ip_local_deliver+203
   ip_rcv+156
   __netif_receive_skb_one_core+96
   process_backlog+164
   net_rx_action+312
   __softirqentry_text_start+238
   do_softirq_own_stack+42
   do_softirq.part.0+65
   __local_bh_enable_ip+75
   ip_finish_output2+415
   ip_output+102
   __ip_queue_xmit+364
   sctp_packet_transmit+1814
   sctp_outq_flush_ctrl.constprop.0+394
   sctp_outq_flush+86
   sctp_do_sm+3914
   sctp_primitive_ASSOCIATE+44
   __sctp_connect+707
   sctp_inet_connect+98
   __sys_connect+156
   __x64_sys_connect+22
   do_syscall_64+91
   entry_SYSCALL_64_after_hwframe+68
]: 1
...

> I'm thinking you're fixing a side-effect of another issue here. For
> example, in sctp_assoc_update(), it first calls sctp_assoc_add_peer()
> to only then call sctp_assoc_set_id(), which would generate the event
> you might have seen. In this case, it should be allocating IDR before,
> so that the event can be sent with the right assoc_id already.
>
> >
> > These events are described in rfc6458#section-6.1
> > SCTP_PEER_ADDR_CHANGE:
> > This tag indicates that an address that is
> > part of an existing association has experienced a change of
> > state (e.g., a failure or return to service of the reachability
> > of an endpoint via a specific transport address).
> >
> > Signed-off-by: Jonas Falkevik <jonas.falkevik@...il.com>
> > ---
> >  net/sctp/associola.c | 11 ++++++++---
> >  1 file changed, 8 insertions(+), 3 deletions(-)
> >
> > diff --git a/net/sctp/associola.c b/net/sctp/associola.c
> > index 437079a4883d..0c5dd295f9b8 100644
> > --- a/net/sctp/associola.c
> > +++ b/net/sctp/associola.c
> > @@ -432,8 +432,10 @@ void sctp_assoc_set_primary(struct sctp_association *asoc,
> >          changeover = 1 ;
> >
> >      asoc->peer.primary_path = transport;
> > -    sctp_ulpevent_nofity_peer_addr_change(transport,
> > -                          SCTP_ADDR_MADE_PRIM, 0);
> > +    if (sctp_assoc2id(asoc) != SCTP_FUTURE_ASSOC)
> > +        sctp_ulpevent_nofity_peer_addr_change(transport,
> > +                              SCTP_ADDR_MADE_PRIM,
> > +                              0);
> >
> >      /* Set a default msg_name for events. */
> >      memcpy(&asoc->peer.primary_addr, &transport->ipaddr,
> > @@ -714,7 +716,10 @@ struct sctp_transport *sctp_assoc_add_peer(struct
> > sctp_association *asoc,
> >      list_add_tail_rcu(&peer->transports, &asoc->peer.transport_addr_list);
> >      asoc->peer.transport_count++;
> >
> > -    sctp_ulpevent_nofity_peer_addr_change(peer, SCTP_ADDR_ADDED, 0);
> > +    if (sctp_assoc2id(asoc) != SCTP_FUTURE_ASSOC)
> > +        sctp_ulpevent_nofity_peer_addr_change(peer,
> > +                              SCTP_ADDR_ADDED,
> > +                              0);
> >
> >      /* If we do not yet have a primary path, set one.  */
> >      if (!asoc->peer.primary_path) {
> > --
> > 2.25.3