1. 12 4月, 2017 1 次提交
  2. 10 4月, 2017 1 次提交
    • E
      tcp: clear saved_syn in tcp_disconnect() · 17c3060b
      Eric Dumazet 提交于
      In the (very unlikely) case a passive socket becomes a listener,
      we do not want to duplicate its saved SYN headers.
      
      This would lead to double frees, use after free, and please hackers and
      various fuzzers
      
      Tested:
          0 socket(..., SOCK_STREAM, IPPROTO_TCP) = 3
         +0 setsockopt(3, IPPROTO_TCP, TCP_SAVE_SYN, [1], 4) = 0
         +0 fcntl(3, F_SETFL, O_RDWR|O_NONBLOCK) = 0
      
         +0 bind(3, ..., ...) = 0
         +0 listen(3, 5) = 0
      
         +0 < S 0:0(0) win 32972 <mss 1460,nop,wscale 7>
         +0 > S. 0:0(0) ack 1 <...>
        +.1 < . 1:1(0) ack 1 win 257
         +0 accept(3, ..., ...) = 4
      
         +0 connect(4, AF_UNSPEC, ...) = 0
         +0 close(3) = 0
         +0 bind(4, ..., ...) = 0
         +0 listen(4, 5) = 0
      
         +0 < S 0:0(0) win 32972 <mss 1460,nop,wscale 7>
         +0 > S. 0:0(0) ack 1 <...>
        +.1 < . 1:1(0) ack 1 win 257
      
      Fixes: cd8ae852 ("tcp: provide SYN headers for passive connections")
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      17c3060b
  3. 08 4月, 2017 4 次提交
  4. 07 4月, 2017 3 次提交
  5. 06 4月, 2017 2 次提交
  6. 05 4月, 2017 3 次提交
  7. 04 4月, 2017 3 次提交
    • M
      tcp: minimize false-positives on TCP/GRO check · 0b9aefea
      Marcelo Ricardo Leitner 提交于
      Markus Trippelsdorf reported that after commit dcb17d22 ("tcp: warn
      on bogus MSS and try to amend it") the kernel started logging the
      warning for a NIC driver that doesn't even support GRO.
      
      It was diagnosed that it was possibly caused on connections that were
      using TCP Timestamps but some packets lacked the Timestamps option. As
      we reduce rcv_mss when timestamps are used, the lack of them would cause
      the packets to be bigger than expected, although this is a valid case.
      
      As this warning is more as a hint, getting a clean-cut on the
      threshold is probably not worth the execution time spent on it. This
      patch thus alleviates the false-positives with 2 quick checks: by
      accounting for the entire TCP option space and also checking against the
      interface MTU if it's available.
      
      These changes, specially the MTU one, might mask some real positives,
      though if they are really happening, it's possible that sooner or later
      it will be triggered anyway.
      Reported-by: NMarkus Trippelsdorf <markus@trippelsdorf.de>
      Cc: Eric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: NMarcelo Ricardo Leitner <marcelo.leitner@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0b9aefea
    • X
      sctp: check for dst and pathmtu update in sctp_packet_config · df2729c3
      Xin Long 提交于
      This patch is to move sctp_transport_dst_check into sctp_packet_config
      from sctp_packet_transmit and add pathmtu check in sctp_packet_config.
      
      With this fix, sctp can update dst or pathmtu before appending chunks,
      which can void dropping packets in sctp_packet_transmit when dst is
      obsolete or dst's mtu is changed.
      
      This patch is also to improve some other codes in sctp_packet_config.
      It updates packet max_size with gso_max_size, checks for dst and
      pathmtu, and appends ecne chunk only when packet is empty and asoc
      is not NULL.
      
      It makes sctp flush work better, as we only need to set up them once
      for one flush schedule. It's also safe, since asoc is NULL only when
      the packet is created by sctp_ootb_pkt_new in which it just gets the
      new dst, no need to do more things for it other than set packet with
      transport's pathmtu.
      Signed-off-by: NXin Long <lucien.xin@gmail.com>
      Acked-by: NMarcelo Ricardo Leitner <marcelo.leitner@gmail.com>
      Acked-by: NNeil Horman <nhorman@tuxdriver.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      df2729c3
    • S
      flow dissector: correct size of storage for ARP · ac6a3722
      Simon Horman 提交于
      The last argument to __skb_header_pointer() should be a buffer large
      enough to store struct arphdr. This can be a pointer to a struct arphdr
      structure. The code was previously using a pointer to a pointer to
      struct arphdr.
      
      By my counting the storage available both before and after is 8 bytes on
      x86_64.
      
      Fixes: 55733350 ("flow disector: ARP support")
      Reported-by: NNicolas Iooss <nicolas.iooss_linux@m4x.org>
      Signed-off-by: NSimon Horman <simon.horman@netronome.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ac6a3722
  8. 03 4月, 2017 1 次提交
    • A
      make skb_copy_datagram_msg() et.al. preserve ->msg_iter on error · 32786821
      Al Viro 提交于
      Fixes the mess observed in e.g. rsync over a noisy link we'd been
      seeing since last Summer.  What happens is that we copy part of
      a datagram before noticing a checksum mismatch.  Datagram will be
      resent, all right, but we want the next try go into the same place,
      not after it...
      
      All this family of primitives (copy/checksum and copy a datagram
      into destination) is "all or nothing" sort of interface - either
      we get 0 (meaning that copy had been successful) or we get an
      error (and no way to tell how much had been copied before we ran
      into whatever error it had been).  Make all of them leave iterator
      unadvanced in case of errors - all callers must be able to cope
      with that (an error might've been caught before the iterator had
      been advanced), it costs very little to arrange, it's safer for
      callers and actually fixes at least one bug in said callers.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      32786821
  9. 02 4月, 2017 7 次提交
    • G
      l2tp: take a reference on sessions used in genetlink handlers · 2777e2ab
      Guillaume Nault 提交于
      Callers of l2tp_nl_session_find() need to hold a reference on the
      returned session since there's no guarantee that it isn't going to
      disappear from under them.
      
      Relying on the fact that no l2tp netlink message may be processed
      concurrently isn't enough: sessions can be deleted by other means
      (e.g. by closing the PPPOL2TP socket of a ppp pseudowire).
      
      l2tp_nl_cmd_session_delete() is a bit special: it runs a callback
      function that may require a previous call to session->ref(). In
      particular, for ppp pseudowires, the callback is l2tp_session_delete(),
      which then calls pppol2tp_session_close() and dereferences the PPPOL2TP
      socket. The socket might already be gone at the moment
      l2tp_session_delete() calls session->ref(), so we need to take a
      reference during the session lookup. So we need to pass the do_ref
      variable down to l2tp_session_get() and l2tp_session_get_by_ifname().
      
      Since all callers have to be updated, l2tp_session_find_by_ifname() and
      l2tp_nl_session_find() are renamed to reflect their new behaviour.
      
      Fixes: 309795f4 ("l2tp: Add netlink control API for L2TP")
      Signed-off-by: NGuillaume Nault <g.nault@alphalink.fr>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      2777e2ab
    • G
      l2tp: hold session while sending creation notifications · 5e6a9e5a
      Guillaume Nault 提交于
      l2tp_session_find() doesn't take any reference on the returned session.
      Therefore, the session may disappear while sending the notification.
      
      Use l2tp_session_get() instead and decrement session's refcount once
      the notification is sent.
      
      Fixes: 33f72e6f ("l2tp : multicast notification to the registered listeners")
      Signed-off-by: NGuillaume Nault <g.nault@alphalink.fr>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5e6a9e5a
    • G
      l2tp: fix duplicate session creation · dbdbc73b
      Guillaume Nault 提交于
      l2tp_session_create() relies on its caller for checking for duplicate
      sessions. This is racy since a session can be concurrently inserted
      after the caller's verification.
      
      Fix this by letting l2tp_session_create() verify sessions uniqueness
      upon insertion. Callers need to be adapted to check for
      l2tp_session_create()'s return code instead of calling
      l2tp_session_find().
      
      pppol2tp_connect() is a bit special because it has to work on existing
      sessions (if they're not connected) or to create a new session if none
      is found. When acting on a preexisting session, a reference must be
      held or it could go away on us. So we have to use l2tp_session_get()
      instead of l2tp_session_find() and drop the reference before exiting.
      
      Fixes: d9e31d17 ("l2tp: Add L2TP ethernet pseudowire support")
      Fixes: fd558d18 ("l2tp: Split pppol2tp patch into separate l2tp and ppp parts")
      Signed-off-by: NGuillaume Nault <g.nault@alphalink.fr>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      dbdbc73b
    • G
      l2tp: ensure session can't get removed during pppol2tp_session_ioctl() · 57377d63
      Guillaume Nault 提交于
      Holding a reference on session is required before calling
      pppol2tp_session_ioctl(). The session could get freed while processing the
      ioctl otherwise. Since pppol2tp_session_ioctl() uses the session's socket,
      we also need to take a reference on it in l2tp_session_get().
      
      Fixes: fd558d18 ("l2tp: Split pppol2tp patch into separate l2tp and ppp parts")
      Signed-off-by: NGuillaume Nault <g.nault@alphalink.fr>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      57377d63
    • G
      l2tp: fix race in l2tp_recv_common() · 61b9a047
      Guillaume Nault 提交于
      Taking a reference on sessions in l2tp_recv_common() is racy; this
      has to be done by the callers.
      
      To this end, a new function is required (l2tp_session_get()) to
      atomically lookup a session and take a reference on it. Callers then
      have to manually drop this reference.
      
      Fixes: fd558d18 ("l2tp: Split pppol2tp patch into separate l2tp and ppp parts")
      Signed-off-by: NGuillaume Nault <g.nault@alphalink.fr>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      61b9a047
    • X
      sctp: use right in and out stream cnt · afe89962
      Xin Long 提交于
      Since sctp reconf was added in sctp, the real cnt of in/out stream
      have not been c.sinit_max_instreams and c.sinit_num_ostreams any
      more.
      
      This patch is to replace them with stream->in/outcnt.
      Signed-off-by: NXin Long <lucien.xin@gmail.com>
      Acked-by: NMarcelo Ricardo Leitner <marcelo.leitner@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      afe89962
    • Y
      openvswitch: Fix ovs_flow_key_update() · 6f56f618
      Yi-Hung Wei 提交于
      ovs_flow_key_update() is called when the flow key is invalid, and it is
      used to update and revalidate the flow key. Commit 329f45bc
      ("openvswitch: add mac_proto field to the flow key") introduces mac_proto
      field to flow key and use it to determine whether the flow key is valid.
      However, the commit does not update the code path in ovs_flow_key_update()
      to revalidate the flow key which may cause BUG_ON() on execute_recirc().
      This patch addresses the aforementioned issue.
      
      Fixes: 329f45bc ("openvswitch: add mac_proto field to the flow key")
      Signed-off-by: NYi-Hung Wei <yihung.wei@gmail.com>
      Acked-by: NJiri Benc <jbenc@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6f56f618
  10. 31 3月, 2017 4 次提交
  11. 30 3月, 2017 2 次提交
  12. 29 3月, 2017 8 次提交
    • A
      xfrm_user: validate XFRM_MSG_NEWAE incoming ESN size harder · f843ee6d
      Andy Whitcroft 提交于
      Kees Cook has pointed out that xfrm_replay_state_esn_len() is subject to
      wrapping issues.  To ensure we are correctly ensuring that the two ESN
      structures are the same size compare both the overall size as reported
      by xfrm_replay_state_esn_len() and the internal length are the same.
      
      CVE-2017-7184
      Signed-off-by: NAndy Whitcroft <apw@canonical.com>
      Acked-by: NSteffen Klassert <steffen.klassert@secunet.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      f843ee6d
    • A
      xfrm_user: validate XFRM_MSG_NEWAE XFRMA_REPLAY_ESN_VAL replay_window · 677e806d
      Andy Whitcroft 提交于
      When a new xfrm state is created during an XFRM_MSG_NEWSA call we
      validate the user supplied replay_esn to ensure that the size is valid
      and to ensure that the replay_window size is within the allocated
      buffer.  However later it is possible to update this replay_esn via a
      XFRM_MSG_NEWAE call.  There we again validate the size of the supplied
      buffer matches the existing state and if so inject the contents.  We do
      not at this point check that the replay_window is within the allocated
      memory.  This leads to out-of-bounds reads and writes triggered by
      netlink packets.  This leads to memory corruption and the potential for
      priviledge escalation.
      
      We already attempt to validate the incoming replay information in
      xfrm_new_ae() via xfrm_replay_verify_len().  This confirms that the user
      is not trying to change the size of the replay state buffer which
      includes the replay_esn.  It however does not check the replay_window
      remains within that buffer.  Add validation of the contained
      replay_window.
      
      CVE-2017-7184
      Signed-off-by: NAndy Whitcroft <apw@canonical.com>
      Acked-by: NSteffen Klassert <steffen.klassert@secunet.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      677e806d
    • J
      mac80211: unconditionally start new netdev queues with iTXQ support · 7d65f829
      Johannes Berg 提交于
      When internal mac80211 TXQs aren't supported, netdev queues must
      always started out started even when driver queues are stopped
      while the interface is added. This is necessary because with the
      internal TXQ support netdev queues are never stopped and packet
      scheduling/dropping is done in mac80211.
      
      Cc: stable@vger.kernel.org # 4.9+
      Fixes: 80a83cfc ("mac80211: skip netdev queue control with software queuing")
      Reported-and-tested-by: NSven Eckelmann <sven.eckelmann@openmesh.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      7d65f829
    • L
      netfilter: nfnetlink_queue: fix secctx memory leak · 77c1c03c
      Liping Zhang 提交于
      We must call security_release_secctx to free the memory returned by
      security_secid_to_secctx, otherwise memory may be leaked forever.
      
      Fixes: ef493bd9 ("netfilter: nfnetlink_queue: add security context information")
      Signed-off-by: NLiping Zhang <zlpnobody@gmail.com>
      Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>
      77c1c03c
    • A
      cfg80211: check rdev resume callback only for registered wiphy · b3ef5520
      Arend Van Spriel 提交于
      We got the following use-after-free KASAN report:
      
       BUG: KASAN: use-after-free in wiphy_resume+0x591/0x5a0 [cfg80211]
      	 at addr ffff8803fc244090
       Read of size 8 by task kworker/u16:24/2587
       CPU: 6 PID: 2587 Comm: kworker/u16:24 Tainted: G    B 4.9.13-debug+
       Hardware name: Dell Inc. XPS 15 9550/0N7TVV, BIOS 1.2.19 12/22/2016
       Workqueue: events_unbound async_run_entry_fn
        ffff880425d4f9d8 ffffffffaeedb541 ffff88042b80ef00 ffff8803fc244088
        ffff880425d4fa00 ffffffffae84d7a1 ffff880425d4fa98 ffff8803fc244080
        ffff88042b80ef00 ffff880425d4fa88 ffffffffae84da3a ffffffffc141f7d9
       Call Trace:
        [<ffffffffaeedb541>] dump_stack+0x85/0xc4
        [<ffffffffae84d7a1>] kasan_object_err+0x21/0x70
        [<ffffffffae84da3a>] kasan_report_error+0x1fa/0x500
        [<ffffffffc141f7d9>] ? cfg80211_bss_age+0x39/0xc0 [cfg80211]
        [<ffffffffc141f83a>] ? cfg80211_bss_age+0x9a/0xc0 [cfg80211]
        [<ffffffffae48d46d>] ? trace_hardirqs_on+0xd/0x10
        [<ffffffffc13fb1c0>] ? wiphy_suspend+0xc70/0xc70 [cfg80211]
        [<ffffffffae84def1>] __asan_report_load8_noabort+0x61/0x70
        [<ffffffffc13fb100>] ? wiphy_suspend+0xbb0/0xc70 [cfg80211]
        [<ffffffffc13fb751>] ? wiphy_resume+0x591/0x5a0 [cfg80211]
        [<ffffffffc13fb751>] wiphy_resume+0x591/0x5a0 [cfg80211]
        [<ffffffffc13fb1c0>] ? wiphy_suspend+0xc70/0xc70 [cfg80211]
        [<ffffffffaf3b206e>] dpm_run_callback+0x6e/0x4f0
        [<ffffffffaf3b31b2>] device_resume+0x1c2/0x670
        [<ffffffffaf3b367d>] async_resume+0x1d/0x50
        [<ffffffffae3ee84e>] async_run_entry_fn+0xfe/0x610
        [<ffffffffae3d0666>] process_one_work+0x716/0x1a50
        [<ffffffffae3d05c9>] ? process_one_work+0x679/0x1a50
        [<ffffffffafdd7b6d>] ? _raw_spin_unlock_irq+0x3d/0x60
        [<ffffffffae3cff50>] ? pwq_dec_nr_in_flight+0x2b0/0x2b0
        [<ffffffffae3d1a80>] worker_thread+0xe0/0x1460
        [<ffffffffae3d19a0>] ? process_one_work+0x1a50/0x1a50
        [<ffffffffae3e54c2>] kthread+0x222/0x2e0
        [<ffffffffae3e52a0>] ? kthread_park+0x80/0x80
        [<ffffffffae3e52a0>] ? kthread_park+0x80/0x80
        [<ffffffffae3e52a0>] ? kthread_park+0x80/0x80
        [<ffffffffafdd86aa>] ret_from_fork+0x2a/0x40
       Object at ffff8803fc244088, in cache kmalloc-1024 size: 1024
       Allocated:
       PID = 71
        save_stack_trace+0x1b/0x20
        save_stack+0x46/0xd0
        kasan_kmalloc+0xad/0xe0
        kasan_slab_alloc+0x12/0x20
        __kmalloc_track_caller+0x134/0x360
        kmemdup+0x20/0x50
        brcmf_cfg80211_attach+0x10b/0x3a90 [brcmfmac]
        brcmf_bus_start+0x19a/0x9a0 [brcmfmac]
        brcmf_pcie_setup+0x1f1a/0x3680 [brcmfmac]
        brcmf_fw_request_nvram_done+0x44c/0x11b0 [brcmfmac]
        request_firmware_work_func+0x135/0x280
        process_one_work+0x716/0x1a50
        worker_thread+0xe0/0x1460
        kthread+0x222/0x2e0
        ret_from_fork+0x2a/0x40
       Freed:
       PID = 2568
        save_stack_trace+0x1b/0x20
        save_stack+0x46/0xd0
        kasan_slab_free+0x71/0xb0
        kfree+0xe8/0x2e0
        brcmf_cfg80211_detach+0x62/0xf0 [brcmfmac]
        brcmf_detach+0x14a/0x2b0 [brcmfmac]
        brcmf_pcie_remove+0x140/0x5d0 [brcmfmac]
        brcmf_pcie_pm_leave_D3+0x198/0x2e0 [brcmfmac]
        pci_pm_resume+0x186/0x220
        dpm_run_callback+0x6e/0x4f0
        device_resume+0x1c2/0x670
        async_resume+0x1d/0x50
        async_run_entry_fn+0xfe/0x610
        process_one_work+0x716/0x1a50
        worker_thread+0xe0/0x1460
        kthread+0x222/0x2e0
        ret_from_fork+0x2a/0x40
       Memory state around the buggy address:
        ffff8803fc243f80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
        ffff8803fc244000: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
       >ffff8803fc244080: fc fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
                                ^
        ffff8803fc244100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
        ffff8803fc244180: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
      
      What is happening is that brcmf_pcie_resume() detects a device that
      is no longer responsive and it decides to unbind resulting in a
      wiphy_unregister() and wiphy_free() call. Now the wiphy instance
      remains allocated, because PM needs to call wiphy_resume() for it.
      However, brcmfmac already does a kfree() for the struct
      cfg80211_registered_device::ops field. Change the checks in
      wiphy_resume() to only access the struct cfg80211_registered_device::ops
      if the wiphy instance is still registered at this time.
      
      Cc: stable@vger.kernel.org # 4.10.x, 4.9.x
      Reported-by: NDaniel J Blueman <daniel@quora.org>
      Reviewed-by: NHante Meuleman <hante.meuleman@broadcom.com>
      Reviewed-by: NPieter-Paul Giesberts <pieter-paul.giesberts@broadcom.com>
      Reviewed-by: NFranky Lin <franky.lin@broadcom.com>
      Signed-off-by: NArend van Spriel <arend.vanspriel@broadcom.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      b3ef5520
    • J
      openvswitch: Fix refcount leak on force commit. · b768b16d
      Jarno Rajahalme 提交于
      The reference count held for skb needs to be released when the skb's
      nfct pointer is cleared regardless of if nf_ct_delete() is called or
      not.
      
      Failing to release the skb's reference cound led to deferred conntrack
      cleanup spinning forever within nf_conntrack_cleanup_net_list() when
      cleaning up a network namespace:
      
         kworker/u16:0-19025 [004] 45981067.173642: sched_switch: kworker/u16:0:19025 [120] R ==> rcu_preempt:7 [120]
         kworker/u16:0-19025 [004] 45981067.173651: kernel_stack: <stack trace>
      => ___preempt_schedule (ffffffffa001ed36)
      => _raw_spin_unlock_bh (ffffffffa0713290)
      => nf_ct_iterate_cleanup (ffffffffc00a4454)
      => nf_conntrack_cleanup_net_list (ffffffffc00a5e1e)
      => nf_conntrack_pernet_exit (ffffffffc00a63dd)
      => ops_exit_list.isra.1 (ffffffffa06075f3)
      => cleanup_net (ffffffffa0607df0)
      => process_one_work (ffffffffa0084c31)
      => worker_thread (ffffffffa008592b)
      => kthread (ffffffffa008bee2)
      => ret_from_fork (ffffffffa071b67c)
      
      Fixes: dd41d33f ("openvswitch: Add force commit.")
      Reported-by: NYang Song <yangsong@vmware.com>
      Signed-off-by: NJarno Rajahalme <jarno@ovn.org>
      Acked-by: NJoe Stringer <joe@ovn.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b768b16d
    • C
      svcrdma: set XPT_CONG_CTRL flag for bc xprt · 23abec20
      Chuck Lever 提交于
      Same change as Kinglong Mee's fix for the TCP backchannel service.
      
      Fixes: 5283b03e ("nfs/nfsd/sunrpc: enforce transport...")
      Signed-off-by: NChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      23abec20
    • X
      sctp: change to save MSG_MORE flag into assoc · f9ba3501
      Xin Long 提交于
      David Laight noticed the support for MSG_MORE with datamsg->force_delay
      didn't really work as we expected, as the first msg with MSG_MORE set
      would always block the following chunks' dequeuing.
      
      This Patch is to rewrite it by saving the MSG_MORE flag into assoc as
      David Laight suggested.
      
      asoc->force_delay is used to save MSG_MORE flag before a msg is sent.
      All chunks in queue would not be sent out if asoc->force_delay is set
      by the msg with MSG_MORE flag, until a new msg without MSG_MORE flag
      clears asoc->force_delay.
      
      Note that this change would not affect the flush is generated by other
      triggers, like asoc->state != ESTABLISHED, queue size > pmtu etc.
      
      v1->v2:
        Not clear asoc->force_delay after sending the msg with MSG_MORE flag.
      
      Fixes: 4ea0c32f ("sctp: add support for MSG_MORE")
      Signed-off-by: NXin Long <lucien.xin@gmail.com>
      Acked-by: NDavid Laight <david.laight@aculab.com>
      Acked-by: NMarcelo Ricardo Leitner <marcelo.leitner@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f9ba3501
  13. 28 3月, 2017 1 次提交
    • M
      net: ipconfig: fix ic_close_devs() use-after-free · ffefb6f4
      Mark Rutland 提交于
      Our chosen ic_dev may be anywhere in our list of ic_devs, and we may
      free it before attempting to close others. When we compare d->dev and
      ic_dev->dev, we're potentially dereferencing memory returned to the
      allocator. This causes KASAN to scream for each subsequent ic_dev we
      check.
      
      As there's a 1-1 mapping between ic_devs and netdevs, we can instead
      compare d and ic_dev directly, which implicitly handles the !ic_dev
      case, and avoids the use-after-free. The ic_dev pointer may be stale,
      but we will not dereference it.
      
      Original splat:
      
      [    6.487446] ==================================================================
      [    6.494693] BUG: KASAN: use-after-free in ic_close_devs+0xc4/0x154 at addr ffff800367efa708
      [    6.503013] Read of size 8 by task swapper/0/1
      [    6.507452] CPU: 5 PID: 1 Comm: swapper/0 Not tainted 4.11.0-rc3-00002-gda42158 #8
      [    6.514993] Hardware name: AppliedMicro Mustang/Mustang, BIOS 3.05.05-beta_rc Jan 27 2016
      [    6.523138] Call trace:
      [    6.525590] [<ffff200008094778>] dump_backtrace+0x0/0x570
      [    6.530976] [<ffff200008094d08>] show_stack+0x20/0x30
      [    6.536017] [<ffff200008bee928>] dump_stack+0x120/0x188
      [    6.541231] [<ffff20000856d5e4>] kasan_object_err+0x24/0xa0
      [    6.546790] [<ffff20000856d924>] kasan_report_error+0x244/0x738
      [    6.552695] [<ffff20000856dfec>] __asan_report_load8_noabort+0x54/0x80
      [    6.559204] [<ffff20000aae86ac>] ic_close_devs+0xc4/0x154
      [    6.564590] [<ffff20000aaedbac>] ip_auto_config+0x2ed4/0x2f1c
      [    6.570321] [<ffff200008084b04>] do_one_initcall+0xcc/0x370
      [    6.575882] [<ffff20000aa31de8>] kernel_init_freeable+0x5f8/0x6c4
      [    6.581959] [<ffff20000a16df00>] kernel_init+0x18/0x190
      [    6.587171] [<ffff200008084710>] ret_from_fork+0x10/0x40
      [    6.592468] Object at ffff800367efa700, in cache kmalloc-128 size: 128
      [    6.598969] Allocated:
      [    6.601324] PID = 1
      [    6.603427]  save_stack_trace_tsk+0x0/0x418
      [    6.607603]  save_stack_trace+0x20/0x30
      [    6.611430]  kasan_kmalloc+0xd8/0x188
      [    6.615087]  ip_auto_config+0x8c4/0x2f1c
      [    6.619002]  do_one_initcall+0xcc/0x370
      [    6.622832]  kernel_init_freeable+0x5f8/0x6c4
      [    6.627178]  kernel_init+0x18/0x190
      [    6.630660]  ret_from_fork+0x10/0x40
      [    6.634223] Freed:
      [    6.636233] PID = 1
      [    6.638334]  save_stack_trace_tsk+0x0/0x418
      [    6.642510]  save_stack_trace+0x20/0x30
      [    6.646337]  kasan_slab_free+0x88/0x178
      [    6.650167]  kfree+0xb8/0x478
      [    6.653131]  ic_close_devs+0x130/0x154
      [    6.656875]  ip_auto_config+0x2ed4/0x2f1c
      [    6.660875]  do_one_initcall+0xcc/0x370
      [    6.664705]  kernel_init_freeable+0x5f8/0x6c4
      [    6.669051]  kernel_init+0x18/0x190
      [    6.672534]  ret_from_fork+0x10/0x40
      [    6.676098] Memory state around the buggy address:
      [    6.680880]  ffff800367efa600: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      [    6.688078]  ffff800367efa680: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
      [    6.695276] >ffff800367efa700: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
      [    6.702469]                       ^
      [    6.705952]  ffff800367efa780: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
      [    6.713149]  ffff800367efa800: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
      [    6.720343] ==================================================================
      [    6.727536] Disabling lock debugging due to kernel taint
      Signed-off-by: NMark Rutland <mark.rutland@arm.com>
      Cc: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>
      Cc: David S. Miller <davem@davemloft.net>
      Cc: Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>
      Cc: James Morris <jmorris@namei.org>
      Cc: Patrick McHardy <kaber@trash.net>
      Cc: netdev@vger.kernel.org
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ffefb6f4