01 Oct, 2020

1 commit

  • [ Upstream commit f643ee295c1c63bc117fb052d4da681354d6f732 ]

    The original patch bringed in the "SCTP ACK tracking trace event"
    feature was committed at Dec.20, 2017, it replaced jprobe usage
    with trace events, and bringed in two trace events, one is
    TRACE_EVENT(sctp_probe), another one is TRACE_EVENT(sctp_probe_path).
    The original patch intended to trigger the trace_sctp_probe_path in
    TRACE_EVENT(sctp_probe) as below code,

    +TRACE_EVENT(sctp_probe,
    +
    + TP_PROTO(const struct sctp_endpoint *ep,
    + const struct sctp_association *asoc,
    + struct sctp_chunk *chunk),
    +
    + TP_ARGS(ep, asoc, chunk),
    +
    + TP_STRUCT__entry(
    + __field(__u64, asoc)
    + __field(__u32, mark)
    + __field(__u16, bind_port)
    + __field(__u16, peer_port)
    + __field(__u32, pathmtu)
    + __field(__u32, rwnd)
    + __field(__u16, unack_data)
    + ),
    +
    + TP_fast_assign(
    + struct sk_buff *skb = chunk->skb;
    +
    + __entry->asoc = (unsigned long)asoc;
    + __entry->mark = skb->mark;
    + __entry->bind_port = ep->base.bind_addr.port;
    + __entry->peer_port = asoc->peer.port;
    + __entry->pathmtu = asoc->pathmtu;
    + __entry->rwnd = asoc->peer.rwnd;
    + __entry->unack_data = asoc->unack_data;
    +
    + if (trace_sctp_probe_path_enabled()) {
    + struct sctp_transport *sp;
    +
    + list_for_each_entry(sp, &asoc->peer.transport_addr_list,
    + transports) {
    + trace_sctp_probe_path(sp, asoc);
    + }
    + }
    + ),

    But I found it did not work when I did testing, and trace_sctp_probe_path
    had no output, I finally found that there is trace buffer lock
    operation(trace_event_buffer_reserve) in include/trace/trace_events.h:

    static notrace void \
    trace_event_raw_event_##call(void *__data, proto) \
    { \
    struct trace_event_file *trace_file = __data; \
    struct trace_event_data_offsets_##call __maybe_unused __data_offsets;\
    struct trace_event_buffer fbuffer; \
    struct trace_event_raw_##call *entry; \
    int __data_size; \
    \
    if (trace_trigger_soft_disabled(trace_file)) \
    return; \
    \
    __data_size = trace_event_get_offsets_##call(&__data_offsets, args); \
    \
    entry = trace_event_buffer_reserve(&fbuffer, trace_file, \
    sizeof(*entry) + __data_size); \
    \
    if (!entry) \
    return; \
    \
    tstruct \
    \
    { assign; } \
    \
    trace_event_buffer_commit(&fbuffer); \
    }

    The reason caused no output of trace_sctp_probe_path is that
    trace_sctp_probe_path written in TP_fast_assign part of
    TRACE_EVENT(sctp_probe), and it will be placed( { assign; } ) after the
    trace_event_buffer_reserve() when compiler expands Macro,

    entry = trace_event_buffer_reserve(&fbuffer, trace_file, \
    sizeof(*entry) + __data_size); \
    \
    if (!entry) \
    return; \
    \
    tstruct \
    \
    { assign; } \

    so trace_sctp_probe_path finally can not acquire trace_event_buffer
    and return no output, that is to say the nest of tracepoint entry function
    is not allowed. The function call flow is:

    trace_sctp_probe()
    -> trace_event_raw_event_sctp_probe()
    -> lock buffer
    -> trace_sctp_probe_path()
    -> trace_event_raw_event_sctp_probe_path() --nested
    -> buffer has been locked and return no output.

    This patch is to remove trace_sctp_probe_path from the TP_fast_assign
    part of TRACE_EVENT(sctp_probe) to avoid the nest of entry function,
    and trigger sctp_probe_path_trace in sctp_outq_sack.

    After this patch, you can enable both events individually,
    # cd /sys/kernel/debug/tracing
    # echo 1 > events/sctp/sctp_probe/enable
    # echo 1 > events/sctp/sctp_probe_path/enable

    Or, you can enable all the events under sctp.

    # echo 1 > events/sctp/enable

    Signed-off-by: Kevin Kou
    Acked-by: Marcelo Ricardo Leitner
    Signed-off-by: David S. Miller
    Signed-off-by: Sasha Levin

    Kevin Kou
     

27 Sep, 2020

1 commit

  • [ Upstream commit fe81d9f6182d1160e625894eecb3d7ff0222cac5 ]

    When calculating ancestor_size with IPv6 enabled, simply using
    sizeof(struct ipv6_pinfo) doesn't account for extra bytes needed for
    alignment in the struct sctp6_sock. On x86, there aren't any extra
    bytes, but on ARM the ipv6_pinfo structure is aligned on an 8-byte
    boundary so there were 4 pad bytes that were omitted from the
    ancestor_size calculation. This would lead to corruption of the
    pd_lobby pointers, causing an oops when trying to free the sctp
    structure on socket close.

    Fixes: 636d25d557d1 ("sctp: not copy sctp_sock pd_lobby in sctp_copy_descendant")
    Signed-off-by: Henry Ptasinski
    Acked-by: Marcelo Ricardo Leitner
    Signed-off-by: David S. Miller
    Signed-off-by: Greg Kroah-Hartman

    Henry Ptasinski
     

12 Sep, 2020

1 commit

  • [ Upstream commit 3106ecb43a05dc3e009779764b9da245a5d082de ]

    With disabling bh in the whole sctp_get_port_local(), when
    snum == 0 and too many ports have been used, the do-while
    loop will take the cpu for a long time and cause cpu stuck:

    [ ] watchdog: BUG: soft lockup - CPU#11 stuck for 22s!
    [ ] RIP: 0010:native_queued_spin_lock_slowpath+0x4de/0x940
    [ ] Call Trace:
    [ ] _raw_spin_lock+0xc1/0xd0
    [ ] sctp_get_port_local+0x527/0x650 [sctp]
    [ ] sctp_do_bind+0x208/0x5e0 [sctp]
    [ ] sctp_autobind+0x165/0x1e0 [sctp]
    [ ] sctp_connect_new_asoc+0x355/0x480 [sctp]
    [ ] __sctp_connect+0x360/0xb10 [sctp]

    There's no need to disable bh in the whole function of
    sctp_get_port_local. So fix this cpu stuck by removing
    local_bh_disable() called at the beginning, and using
    spin_lock_bh() instead.

    The same thing was actually done for inet_csk_get_port() in
    Commit ea8add2b1903 ("tcp/dccp: better use of ephemeral
    ports in bind()").

    Thanks to Marcelo for pointing the buggy code out.

    v1->v2:
    - use cond_resched() to yield cpu to other tasks if needed,
    as Eric noticed.

    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Reported-by: Ying Xu
    Signed-off-by: Xin Long
    Acked-by: Marcelo Ricardo Leitner
    Signed-off-by: David S. Miller
    Signed-off-by: Greg Kroah-Hartman

    Xin Long
     

03 Sep, 2020

1 commit

  • [ Upstream commit ab921f3cdbec01c68705a7ade8bec628d541fc2b ]

    The number of output and input streams was never being reduced, eg when
    processing received INIT or INIT_ACK chunks.
    The effect is that DATA chunks can be sent with invalid stream ids
    and then discarded by the remote system.

    Fixes: 2075e50caf5ea ("sctp: convert to genradix")
    Signed-off-by: David Laight
    Acked-by: Marcelo Ricardo Leitner
    Signed-off-by: David S. Miller
    Signed-off-by: Greg Kroah-Hartman

    David Laight
     

01 Aug, 2020

2 commits

  • [ Upstream commit 3ecdda3e9ad837cf9cb41b6faa11b1af3a5abc0c ]

    When adding a stream with stream reconf, the new stream firstly is in
    CLOSED state but new out chunks can still be enqueued. Then once gets
    the confirmation from the peer, the state will change to OPEN.

    However, if the peer denies, it needs to roll back the stream. But when
    doing that, it only sets the stream outcnt back, and the chunks already
    in the new stream don't get purged. It caused these chunks can still be
    dequeued in sctp_outq_dequeue_data().

    As its stream is still in CLOSE, the chunk will be enqueued to the head
    again by sctp_outq_head_data(). This chunk will never be sent out, and
    the chunks after it can never be dequeued. The assoc will be 'hung' in
    a dead loop of sending this chunk.

    To fix it, this patch is to purge these chunks already in the new
    stream by calling sctp_stream_shrink_out() when failing to do the
    addstream reconf.

    Fixes: 11ae76e67a17 ("sctp: implement receiver-side procedures for the Reconf Response Parameter")
    Reported-by: Ying Xu
    Signed-off-by: Xin Long
    Signed-off-by: David S. Miller
    Signed-off-by: Greg Kroah-Hartman

    Xin Long
     
  • [ Upstream commit 8f13399db22f909a35735bf8ae2f932e0c8f0e30 ]

    It's not necessary to go list_for_each for outq->out_chunk_list
    when new outcnt >= old outcnt, as no chunk with higher sid than
    new (outcnt - 1) exists in the outqueue.

    While at it, also move the list_for_each code in a new function
    sctp_stream_shrink_out(), which will be used in the next patch.

    Signed-off-by: Xin Long
    Signed-off-by: David S. Miller
    Signed-off-by: Greg Kroah-Hartman

    Xin Long
     

01 Jul, 2020

1 commit

  • [ Upstream commit 471e39df96b9a4c4ba88a2da9e25a126624d7a9c ]

    If a socket is set ipv6only, it will still send IPv4 addresses in the
    INIT and INIT_ACK packets. This potentially misleads the peer into using
    them, which then would cause association termination.

    The fix is to not add IPv4 addresses to ipv6only sockets.

    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Reported-by: Corey Minyard
    Signed-off-by: Marcelo Ricardo Leitner
    Tested-by: Corey Minyard
    Signed-off-by: David S. Miller
    Signed-off-by: Greg Kroah-Hartman

    Marcelo Ricardo Leitner
     

17 Jun, 2020

2 commits

  • [ Upstream commit 5c3e82fe159622e46e91458c1a6509c321a62820 ]

    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: Qiujun Huang
    Acked-by: Marcelo Ricardo Leitner
    Signed-off-by: David S. Miller
    Signed-off-by: Sasha Levin

    Qiujun Huang
     
  • [ Upstream commit 582eea230536a6f104097dd46205822005d5fe3a ]

    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
    410f03831c07), 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: 410f03831c07 ("sctp: add routing output fallback")
    Reported-by: Jin Meng
    Signed-off-by: Marcelo Ricardo Leitner
    Tested-by: Xin Long
    Signed-off-by: David S. Miller
    Signed-off-by: Sasha Levin

    Marcelo Ricardo Leitner
     

03 Jun, 2020

2 commits

  • [ Upstream commit d3e8e4c11870413789f029a71e72ae6e971fe678 ]

    Commit bdf6fa52f01b ("sctp: handle association restarts when the
    socket is closed.") starts shutdown when an association is restarted,
    if in SHUTDOWN-PENDING state and the socket is closed. However, the
    rationale stated in that commit applies also when in SHUTDOWN-SENT
    state - we don't want to move an association to ESTABLISHED state when
    the socket has been closed, because that results in an association
    that is unreachable from user space.

    The problem scenario:

    1. Client crashes and/or restarts.

    2. Server (using one-to-one socket) calls close(). SHUTDOWN is lost.

    3. Client reconnects using the same addresses and ports.

    4. Server's association is restarted. The association and the socket
    move to ESTABLISHED state, even though the server process has
    closed its descriptor.

    Also, after step 4 when the server process exits, some resources are
    leaked in an attempt to release the underlying inet sock structure in
    ESTABLISHED state:

    IPv4: Attempt to release TCP socket in state 1 00000000377288c7

    Fix by acting the same way as in SHUTDOWN-PENDING state. That is, if
    an association is restarted in SHUTDOWN-SENT state and the socket is
    closed, then start shutdown and don't move the association or the
    socket to ESTABLISHED state.

    Fixes: bdf6fa52f01b ("sctp: handle association restarts when the socket is closed.")
    Signed-off-by: Jere Leppänen
    Acked-by: Marcelo Ricardo Leitner
    Signed-off-by: David S. Miller
    Signed-off-by: Greg Kroah-Hartman

    Jere Leppänen
     
  • [ Upstream commit 20a785aa52c82246055a089e55df9dac47d67da1 ]

    This BUG halt was reported a while back, but the patch somehow got
    missed:

    PID: 2879 TASK: c16adaa0 CPU: 1 COMMAND: "sctpn"
    #0 [f418dd28] crash_kexec at c04a7d8c
    #1 [f418dd7c] oops_end at c0863e02
    #2 [f418dd90] do_invalid_op at c040aaca
    #3 [f418de28] error_code (via invalid_op) at c08631a5
    EAX: f34baac0 EBX: 00000090 ECX: f418deb0 EDX: f5542950 EBP: 00000000
    DS: 007b ESI: f34ba800 ES: 007b EDI: f418dea0 GS: 00e0
    CS: 0060 EIP: c046fa5e ERR: ffffffff EFLAGS: 00010286
    #4 [f418de5c] add_timer at c046fa5e
    #5 [f418de68] sctp_do_sm at f8db8c77 [sctp]
    #6 [f418df30] sctp_primitive_SHUTDOWN at f8dcc1b5 [sctp]
    #7 [f418df48] inet_shutdown at c080baf9
    #8 [f418df5c] sys_shutdown at c079eedf
    #9 [f418df70] sys_socketcall at c079fe88
    EAX: ffffffda EBX: 0000000d ECX: bfceea90 EDX: 0937af98
    DS: 007b ESI: 0000000c ES: 007b EDI: b7150ae4
    SS: 007b ESP: bfceea7c EBP: bfceeaa8 GS: 0033
    CS: 0073 EIP: b775c424 ERR: 00000066 EFLAGS: 00000282

    It appears that the side effect that starts the shutdown timer was processed
    multiple times, which can happen as multiple paths can trigger it. This of
    course leads to the BUG halt in add_timer getting called.

    Fix seems pretty straightforward, just check before the timer is added if its
    already been started. If it has mod the timer instead to min(current
    expiration, new expiration)

    Its been tested but not confirmed to fix the problem, as the issue has only
    occured in production environments where test kernels are enjoined from being
    installed. It appears to be a sane fix to me though. Also, recentely,
    Jere found a reproducer posted on list to confirm that this resolves the
    issues

    Signed-off-by: Neil Horman
    CC: Vlad Yasevich
    CC: "David S. Miller"
    CC: jere.leppanen@nokia.com
    CC: marcelo.leitner@gmail.com
    CC: netdev@vger.kernel.org
    Acked-by: Marcelo Ricardo Leitner
    Signed-off-by: David S. Miller
    Signed-off-by: Greg Kroah-Hartman

    Neil Horman
     

14 May, 2020

1 commit

  • commit 145cb2f7177d94bc54563ed26027e952ee0ae03c upstream.

    When we start shutdown in sctp_sf_do_dupcook_a(), we want to bundle
    the SHUTDOWN with the COOKIE-ACK to ensure that the peer receives them
    at the same time and in the correct order. This bundling was broken by
    commit 4ff40b86262b ("sctp: set chunk transport correctly when it's a
    new asoc"), which assigns a transport for the COOKIE-ACK, but not for
    the SHUTDOWN.

    Fix this by passing a reference to the COOKIE-ACK chunk as an argument
    to sctp_sf_do_9_2_start_shutdown() and onward to
    sctp_make_shutdown(). This way the SHUTDOWN chunk is assigned the same
    transport as the COOKIE-ACK chunk, which allows them to be bundled.

    In sctp_sf_do_9_2_start_shutdown(), the void *arg parameter was
    previously unused. Now that we're taking it into use, it must be a
    valid pointer to a chunk, or NULL. There is only one call site where
    it's not, in sctp_sf_autoclose_timer_expire(). Fix that too.

    Fixes: 4ff40b86262b ("sctp: set chunk transport correctly when it's a new asoc")
    Signed-off-by: Jere Leppänen
    Acked-by: Marcelo Ricardo Leitner
    Signed-off-by: David S. Miller
    Cc: Guenter Roeck
    Signed-off-by: Greg Kroah-Hartman

    Jere Leppänen
     

10 May, 2020

1 commit

  • commit 12dfd78e3a74825e6f0bc8df7ef9f938fbc6bfe3 upstream.

    When starting shutdown in sctp_sf_do_dupcook_a(), get the value for
    SHUTDOWN Cumulative TSN Ack from the new association, which is
    reconstructed from the cookie, instead of the old association, which
    the peer doesn't have anymore.

    Otherwise the SHUTDOWN is either ignored or replied to with an ABORT
    by the peer because CTSN Ack doesn't match the peer's Initial TSN.

    Fixes: bdf6fa52f01b ("sctp: handle association restarts when the socket is closed.")
    Signed-off-by: Jere Leppänen
    Acked-by: Marcelo Ricardo Leitner
    Signed-off-by: David S. Miller
    Signed-off-by: Greg Kroah-Hartman

    Jere Leppänen
     

18 Mar, 2020

1 commit

  • [ Upstream commit 83f73c5bb7b9a9135173f0ba2b1aa00c06664ff9 ]

    In commit 1ec17dbd90f8 ("inet_diag: fix reporting cgroup classid and
    fallback to priority") croup classid reporting was fixed. But this works
    only for TCP sockets because for other socket types icsk parameter can
    be NULL and classid code path is skipped. This change moves classid
    handling to inet_diag_msg_attrs_fill() function.

    Also inet_diag_msg_attrs_size() helper was added and addends in
    nlmsg_new() were reordered to save order from inet_sk_diag_fill().

    Fixes: 1ec17dbd90f8 ("inet_diag: fix reporting cgroup classid and fallback to priority")
    Signed-off-by: Dmitry Yakunin
    Reviewed-by: Konstantin Khlebnikov
    Signed-off-by: David S. Miller
    Signed-off-by: Greg Kroah-Hartman

    Dmitry Yakunin
     

05 Mar, 2020

1 commit

  • [ Upstream commit 245709ec8be89af46ea7ef0444c9c80913999d99 ]

    When T2 timer is to be stopped, the asoc should also be deleted,
    otherwise, there will be no chance to call sctp_association_free
    and the asoc could last in memory forever.

    However, in sctp_sf_shutdown_sent_abort(), after adding the cmd
    SCTP_CMD_TIMER_STOP for T2 timer, it may return error due to the
    format error from __sctp_sf_do_9_1_abort() and miss adding
    SCTP_CMD_ASSOC_FAILED where the asoc will be deleted.

    This patch is to fix it by moving the format error check out of
    __sctp_sf_do_9_1_abort(), and do it before adding the cmd
    SCTP_CMD_TIMER_STOP for T2 timer.

    Thanks Hangbin for reporting this issue by the fuzz testing.

    v1->v2:
    - improve the comment in the code as Marcelo's suggestion.

    Fixes: 96ca468b86b0 ("sctp: check invalid value of length parameter in error cause")
    Reported-by: Hangbin Liu
    Acked-by: Marcelo Ricardo Leitner
    Signed-off-by: Xin Long
    Signed-off-by: David S. Miller
    Signed-off-by: Greg Kroah-Hartman

    Xin Long
     

12 Jan, 2020

1 commit

  • [ Upstream commit be7a7729207797476b6666f046d765bdf9630407 ]

    This patch is to fix a memleak caused by no place to free cmd->obj.chunk
    for the unprocessed SCTP_CMD_REPLY. This issue occurs when failing to
    process a cmd while there're still SCTP_CMD_REPLY cmds on the cmd seq
    with an allocated chunk in cmd->obj.chunk.

    So fix it by freeing cmd->obj.chunk for each SCTP_CMD_REPLY cmd left on
    the cmd seq when any cmd returns error. While at it, also remove 'nomem'
    label.

    Reported-by: syzbot+107c4aff5f392bf1517f@syzkaller.appspotmail.com
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Xin Long
    Signed-off-by: David S. Miller
    Signed-off-by: Greg Kroah-Hartman

    Xin Long
     

05 Jan, 2020

2 commits

  • [ Upstream commit bd085ef678b2cc8c38c105673dfe8ff8f5ec0c57 ]

    The MTU update code is supposed to be invoked in response to real
    networking events that update the PMTU. In IPv6 PMTU update function
    __ip6_rt_update_pmtu() we called dst_confirm_neigh() to update neighbor
    confirmed time.

    But for tunnel code, it will call pmtu before xmit, like:
    - tnl_update_pmtu()
    - skb_dst_update_pmtu()
    - ip6_rt_update_pmtu()
    - __ip6_rt_update_pmtu()
    - dst_confirm_neigh()

    If the tunnel remote dst mac address changed and we still do the neigh
    confirm, we will not be able to update neigh cache and ping6 remote
    will failed.

    So for this ip_tunnel_xmit() case, _EVEN_ if the MTU is changed, we
    should not be invoking dst_confirm_neigh() as we have no evidence
    of successful two-way communication at this point.

    On the other hand it is also important to keep the neigh reachability fresh
    for TCP flows, so we cannot remove this dst_confirm_neigh() call.

    To fix the issue, we have to add a new bool parameter for dst_ops.update_pmtu
    to choose whether we should do neigh update or not. I will add the parameter
    in this patch and set all the callers to true to comply with the previous
    way, and fix the tunnel code one by one on later patches.

    v5: No change.
    v4: No change.
    v3: Do not remove dst_confirm_neigh, but add a new bool parameter in
    dst_ops.update_pmtu to control whether we should do neighbor confirm.
    Also split the big patch to small ones for each area.
    v2: Remove dst_confirm_neigh in __ip6_rt_update_pmtu.

    Suggested-by: David Miller
    Reviewed-by: Guillaume Nault
    Acked-by: David Ahern
    Signed-off-by: Hangbin Liu
    Signed-off-by: David S. Miller
    Signed-off-by: Greg Kroah-Hartman

    Hangbin Liu
     
  • [ Upstream commit 61d5d4062876e21331c3d0ba4b02dbd50c06a658 ]

    The fix on 951c6db954a1 fixed the issued reported there but introduced
    another. When the allocation fails within sctp_stream_init() it is
    okay/necessary to free the genradix. But it is also called when adding
    new streams, from sctp_send_add_streams() and
    sctp_process_strreset_addstrm_in() and in those situations it cannot
    just free the genradix because by then it is a fully operational
    association.

    The fix here then is to only free the genradix in sctp_stream_init()
    and on those other call sites move on with what it already had and let
    the subsequent error handling to handle it.

    Tested with the reproducers from this report and the previous one,
    with lksctp-tools and sctp-tests.

    Reported-by: syzbot+9a1bc632e78a1a98488b@syzkaller.appspotmail.com
    Fixes: 951c6db954a1 ("sctp: fix memleak on err handling of stream initialization")
    Signed-off-by: Marcelo Ricardo Leitner
    Signed-off-by: David S. Miller
    Signed-off-by: Sasha Levin

    Marcelo Ricardo Leitner
     

31 Dec, 2019

2 commits

  • [ Upstream commit b6f3320b1d5267e7b583a6d0c88dda518101740c ]

    Syzbot found a crash:

    BUG: KMSAN: uninit-value in crc32_body lib/crc32.c:112 [inline]
    BUG: KMSAN: uninit-value in crc32_le_generic lib/crc32.c:179 [inline]
    BUG: KMSAN: uninit-value in __crc32c_le_base+0x4fa/0xd30 lib/crc32.c:202
    Call Trace:
    crc32_body lib/crc32.c:112 [inline]
    crc32_le_generic lib/crc32.c:179 [inline]
    __crc32c_le_base+0x4fa/0xd30 lib/crc32.c:202
    chksum_update+0xb2/0x110 crypto/crc32c_generic.c:90
    crypto_shash_update+0x4c5/0x530 crypto/shash.c:107
    crc32c+0x150/0x220 lib/libcrc32c.c:47
    sctp_csum_update+0x89/0xa0 include/net/sctp/checksum.h:36
    __skb_checksum+0x1297/0x12a0 net/core/skbuff.c:2640
    sctp_compute_cksum include/net/sctp/checksum.h:59 [inline]
    sctp_packet_pack net/sctp/output.c:528 [inline]
    sctp_packet_transmit+0x40fb/0x4250 net/sctp/output.c:597
    sctp_outq_flush_transports net/sctp/outqueue.c:1146 [inline]
    sctp_outq_flush+0x1823/0x5d80 net/sctp/outqueue.c:1194
    sctp_outq_uncork+0xd0/0xf0 net/sctp/outqueue.c:757
    sctp_cmd_interpreter net/sctp/sm_sideeffect.c:1781 [inline]
    sctp_side_effects net/sctp/sm_sideeffect.c:1184 [inline]
    sctp_do_sm+0x8fe1/0x9720 net/sctp/sm_sideeffect.c:1155
    sctp_primitive_REQUESTHEARTBEAT+0x175/0x1a0 net/sctp/primitive.c:185
    sctp_apply_peer_addr_params+0x212/0x1d40 net/sctp/socket.c:2433
    sctp_setsockopt_peer_addr_params net/sctp/socket.c:2686 [inline]
    sctp_setsockopt+0x189bb/0x19090 net/sctp/socket.c:4672

    The issue was caused by transport->ipaddr set with uninit addr param, which
    was passed by:

    sctp_transport_init net/sctp/transport.c:47 [inline]
    sctp_transport_new+0x248/0xa00 net/sctp/transport.c:100
    sctp_assoc_add_peer+0x5ba/0x2030 net/sctp/associola.c:611
    sctp_process_param net/sctp/sm_make_chunk.c:2524 [inline]

    where 'addr' is set by sctp_v4_from_addr_param(), and it doesn't initialize
    the padding of addr->v4.

    Later when calling sctp_make_heartbeat(), hbinfo.daddr(=transport->ipaddr)
    will become the part of skb, and the issue occurs.

    This patch is to fix it by initializing the padding of addr->v4 in
    sctp_v4_from_addr_param(), as well as other functions that do the similar
    thing, and these functions shouldn't trust that the caller initializes the
    memory, as Marcelo suggested.

    Reported-by: syzbot+6dcbfea81cd3d4dd0b02@syzkaller.appspotmail.com
    Signed-off-by: Xin Long
    Acked-by: Neil Horman
    Signed-off-by: David S. Miller
    Signed-off-by: Greg Kroah-Hartman

    Xin Long
     
  • [ Upstream commit 951c6db954a1adefab492f6da805decacabbd1a7 ]

    syzbot reported a memory leak when an allocation fails within
    genradix_prealloc() for output streams. That's because
    genradix_prealloc() leaves initialized members initialized when the
    issue happens and SCTP stack will abort the current initialization but
    without cleaning up such members.

    The fix here is to always call genradix_free() when genradix_prealloc()
    fails, for output and also input streams, as it suffers from the same
    issue.

    Reported-by: syzbot+772d9e36c490b18d51d1@syzkaller.appspotmail.com
    Fixes: 2075e50caf5e ("sctp: convert to genradix")
    Signed-off-by: Marcelo Ricardo Leitner
    Tested-by: Xin Long
    Signed-off-by: David S. Miller
    Signed-off-by: Greg Kroah-Hartman

    Marcelo Ricardo Leitner
     

18 Dec, 2019

1 commit

  • [ Upstream commit c4e85f73afb6384123e5ef1bba3315b2e3ad031e ]

    This will be used in the conversion of ipv6_stub to ip6_dst_lookup_flow,
    as some modules currently pass a net argument without a socket to
    ip6_dst_lookup. This is equivalent to commit 343d60aada5a ("ipv6: change
    ipv6_stub_impl.ipv6_dst_lookup to take net argument").

    Signed-off-by: Sabrina Dubroca
    Signed-off-by: David S. Miller
    Signed-off-by: Greg Kroah-Hartman

    Sabrina Dubroca
     

05 Dec, 2019

2 commits

  • [ Upstream commit 312434617cb16be5166316cf9d08ba760b1042a1 ]

    This patch is to fix a data-race reported by syzbot:

    BUG: KCSAN: data-race in sctp_assoc_migrate / sctp_hash_obj

    write to 0xffff8880b67c0020 of 8 bytes by task 18908 on cpu 1:
    sctp_assoc_migrate+0x1a6/0x290 net/sctp/associola.c:1091
    sctp_sock_migrate+0x8aa/0x9b0 net/sctp/socket.c:9465
    sctp_accept+0x3c8/0x470 net/sctp/socket.c:4916
    inet_accept+0x7f/0x360 net/ipv4/af_inet.c:734
    __sys_accept4+0x224/0x430 net/socket.c:1754
    __do_sys_accept net/socket.c:1795 [inline]
    __se_sys_accept net/socket.c:1792 [inline]
    __x64_sys_accept+0x4e/0x60 net/socket.c:1792
    do_syscall_64+0xcc/0x370 arch/x86/entry/common.c:290
    entry_SYSCALL_64_after_hwframe+0x44/0xa9

    read to 0xffff8880b67c0020 of 8 bytes by task 12003 on cpu 0:
    sctp_hash_obj+0x4f/0x2d0 net/sctp/input.c:894
    rht_key_get_hash include/linux/rhashtable.h:133 [inline]
    rht_key_hashfn include/linux/rhashtable.h:159 [inline]
    rht_head_hashfn include/linux/rhashtable.h:174 [inline]
    head_hashfn lib/rhashtable.c:41 [inline]
    rhashtable_rehash_one lib/rhashtable.c:245 [inline]
    rhashtable_rehash_chain lib/rhashtable.c:276 [inline]
    rhashtable_rehash_table lib/rhashtable.c:316 [inline]
    rht_deferred_worker+0x468/0xab0 lib/rhashtable.c:420
    process_one_work+0x3d4/0x890 kernel/workqueue.c:2269
    worker_thread+0xa0/0x800 kernel/workqueue.c:2415
    kthread+0x1d4/0x200 drivers/block/aoe/aoecmd.c:1253
    ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:352

    It was caused by rhashtable access asoc->base.sk when sctp_assoc_migrate
    is changing its value. However, what rhashtable wants is netns from asoc
    base.sk, and for an asoc, its netns won't change once set. So we can
    simply fix it by caching netns since created.

    Fixes: d6c0256a60e6 ("sctp: add the rhashtable apis for sctp global transport hashtable")
    Reported-by: syzbot+e3b35fe7918ff0ee474e@syzkaller.appspotmail.com
    Signed-off-by: Xin Long
    Acked-by: Marcelo Ricardo Leitner
    Signed-off-by: Jakub Kicinski
    Signed-off-by: Greg Kroah-Hartman

    Xin Long
     
  • [ Upstream commit b6631c6031c746ed004c4221ec0616d7a520f441 ]

    In the implementation of sctp_sf_do_5_2_4_dupcook() the allocated
    new_asoc is leaked if security_sctp_assoc_request() fails. Release it
    via sctp_association_free().

    Fixes: 2277c7cd75e3 ("sctp: Add LSM hooks")
    Signed-off-by: Navid Emamdoost
    Acked-by: Marcelo Ricardo Leitner
    Signed-off-by: Jakub Kicinski
    Signed-off-by: Greg Kroah-Hartman

    Navid Emamdoost
     

02 Nov, 2019

1 commit

  • Historically linux tried to stick to RFC 791, 1122, 2003
    for IPv4 ID field generation.

    RFC 6864 made clear that no matter how hard we try,
    we can not ensure unicity of IP ID within maximum
    lifetime for all datagrams with a given source
    address/destination address/protocol tuple.

    Linux uses a per socket inet generator (inet_id), initialized
    at connection startup with a XOR of 'jiffies' and other
    fields that appear clear on the wire.

    Thiemo Nagel pointed that this strategy is a privacy
    concern as this provides 16 bits of entropy to fingerprint
    devices.

    Let's switch to a random starting point, this is just as
    good as far as RFC 6864 is concerned and does not leak
    anything critical.

    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Eric Dumazet
    Reported-by: Thiemo Nagel
    Signed-off-by: David S. Miller

    Eric Dumazet
     

29 Oct, 2019

2 commits


20 Oct, 2019

1 commit

  • Pull networking fixes from David Miller:
    "I was battling a cold after some recent trips, so quite a bit piled up
    meanwhile, sorry about that.

    Highlights:

    1) Fix fd leak in various bpf selftests, from Brian Vazquez.

    2) Fix crash in xsk when device doesn't support some methods, from
    Magnus Karlsson.

    3) Fix various leaks and use-after-free in rxrpc, from David Howells.

    4) Fix several SKB leaks due to confusion of who owns an SKB and who
    should release it in the llc code. From Eric Biggers.

    5) Kill a bunc of KCSAN warnings in TCP, from Eric Dumazet.

    6) Jumbo packets don't work after resume on r8169, as the BIOS resets
    the chip into non-jumbo mode during suspend. From Heiner Kallweit.

    7) Corrupt L2 header during MPLS push, from Davide Caratti.

    8) Prevent possible infinite loop in tc_ctl_action, from Eric
    Dumazet.

    9) Get register bits right in bcmgenet driver, based upon chip
    version. From Florian Fainelli.

    10) Fix mutex problems in microchip DSA driver, from Marek Vasut.

    11) Cure race between route lookup and invalidation in ipv4, from Wei
    Wang.

    12) Fix performance regression due to false sharing in 'net'
    structure, from Eric Dumazet"

    * git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net: (145 commits)
    net: reorder 'struct net' fields to avoid false sharing
    net: dsa: fix switch tree list
    net: ethernet: dwmac-sun8i: show message only when switching to promisc
    net: aquantia: add an error handling in aq_nic_set_multicast_list
    net: netem: correct the parent's backlog when corrupted packet was dropped
    net: netem: fix error path for corrupted GSO frames
    macb: propagate errors when getting optional clocks
    xen/netback: fix error path of xenvif_connect_data()
    net: hns3: fix mis-counting IRQ vector numbers issue
    net: usb: lan78xx: Connect PHY before registering MAC
    vsock/virtio: discard packets if credit is not respected
    vsock/virtio: send a credit update when buffer size is changed
    mlxsw: spectrum_trap: Push Ethernet header before reporting trap
    net: ensure correct skb->tstamp in various fragmenters
    net: bcmgenet: reset 40nm EPHY on energy detect
    net: bcmgenet: soft reset 40nm EPHYs before MAC init
    net: phy: bcm7xxx: define soft_reset for 40nm EPHY
    net: bcmgenet: don't set phydev->link from MAC
    net: Update address for MediaTek ethernet driver in MAINTAINERS
    ipv4: fix race condition between route lookup and invalidation
    ...

    Linus Torvalds
     

16 Oct, 2019

1 commit

  • syzbot reported a memory leak:

    BUG: memory leak, unreferenced object 0xffff888120b3d380 (size 64):
    backtrace:

    [...] slab_alloc mm/slab.c:3319 [inline]
    [...] kmem_cache_alloc+0x13f/0x2c0 mm/slab.c:3483
    [...] sctp_bucket_create net/sctp/socket.c:8523 [inline]
    [...] sctp_get_port_local+0x189/0x5a0 net/sctp/socket.c:8270
    [...] sctp_do_bind+0xcc/0x200 net/sctp/socket.c:402
    [...] sctp_bindx_add+0x4b/0xd0 net/sctp/socket.c:497
    [...] sctp_setsockopt_bindx+0x156/0x1b0 net/sctp/socket.c:1022
    [...] sctp_setsockopt net/sctp/socket.c:4641 [inline]
    [...] sctp_setsockopt+0xaea/0x2dc0 net/sctp/socket.c:4611
    [...] sock_common_setsockopt+0x38/0x50 net/core/sock.c:3147
    [...] __sys_setsockopt+0x10f/0x220 net/socket.c:2084
    [...] __do_sys_setsockopt net/socket.c:2100 [inline]

    It was caused by when sending msgs without binding a port, in the path:
    inet_sendmsg() -> inet_send_prepare() -> inet_autobind() ->
    .get_port/sctp_get_port(), sp->bind_hash will be set while bp->port is
    not. Later when binding another port by sctp_setsockopt_bindx(), a new
    bucket will be created as bp->port is not set.

    sctp's autobind is supposed to call sctp_autobind() where it does all
    things including setting bp->port. Since sctp_autobind() is called in
    sctp_sendmsg() if the sk is not yet bound, it should have skipped the
    auto bind.

    THis patch is to avoid calling inet_autobind() in inet_send_prepare()
    by changing sctp_prot .no_autobind with true, also remove the unused
    .get_port.

    Reported-by: syzbot+d44f7bbebdea49dbc84a@syzkaller.appspotmail.com
    Signed-off-by: Xin Long
    Acked-by: Marcelo Ricardo Leitner
    Signed-off-by: David S. Miller

    Xin Long
     

12 Oct, 2019

1 commit


10 Oct, 2019

3 commits

  • sk->sk_backlog.len can be written by BH handlers, and read
    from process contexts in a lockless way.

    Note the write side should also use WRITE_ONCE() or a variant.
    We need some agreement about the best way to do this.

    syzbot reported :

    BUG: KCSAN: data-race in tcp_add_backlog / tcp_grow_window.isra.0

    write to 0xffff88812665f32c of 4 bytes by interrupt on cpu 1:
    sk_add_backlog include/net/sock.h:934 [inline]
    tcp_add_backlog+0x4a0/0xcc0 net/ipv4/tcp_ipv4.c:1737
    tcp_v4_rcv+0x1aba/0x1bf0 net/ipv4/tcp_ipv4.c:1925
    ip_protocol_deliver_rcu+0x51/0x470 net/ipv4/ip_input.c:204
    ip_local_deliver_finish+0x110/0x140 net/ipv4/ip_input.c:231
    NF_HOOK include/linux/netfilter.h:305 [inline]
    NF_HOOK include/linux/netfilter.h:299 [inline]
    ip_local_deliver+0x133/0x210 net/ipv4/ip_input.c:252
    dst_input include/net/dst.h:442 [inline]
    ip_rcv_finish+0x121/0x160 net/ipv4/ip_input.c:413
    NF_HOOK include/linux/netfilter.h:305 [inline]
    NF_HOOK include/linux/netfilter.h:299 [inline]
    ip_rcv+0x18f/0x1a0 net/ipv4/ip_input.c:523
    __netif_receive_skb_one_core+0xa7/0xe0 net/core/dev.c:5004
    __netif_receive_skb+0x37/0xf0 net/core/dev.c:5118
    netif_receive_skb_internal+0x59/0x190 net/core/dev.c:5208
    napi_skb_finish net/core/dev.c:5671 [inline]
    napi_gro_receive+0x28f/0x330 net/core/dev.c:5704
    receive_buf+0x284/0x30b0 drivers/net/virtio_net.c:1061
    virtnet_receive drivers/net/virtio_net.c:1323 [inline]
    virtnet_poll+0x436/0x7d0 drivers/net/virtio_net.c:1428
    napi_poll net/core/dev.c:6352 [inline]
    net_rx_action+0x3ae/0xa50 net/core/dev.c:6418

    read to 0xffff88812665f32c of 4 bytes by task 7292 on cpu 0:
    tcp_space include/net/tcp.h:1373 [inline]
    tcp_grow_window.isra.0+0x6b/0x480 net/ipv4/tcp_input.c:413
    tcp_event_data_recv+0x68f/0x990 net/ipv4/tcp_input.c:717
    tcp_rcv_established+0xbfe/0xf50 net/ipv4/tcp_input.c:5618
    tcp_v4_do_rcv+0x381/0x4e0 net/ipv4/tcp_ipv4.c:1542
    sk_backlog_rcv include/net/sock.h:945 [inline]
    __release_sock+0x135/0x1e0 net/core/sock.c:2427
    release_sock+0x61/0x160 net/core/sock.c:2943
    tcp_recvmsg+0x63b/0x1a30 net/ipv4/tcp.c:2181
    inet_recvmsg+0xbb/0x250 net/ipv4/af_inet.c:838
    sock_recvmsg_nosec net/socket.c:871 [inline]
    sock_recvmsg net/socket.c:889 [inline]
    sock_recvmsg+0x92/0xb0 net/socket.c:885
    sock_read_iter+0x15f/0x1e0 net/socket.c:967
    call_read_iter include/linux/fs.h:1864 [inline]
    new_sync_read+0x389/0x4f0 fs/read_write.c:414
    __vfs_read+0xb1/0xc0 fs/read_write.c:427
    vfs_read fs/read_write.c:461 [inline]
    vfs_read+0x143/0x2c0 fs/read_write.c:446

    Reported by Kernel Concurrency Sanitizer on:
    CPU: 0 PID: 7292 Comm: syz-fuzzer Not tainted 5.3.0+ #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011

    Signed-off-by: Eric Dumazet
    Reported-by: syzbot
    Signed-off-by: Jakub Kicinski

    Eric Dumazet
     
  • sk_add_backlog() callers usually read sk->sk_rcvbuf without
    owning the socket lock. This means sk_rcvbuf value can
    be changed by other cpus, and KCSAN complains.

    Add READ_ONCE() annotations to document the lockless nature
    of these reads.

    Note that writes over sk_rcvbuf should also use WRITE_ONCE(),
    but this will be done in separate patches to ease stable
    backports (if we decide this is relevant for stable trees).

    BUG: KCSAN: data-race in tcp_add_backlog / tcp_recvmsg

    write to 0xffff88812ab369f8 of 8 bytes by interrupt on cpu 1:
    __sk_add_backlog include/net/sock.h:902 [inline]
    sk_add_backlog include/net/sock.h:933 [inline]
    tcp_add_backlog+0x45a/0xcc0 net/ipv4/tcp_ipv4.c:1737
    tcp_v4_rcv+0x1aba/0x1bf0 net/ipv4/tcp_ipv4.c:1925
    ip_protocol_deliver_rcu+0x51/0x470 net/ipv4/ip_input.c:204
    ip_local_deliver_finish+0x110/0x140 net/ipv4/ip_input.c:231
    NF_HOOK include/linux/netfilter.h:305 [inline]
    NF_HOOK include/linux/netfilter.h:299 [inline]
    ip_local_deliver+0x133/0x210 net/ipv4/ip_input.c:252
    dst_input include/net/dst.h:442 [inline]
    ip_rcv_finish+0x121/0x160 net/ipv4/ip_input.c:413
    NF_HOOK include/linux/netfilter.h:305 [inline]
    NF_HOOK include/linux/netfilter.h:299 [inline]
    ip_rcv+0x18f/0x1a0 net/ipv4/ip_input.c:523
    __netif_receive_skb_one_core+0xa7/0xe0 net/core/dev.c:5004
    __netif_receive_skb+0x37/0xf0 net/core/dev.c:5118
    netif_receive_skb_internal+0x59/0x190 net/core/dev.c:5208
    napi_skb_finish net/core/dev.c:5671 [inline]
    napi_gro_receive+0x28f/0x330 net/core/dev.c:5704
    receive_buf+0x284/0x30b0 drivers/net/virtio_net.c:1061
    virtnet_receive drivers/net/virtio_net.c:1323 [inline]
    virtnet_poll+0x436/0x7d0 drivers/net/virtio_net.c:1428
    napi_poll net/core/dev.c:6352 [inline]
    net_rx_action+0x3ae/0xa50 net/core/dev.c:6418

    read to 0xffff88812ab369f8 of 8 bytes by task 7271 on cpu 0:
    tcp_recvmsg+0x470/0x1a30 net/ipv4/tcp.c:2047
    inet_recvmsg+0xbb/0x250 net/ipv4/af_inet.c:838
    sock_recvmsg_nosec net/socket.c:871 [inline]
    sock_recvmsg net/socket.c:889 [inline]
    sock_recvmsg+0x92/0xb0 net/socket.c:885
    sock_read_iter+0x15f/0x1e0 net/socket.c:967
    call_read_iter include/linux/fs.h:1864 [inline]
    new_sync_read+0x389/0x4f0 fs/read_write.c:414
    __vfs_read+0xb1/0xc0 fs/read_write.c:427
    vfs_read fs/read_write.c:461 [inline]
    vfs_read+0x143/0x2c0 fs/read_write.c:446
    ksys_read+0xd5/0x1b0 fs/read_write.c:587
    __do_sys_read fs/read_write.c:597 [inline]
    __se_sys_read fs/read_write.c:595 [inline]
    __x64_sys_read+0x4c/0x60 fs/read_write.c:595
    do_syscall_64+0xcf/0x2f0 arch/x86/entry/common.c:296
    entry_SYSCALL_64_after_hwframe+0x44/0xa9

    Reported by Kernel Concurrency Sanitizer on:
    CPU: 0 PID: 7271 Comm: syz-fuzzer Not tainted 5.3.0+ #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011

    Signed-off-by: Eric Dumazet
    Reported-by: syzbot
    Signed-off-by: Jakub Kicinski

    Eric Dumazet
     
  • This patch is to fix a NULL-ptr deref in selinux_socket_connect_helper:

    [...] kasan: GPF could be caused by NULL-ptr deref or user memory access
    [...] RIP: 0010:selinux_socket_connect_helper+0x94/0x460
    [...] Call Trace:
    [...] selinux_sctp_bind_connect+0x16a/0x1d0
    [...] security_sctp_bind_connect+0x58/0x90
    [...] sctp_process_asconf+0xa52/0xfd0 [sctp]
    [...] sctp_sf_do_asconf+0x785/0x980 [sctp]
    [...] sctp_do_sm+0x175/0x5a0 [sctp]
    [...] sctp_assoc_bh_rcv+0x285/0x5b0 [sctp]
    [...] sctp_backlog_rcv+0x482/0x910 [sctp]
    [...] __release_sock+0x11e/0x310
    [...] release_sock+0x4f/0x180
    [...] sctp_accept+0x3f9/0x5a0 [sctp]
    [...] inet_accept+0xe7/0x720

    It was caused by that the 'newsk' sk_socket was not set before going to
    security sctp hook when processing asconf chunk with SCTP_PARAM_ADD_IP
    or SCTP_PARAM_SET_PRIMARY:

    inet_accept()->
    sctp_accept():
    lock_sock():
    lock listening 'sk'
    do_softirq():
    sctp_rcv(): sk_socket can be NULL when the sock is closed, so SOCK_DEAD
    flag is also needed to check in sctp_newsk_ready().

    Thanks to Ondrej for reviewing the code.

    Fixes: d452930fd3b9 ("selinux: Add SCTP support")
    Reported-by: Ying Xu
    Suggested-by: Marcelo Ricardo Leitner
    Signed-off-by: Xin Long
    Acked-by: Marcelo Ricardo Leitner
    Acked-by: Neil Horman
    Signed-off-by: Jakub Kicinski

    Xin Long
     

02 Oct, 2019

1 commit

  • commit 174e23810cd31
    ("sk_buff: drop all skb extensions on free and skb scrubbing") made napi
    recycle always drop skb extensions. The additional skb_ext_del() that is
    performed via nf_reset on napi skb recycle is not needed anymore.

    Most nf_reset() calls in the stack are there so queued skb won't block
    'rmmod nf_conntrack' indefinitely.

    This removes the skb_ext_del from nf_reset, and renames it to a more
    fitting nf_reset_ct().

    In a few selected places, add a call to skb_ext_reset to make sure that
    no active extensions remain.

    I am submitting this for "net", because we're still early in the release
    cycle. The patch applies to net-next too, but I think the rename causes
    needless divergence between those trees.

    Suggested-by: Eric Dumazet
    Signed-off-by: Florian Westphal
    Signed-off-by: Pablo Neira Ayuso

    Florian Westphal
     

27 Sep, 2019

1 commit

  • Currently, ip6_xmit() sets skb->priority based on sk->sk_priority

    This is not desirable for TCP since TCP shares the same ctl socket
    for a given netns. We want to be able to send RST or ACK packets
    with a non zero skb->priority.

    This patch has no functional change.

    Signed-off-by: Eric Dumazet
    Signed-off-by: David S. Miller

    Eric Dumazet
     

15 Sep, 2019

1 commit


14 Sep, 2019

3 commits

  • There is one memory leak bug report:
    BUG: memory leak
    unreferenced object 0xffff8881dc4c5ec0 (size 40):
    comm "syz-executor.0", pid 5673, jiffies 4298198457 (age 27.578s)
    hex dump (first 32 bytes):
    02 00 00 00 81 88 ff ff 00 00 00 00 00 00 00 00 ................
    f8 63 3d c1 81 88 ff ff 00 00 00 00 00 00 00 00 .c=.............
    backtrace:
    [] sctp_get_port_local+0x2a1/0xa00 [sctp]
    [] sctp_do_bind+0x176/0x2c0 [sctp]
    [] sctp_bind+0x5a/0x80 [sctp]
    [] inet6_bind+0x59/0xd0 [ipv6]
    [] __sys_bind+0x120/0x1f0 net/socket.c:1647
    [] __do_sys_bind net/socket.c:1658 [inline]
    [] __se_sys_bind net/socket.c:1656 [inline]
    [] __x64_sys_bind+0x3e/0x50 net/socket.c:1656
    [] do_syscall_64+0x72/0x2e0 arch/x86/entry/common.c:296
    [] entry_SYSCALL_64_after_hwframe+0x49/0xbe

    This is because in sctp_do_bind, if sctp_get_port_local is to
    create hash bucket successfully, and sctp_add_bind_addr failed
    to bind address, e.g return -ENOMEM, so memory leak found, it
    needs to destroy allocated bucket.

    Reported-by: Hulk Robot
    Signed-off-by: Mao Wenan
    Acked-by: Neil Horman
    Acked-by: Marcelo Ricardo Leitner
    Signed-off-by: David S. Miller

    Mao Wenan
     
  • There are more parentheses in if clause when call sctp_get_port_local
    in sctp_do_bind, and redundant assignment to 'ret'. This patch is to
    do cleanup.

    Signed-off-by: Mao Wenan
    Acked-by: Neil Horman
    Acked-by: Marcelo Ricardo Leitner
    Signed-off-by: David S. Miller

    Mao Wenan
     
  • Currently sctp_get_port_local() returns a long
    which is either 0,1 or a pointer casted to long.
    It's neither of the callers use the return value since
    commit 62208f12451f ("net: sctp: simplify sctp_get_port").
    Now two callers are sctp_get_port and sctp_do_bind,
    they actually assumend a casted to an int was the same as
    a pointer casted to a long, and they don't save the return
    value just check whether it is zero or non-zero, so
    it would better change return type from long to int for
    sctp_get_port_local.

    Signed-off-by: Mao Wenan
    Acked-by: Marcelo Ricardo Leitner
    Signed-off-by: David S. Miller

    Mao Wenan
     

12 Sep, 2019

1 commit


11 Sep, 2019

1 commit

  • This issue causes SCTP_PEER_ADDR_THLDS sockopt not to be able to dump
    a transport thresholds info.

    Fix it by adding 'goto' put_user in sctp_getsockopt_paddr_thresholds.

    Fixes: 8add543e369d ("sctp: add SCTP_FUTURE_ASSOC for SCTP_PEER_ADDR_THLDS sockopt")
    Signed-off-by: Xin Long
    Acked-by: Marcelo Ricardo Leitner
    Acked-by: Neil Horman
    Signed-off-by: David S. Miller

    Xin Long