1. 13 Apr, 2020 4 commits
    • Marcelo Ricardo Leitner's avatar
      sctp: fix possibly using a bad saddr with a given dst · e2ed7b11
      Marcelo Ricardo Leitner authored
      [ Upstream commit 582eea23 ]
      
      Under certain circumstances, depending on the order of addresses on the
      interfaces, it could be that sctp_v[46]_get_dst() would return a dst
      with a mismatched struct flowi.
      
      For example, if when walking through the bind addresses and the first
      one is not a match, it saves the dst as a fallback (added in
      410f0383), but not the flowi. Then if the next one is also not a
      match, the previous dst will be returned but with the flowi information
      for the 2nd address, which is wrong.
      
      The fix is to use a locally stored flowi that can be used for such
      attempts, and copy it to the parameter only in case it is a possible
      match, together with the corresponding dst entry.
      
      The patch updates IPv6 code mostly just to be in sync. Even though the issue
      is also present there, it fallback is not expected to work with IPv6.
      
      Fixes: 410f0383 ("sctp: add routing output fallback")
      Reported-by: default avatarJin Meng <meng.a.jin@nokia-sbell.com>
      Signed-off-by: default avatarMarcelo Ricardo Leitner <marcelo.leitner@gmail.com>
      Tested-by: default avatarXin Long <lucien.xin@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e2ed7b11
    • Qiujun Huang's avatar
      sctp: fix refcount bug in sctp_wfree · 6ce6aea3
      Qiujun Huang authored
      [ Upstream commit 5c3e82fe ]
      
      We should iterate over the datamsgs to move
      all chunks(skbs) to newsk.
      
      The following case cause the bug:
      for the trouble SKB, it was in outq->transmitted list
      
      sctp_outq_sack
              sctp_check_transmitted
                      SKB was moved to outq->sacked list
              then throw away the sack queue
                      SKB was deleted from outq->sacked
      (but it was held by datamsg at sctp_datamsg_to_asoc
      So, sctp_wfree was not called here)
      
      then migrate happened
      
              sctp_for_each_tx_datachunk(
              sctp_clear_owner_w);
              sctp_assoc_migrate();
              sctp_for_each_tx_datachunk(
              sctp_set_owner_w);
      SKB was not in the outq, and was not changed to newsk
      
      finally
      
      __sctp_outq_teardown
              sctp_chunk_put (for another skb)
                      sctp_datamsg_put
                              __kfree_skb(msg->frag_list)
                                      sctp_wfree (for SKB)
      	SKB->sk was still oldsk (skb->sk != asoc->base.sk).
      
      Reported-and-tested-by: syzbot+cea71eec5d6de256d54d@syzkaller.appspotmail.com
      Signed-off-by: default avatarQiujun Huang <hqjagain@gmail.com>
      Acked-by: default avatarMarcelo Ricardo Leitner <mleitner@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6ce6aea3
    • William Dauchy's avatar
      net, ip_tunnel: fix interface lookup with no key · 48dee022
      William Dauchy authored
      [ Upstream commit 25629fda ]
      
      when creating a new ipip interface with no local/remote configuration,
      the lookup is done with TUNNEL_NO_KEY flag, making it impossible to
      match the new interface (only possible match being fallback or metada
      case interface); e.g: `ip link add tunl1 type ipip dev eth0`
      
      To fix this case, adding a flag check before the key comparison so we
      permit to match an interface with no local/remote config; it also avoids
      breaking possible userland tools relying on TUNNEL_NO_KEY flag and
      uninitialised key.
      
      context being on my side, I'm creating an extra ipip interface attached
      to the physical one, and moving it to a dedicated namespace.
      
      Fixes: c5441932 ("GRE: Refactor GRE tunneling code.")
      Signed-off-by: default avatarWilliam Dauchy <w.dauchy@criteo.com>
      Signed-off-by: default avatarNicolas Dichtel <nicolas.dichtel@6wind.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      48dee022
    • Qian Cai's avatar
      ipv4: fix a RCU-list lock in fib_triestat_seq_show · 6f2239a1
      Qian Cai authored
      [ Upstream commit fbe4e0c1 ]
      
      fib_triestat_seq_show() calls hlist_for_each_entry_rcu(tb, head,
      tb_hlist) without rcu_read_lock() will trigger a warning,
      
       net/ipv4/fib_trie.c:2579 RCU-list traversed in non-reader section!!
      
       other info that might help us debug this:
      
       rcu_scheduler_active = 2, debug_locks = 1
       1 lock held by proc01/115277:
        #0: c0000014507acf00 (&p->lock){+.+.}-{3:3}, at: seq_read+0x58/0x670
      
       Call Trace:
        dump_stack+0xf4/0x164 (unreliable)
        lockdep_rcu_suspicious+0x140/0x164
        fib_triestat_seq_show+0x750/0x880
        seq_read+0x1a0/0x670
        proc_reg_read+0x10c/0x1b0
        __vfs_read+0x3c/0x70
        vfs_read+0xac/0x170
        ksys_read+0x7c/0x140
        system_call+0x5c/0x68
      
      Fix it by adding a pair of rcu_read_lock/unlock() and use
      cond_resched_rcu() to avoid the situation where walking of a large
      number of items  may prevent scheduling for a long time.
      Signed-off-by: default avatarQian Cai <cai@lca.pw>
      Reviewed-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6f2239a1
  2. 02 Apr, 2020 36 commits