• J
    sctp: Fixup v4mapped behaviour to comply with Sock API · 299ee123
    Jason Gunthorpe 提交于
    The SCTP socket extensions API document describes the v4mapping option as
    follows:
    
    8.1.15.  Set/Clear IPv4 Mapped Addresses (SCTP_I_WANT_MAPPED_V4_ADDR)
    
       This socket option is a Boolean flag which turns on or off the
       mapping of IPv4 addresses.  If this option is turned on, then IPv4
       addresses will be mapped to V6 representation.  If this option is
       turned off, then no mapping will be done of V4 addresses and a user
       will receive both PF_INET6 and PF_INET type addresses on the socket.
       See [RFC3542] for more details on mapped V6 addresses.
    
    This description isn't really in line with what the code does though.
    
    Introduce addr_to_user (renamed addr_v4map), which should be called
    before any sockaddr is passed back to user space. The new function
    places the sockaddr into the correct format depending on the
    SCTP_I_WANT_MAPPED_V4_ADDR option.
    
    Audit all places that touched v4mapped and either sanely construct
    a v4 or v6 address then call addr_to_user, or drop the
    unnecessary v4mapped check entirely.
    
    Audit all places that call addr_to_user and verify they are on a sycall
    return path.
    
    Add a custom getname that formats the address properly.
    
    Several bugs are addressed:
     - SCTP_I_WANT_MAPPED_V4_ADDR=0 often returned garbage for
       addresses to user space
     - The addr_len returned from recvmsg was not correct when
       returning AF_INET on a v6 socket
     - flowlabel and scope_id were not zerod when promoting
       a v4 to v6
     - Some syscalls like bind and connect behaved differently
       depending on v4mapped
    
    Tested bind, getpeername, getsockname, connect, and recvmsg for proper
    behaviour in v4mapped = 1 and 0 cases.
    Signed-off-by: NNeil Horman <nhorman@tuxdriver.com>
    Tested-by: NJason Gunthorpe <jgunthorpe@obsidianresearch.com>
    Signed-off-by: NJason Gunthorpe <jgunthorpe@obsidianresearch.com>
    Signed-off-by: NDavid S. Miller <davem@davemloft.net>
    299ee123
structs.h 60.6 KB