• Xin Long's avatar
    sctp: fix src address selection if using secondary addresses for ipv6 · dbc2b5e9
    Xin Long authored
    Commit 0ca50d12 ("sctp: fix src address selection if using secondary
    addresses") has fixed a src address selection issue when using secondary
    addresses for ipv4.
    
    Now sctp ipv6 also has the similar issue. When using a secondary address,
    sctp_v6_get_dst tries to choose the saddr which has the most same bits
    with the daddr by sctp_v6_addr_match_len. It may make some cases not work
    as expected.
    
    hostA:
      [1] fd21:356b:459a:cf10::11 (eth1)
      [2] fd21:356b:459a:cf20::11 (eth2)
    
    hostB:
      [a] fd21:356b:459a:cf30::2  (eth1)
      [b] fd21:356b:459a:cf40::2  (eth2)
    
    route from hostA to hostB:
      fd21:356b:459a:cf30::/64 dev eth1  metric 1024  mtu 1500
    
    The expected path should be:
      fd21:356b:459a:cf10::11 <-> fd21:356b:459a:cf30::2
    But addr[2] matches addr[a] more bits than addr[1] does, according to
    sctp_v6_addr_match_len. It causes the path to be:
      fd21:356b:459a:cf20::11 <-> fd21:356b:459a:cf30::2
    
    This patch is to fix it with the same way as Marcelo's fix for sctp ipv4.
    As no ip_dev_find for ipv6, this patch is to use ipv6_chk_addr to check
    if the saddr is in a dev instead.
    
    Note that for backwards compatibility, it will still do the addr_match_len
    check here when no optimal is found.
    Reported-by: default avatarPatrick Talbert <ptalbert@redhat.com>
    Signed-off-by: default avatarXin Long <lucien.xin@gmail.com>
    Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    dbc2b5e9
ipv6.c 29 KB