1. 13 11月, 2019 6 次提交
    • S
      net: qualcomm: rmnet: Fix potential UAF when unregistering · 4fd21807
      Sean Tranchetti 提交于
      [ Upstream commit e7a86c687e64ab24f88330ad24ecc9442ce40c5a ]
      
      During the exit/unregistration process of the RmNet driver, the function
      rmnet_unregister_real_device() is called to handle freeing the driver's
      internal state and removing the RX handler on the underlying physical
      device. However, the order of operations this function performs is wrong
      and can lead to a use after free of the rmnet_port structure.
      
      Before calling netdev_rx_handler_unregister(), this port structure is
      freed with kfree(). If packets are received on any RmNet devices before
      synchronize_net() completes, they will attempt to use this already-freed
      port structure when processing the packet. As such, before cleaning up any
      other internal state, the RX handler must be unregistered in order to
      guarantee that no further packets will arrive on the device.
      
      Fixes: ceed73a2 ("drivers: net: ethernet: qualcomm: rmnet: Initial implementation")
      Signed-off-by: NSean Tranchetti <stranche@codeaurora.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4fd21807
    • E
      net: fix data-race in neigh_event_send() · b9bda52f
      Eric Dumazet 提交于
      [ Upstream commit 1b53d64435d56902fc234ff2507142d971a09687 ]
      
      KCSAN reported the following data-race [1]
      
      The fix will also prevent the compiler from optimizing out
      the condition.
      
      [1]
      
      BUG: KCSAN: data-race in neigh_resolve_output / neigh_resolve_output
      
      write to 0xffff8880a41dba78 of 8 bytes by interrupt on cpu 1:
       neigh_event_send include/net/neighbour.h:443 [inline]
       neigh_resolve_output+0x78/0x480 net/core/neighbour.c:1474
       neigh_output include/net/neighbour.h:511 [inline]
       ip_finish_output2+0x4af/0xe40 net/ipv4/ip_output.c:228
       __ip_finish_output net/ipv4/ip_output.c:308 [inline]
       __ip_finish_output+0x23a/0x490 net/ipv4/ip_output.c:290
       ip_finish_output+0x41/0x160 net/ipv4/ip_output.c:318
       NF_HOOK_COND include/linux/netfilter.h:294 [inline]
       ip_output+0xdf/0x210 net/ipv4/ip_output.c:432
       dst_output include/net/dst.h:436 [inline]
       ip_local_out+0x74/0x90 net/ipv4/ip_output.c:125
       __ip_queue_xmit+0x3a8/0xa40 net/ipv4/ip_output.c:532
       ip_queue_xmit+0x45/0x60 include/net/ip.h:237
       __tcp_transmit_skb+0xe81/0x1d60 net/ipv4/tcp_output.c:1169
       tcp_transmit_skb net/ipv4/tcp_output.c:1185 [inline]
       __tcp_retransmit_skb+0x4bd/0x15f0 net/ipv4/tcp_output.c:2976
       tcp_retransmit_skb+0x36/0x1a0 net/ipv4/tcp_output.c:2999
       tcp_retransmit_timer+0x719/0x16d0 net/ipv4/tcp_timer.c:515
       tcp_write_timer_handler+0x42d/0x510 net/ipv4/tcp_timer.c:598
       tcp_write_timer+0xd1/0xf0 net/ipv4/tcp_timer.c:618
      
      read to 0xffff8880a41dba78 of 8 bytes by interrupt on cpu 0:
       neigh_event_send include/net/neighbour.h:442 [inline]
       neigh_resolve_output+0x57/0x480 net/core/neighbour.c:1474
       neigh_output include/net/neighbour.h:511 [inline]
       ip_finish_output2+0x4af/0xe40 net/ipv4/ip_output.c:228
       __ip_finish_output net/ipv4/ip_output.c:308 [inline]
       __ip_finish_output+0x23a/0x490 net/ipv4/ip_output.c:290
       ip_finish_output+0x41/0x160 net/ipv4/ip_output.c:318
       NF_HOOK_COND include/linux/netfilter.h:294 [inline]
       ip_output+0xdf/0x210 net/ipv4/ip_output.c:432
       dst_output include/net/dst.h:436 [inline]
       ip_local_out+0x74/0x90 net/ipv4/ip_output.c:125
       __ip_queue_xmit+0x3a8/0xa40 net/ipv4/ip_output.c:532
       ip_queue_xmit+0x45/0x60 include/net/ip.h:237
       __tcp_transmit_skb+0xe81/0x1d60 net/ipv4/tcp_output.c:1169
       tcp_transmit_skb net/ipv4/tcp_output.c:1185 [inline]
       __tcp_retransmit_skb+0x4bd/0x15f0 net/ipv4/tcp_output.c:2976
       tcp_retransmit_skb+0x36/0x1a0 net/ipv4/tcp_output.c:2999
       tcp_retransmit_timer+0x719/0x16d0 net/ipv4/tcp_timer.c:515
       tcp_write_timer_handler+0x42d/0x510 net/ipv4/tcp_timer.c:598
      
      Reported by Kernel Concurrency Sanitizer on:
      CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.4.0-rc3+ #0
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Reported-by: Nsyzbot <syzkaller@googlegroups.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b9bda52f
    • A
      net: ethernet: octeon_mgmt: Account for second possible VLAN header · 2fbfdb2d
      Alexander Sverdlin 提交于
      [ Upstream commit e4dd5608033efe7b6030cde359bfdbaeb73bc22d ]
      
      Octeon's input ring-buffer entry has 14 bits-wide size field, so to account
      for second possible VLAN header max_mtu must be further reduced.
      
      Fixes: 109cc165 ("ethernet/cavium: use core min/max MTU checking")
      Signed-off-by: NAlexander Sverdlin <alexander.sverdlin@nokia.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2fbfdb2d
    • D
      ipv4: Fix table id reference in fib_sync_down_addr · 88f8c399
      David Ahern 提交于
      [ Upstream commit e0a312629fefa943534fc46f7bfbe6de3fdaf463 ]
      
      Hendrik reported routes in the main table using source address are not
      removed when the address is removed. The problem is that fib_sync_down_addr
      does not account for devices in the default VRF which are associated
      with the main table. Fix by updating the table id reference.
      
      Fixes: 5a56a0b3 ("net: Don't delete routes in different VRFs")
      Reported-by: NHendrik Donner <hd@os-cillation.de>
      Signed-off-by: NDavid Ahern <dsahern@kernel.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      88f8c399
    • O
      CDC-NCM: handle incomplete transfer of MTU · 0ddabef8
      Oliver Neukum 提交于
      [ Upstream commit 332f989a3b0041b810836c5c3747e59aad7e9d0b ]
      
      A malicious device may give half an answer when asked
      for its MTU. The driver will proceed after this with
      a garbage MTU. Anything but a complete answer must be treated
      as an error.
      
      V2: used sizeof as request by Alexander
      
      Reported-and-tested-by: syzbot+0631d878823ce2411636@syzkaller.appspotmail.com
      Signed-off-by: NOliver Neukum <oneukum@suse.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0ddabef8
    • J
      bonding: fix state transition issue in link monitoring · 27b5f4bf
      Jay Vosburgh 提交于
      [ Upstream commit 1899bb325149e481de31a4f32b59ea6f24e176ea ]
      
      Since de77ecd4 ("bonding: improve link-status update in
      mii-monitoring"), the bonding driver has utilized two separate variables
      to indicate the next link state a particular slave should transition to.
      Each is used to communicate to a different portion of the link state
      change commit logic; one to the bond_miimon_commit function itself, and
      another to the state transition logic.
      
      	Unfortunately, the two variables can become unsynchronized,
      resulting in incorrect link state transitions within bonding.  This can
      cause slaves to become stuck in an incorrect link state until a
      subsequent carrier state transition.
      
      	The issue occurs when a special case in bond_slave_netdev_event
      sets slave->link directly to BOND_LINK_FAIL.  On the next pass through
      bond_miimon_inspect after the slave goes carrier up, the BOND_LINK_FAIL
      case will set the proposed next state (link_new_state) to BOND_LINK_UP,
      but the new_link to BOND_LINK_DOWN.  The setting of the final link state
      from new_link comes after that from link_new_state, and so the slave
      will end up incorrectly in _DOWN state.
      
      	Resolve this by combining the two variables into one.
      Reported-by: NAleksei Zakharov <zakharov.a.g@yandex.ru>
      Reported-by: NSha Zhang <zhangsha.zhang@huawei.com>
      Cc: Mahesh Bandewar <maheshb@google.com>
      Fixes: de77ecd4 ("bonding: improve link-status update in mii-monitoring")
      Signed-off-by: NJay Vosburgh <jay.vosburgh@canonical.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      27b5f4bf
  2. 10 11月, 2019 34 次提交
    • G
      Linux 4.19.83 · 7d8dbefc
      Greg Kroah-Hartman 提交于
      7d8dbefc
    • R
      usb: gadget: udc: core: Fix segfault if udc_bind_to_driver() for pending driver fails · 818c96ac
      Roger Quadros 提交于
      commit 163be6ff7739b12ff300d77897d340f661821da2 upstream.
      
      If a gadget driver is in the pending drivers list, a UDC
      becomes available and udc_bind_to_driver() fails, then it
      gets deleted from the pending list.
      i.e. list_del(&driver->pending) in check_pending_gadget_drivers().
      
      Then if that gadget driver is unregistered,
      usb_gadget_unregister_driver() does a list_del(&driver->pending)
      again thus causing a page fault as that list entry has been poisoned
      by the previous list_del().
      
      Fix this by using list_del_init() instead of list_del() in
      check_pending_gadget_drivers().
      
      Test case:
      
      - Make sure no UDC is available
      - modprobe g_mass_storage file=wrongfile
      - Load UDC driver so it becomes available
      	lun0: unable to open backing file: wrongfile
      - modprobe -r g_mass_storage
      
      [   60.900431] Unable to handle kernel paging request at virtual address dead000000000108
      [   60.908346] Mem abort info:
      [   60.911145]   ESR = 0x96000044
      [   60.914227]   Exception class = DABT (current EL), IL = 32 bits
      [   60.920162]   SET = 0, FnV = 0
      [   60.923217]   EA = 0, S1PTW = 0
      [   60.926354] Data abort info:
      [   60.929228]   ISV = 0, ISS = 0x00000044
      [   60.933058]   CM = 0, WnR = 1
      [   60.936011] [dead000000000108] address between user and kernel address ranges
      [   60.943136] Internal error: Oops: 96000044 [#1] PREEMPT SMP
      [   60.948691] Modules linked in: g_mass_storage(-) usb_f_mass_storage libcomposite xhci_plat_hcd xhci_hcd usbcore ti_am335x_adc kfifo_buf omap_rng cdns3 rng_core udc_core crc32_ce xfrm_user crct10dif_ce snd_so6
      [   60.993995] Process modprobe (pid: 834, stack limit = 0x00000000c2aebc69)
      [   61.000765] CPU: 0 PID: 834 Comm: modprobe Not tainted 4.19.59-01963-g065f42a60499 #92
      [   61.008658] Hardware name: Texas Instruments SoC (DT)
      [   61.014472] pstate: 60000005 (nZCv daif -PAN -UAO)
      [   61.019253] pc : usb_gadget_unregister_driver+0x7c/0x108 [udc_core]
      [   61.025503] lr : usb_gadget_unregister_driver+0x30/0x108 [udc_core]
      [   61.031750] sp : ffff00001338fda0
      [   61.035049] x29: ffff00001338fda0 x28: ffff800846d40000
      [   61.040346] x27: 0000000000000000 x26: 0000000000000000
      [   61.045642] x25: 0000000056000000 x24: 0000000000000800
      [   61.050938] x23: ffff000008d7b0d0 x22: ffff0000088b07c8
      [   61.056234] x21: ffff000001100000 x20: ffff000002020260
      [   61.061530] x19: ffff0000010ffd28 x18: 0000000000000000
      [   61.066825] x17: 0000000000000000 x16: 0000000000000000
      [   61.072121] x15: 0000000000000000 x14: 0000000000000000
      [   61.077417] x13: ffff000000000000 x12: ffffffffffffffff
      [   61.082712] x11: 0000000000000030 x10: 7f7f7f7f7f7f7f7f
      [   61.088008] x9 : fefefefefefefeff x8 : 0000000000000000
      [   61.093304] x7 : ffffffffffffffff x6 : 000000000000ffff
      [   61.098599] x5 : 8080000000000000 x4 : 0000000000000000
      [   61.103895] x3 : ffff000001100020 x2 : ffff800846d40000
      [   61.109190] x1 : dead000000000100 x0 : dead000000000200
      [   61.114486] Call trace:
      [   61.116922]  usb_gadget_unregister_driver+0x7c/0x108 [udc_core]
      [   61.122828]  usb_composite_unregister+0x10/0x18 [libcomposite]
      [   61.128643]  msg_cleanup+0x18/0xfce0 [g_mass_storage]
      [   61.133682]  __arm64_sys_delete_module+0x17c/0x1f0
      [   61.138458]  el0_svc_common+0x90/0x158
      [   61.142192]  el0_svc_handler+0x2c/0x80
      [   61.145926]  el0_svc+0x8/0xc
      [   61.148794] Code: eb03003f d10be033 54ffff21 a94d0281 (f9000420)
      [   61.154869] ---[ end trace afb22e9b637bd9a7 ]---
      Segmentation fault
      Acked-by: NAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: NRoger Quadros <rogerq@ti.com>
      Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>
      Signed-off-by: NMathieu Poirier <mathieu.poirier@linaro.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      818c96ac
    • S
      arm64: dts: ti: k3-am65-main: Fix gic-its node unit-address · b06f37ea
      Suman Anna 提交于
      commit 389ce1a7c5279ebfb682fab220b4021b2bd49c8b upstream.
      
      The gic-its node unit-address has an additional zero compared
      to the actual reg value. Fix it.
      
      Fixes: ea47eed3 ("arm64: dts: ti: Add Support for AM654 SoC")
      Reported-by: NRobert Tivy <rtivy@ti.com>
      Signed-off-by: NSuman Anna <s-anna@ti.com>
      Signed-off-by: NTero Kristo <t-kristo@ti.com>
      Signed-off-by: NMathieu Poirier <mathieu.poirier@linaro.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b06f37ea
    • P
      ASoC: pcm3168a: The codec does not support S32_LE · 54ee5ccd
      Peter Ujfalusi 提交于
      commit 7b2db65b59c30d58c129d3c8b2101feca686155a upstream.
      
      24 bits is supported in all modes and 16 bit only when the codec is slave
      and the DAI is set to RIGHT_J.
      
      Remove the unsupported sample format.
      Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
      Link: https://lore.kernel.org/r/20190919071652.31724-1-peter.ujfalusi@ti.comSigned-off-by: NMark Brown <broonie@kernel.org>
      Signed-off-by: NMathieu Poirier <mathieu.poirier@linaro.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      54ee5ccd
    • D
      selftests/powerpc: Fix compile error on tlbie_test due to newer gcc · 3ddf2a70
      Desnes A. Nunes do Rosario 提交于
      commit 5b216ea1c40cf06eead15054c70e238c9bd4729e upstream.
      
      Newer versions of GCC (>= 9) demand that the size of the string to be
      copied must be explicitly smaller than the size of the destination.
      Thus, the NULL char has to be taken into account on strncpy.
      
      This will avoid the following compiling error:
      
        tlbie_test.c: In function 'main':
        tlbie_test.c:639:4: error: 'strncpy' specified bound 100 equals destination size
            strncpy(logdir, optarg, LOGDIR_NAME_SIZE);
            ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
        cc1: all warnings being treated as errors
      Signed-off-by: NDesnes A. Nunes do Rosario <desnesn@linux.ibm.com>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      Link: https://lore.kernel.org/r/20191003211010.9711-1-desnesn@linux.ibm.com
      [sandipan: Backported to v4.19]
      Signed-off-by: NSandipan Das <sandipan@linux.ibm.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3ddf2a70
    • A
      selftests/powerpc: Add test case for tlbie vs mtpidr ordering issue · e7aaa8dd
      Aneesh Kumar K.V 提交于
      commit 93cad5f789951eaa27c3392b15294b4e51253944 upstream.
      Signed-off-by: NAneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
      [mpe: Some minor fixes to make it build]
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      Link: https://lore.kernel.org/r/20190924035254.24612-4-aneesh.kumar@linux.ibm.com
      [sandipan: Backported to v4.19]
      Signed-off-by: NSandipan Das <sandipan@linux.ibm.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e7aaa8dd
    • A
      powerpc/mm: Fixup tlbie vs mtpidr/mtlpidr ordering issue on POWER9 · ec199b24
      Aneesh Kumar K.V 提交于
      commit 047e6575aec71d75b765c22111820c4776cd1c43 upstream.
      
      On POWER9, under some circumstances, a broadcast TLB invalidation will
      fail to invalidate the ERAT cache on some threads when there are
      parallel mtpidr/mtlpidr happening on other threads of the same core.
      This can cause stores to continue to go to a page after it's unmapped.
      
      The workaround is to force an ERAT flush using PID=0 or LPID=0 tlbie
      flush. This additional TLB flush will cause the ERAT cache
      invalidation. Since we are using PID=0 or LPID=0, we don't get
      filtered out by the TLB snoop filtering logic.
      
      We need to still follow this up with another tlbie to take care of
      store vs tlbie ordering issue explained in commit:
      a5d4b589 ("powerpc/mm: Fixup tlbie vs store ordering issue on
      POWER9"). The presence of ERAT cache implies we can still get new
      stores and they may miss store queue marking flush.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: NAneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      Link: https://lore.kernel.org/r/20190924035254.24612-3-aneesh.kumar@linux.ibm.com
      [sandipan: Backported to v4.19]
      Signed-off-by: NSandipan Das <sandipan@linux.ibm.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ec199b24
    • J
      platform/x86: pmc_atom: Add Siemens SIMATIC IPC227E to critclk_systems DMI table · 06e8438e
      Jan Kiszka 提交于
      commit ad0d315b4d4e7138f43acf03308192ec00e9614d upstream.
      
      The SIMATIC IPC227E uses the PMC clock for on-board components and gets
      stuck during boot if the clock is disabled. Therefore, add this device
      to the critical systems list.
      
      Fixes: 648e9218 ("clk: x86: Stop marking clocks as CLK_IS_CRITICAL")
      Signed-off-by: NJan Kiszka <jan.kiszka@siemens.com>
      Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      06e8438e
    • M
      wireless: Skip directory when generating certificates · 2d830cf2
      Maxim Mikityanskiy 提交于
      [ Upstream commit 32b5a2c9950b9284000059d752f7afa164deb15e ]
      
      Commit 715a1233 ("wireless: don't write C files on failures") drops
      the `test -f $$f` check. The list of targets contains the
      CONFIG_CFG80211_EXTRA_REGDB_KEYDIR directory itself, and this check used
      to filter it out. After the check was removed, the extra keydir option
      no longer works, failing with the following message:
      
      od: 'standard input': read error: Is a directory
      
      This commit restores the check to make extra keydir work again.
      
      Fixes: 715a1233 ("wireless: don't write C files on failures")
      Signed-off-by: NMaxim Mikityanskiy <maxtram95@gmail.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      2d830cf2
    • E
      net/flow_dissector: switch to siphash · 558d2bda
      Eric Dumazet 提交于
      [ Upstream commit 55667441c84fa5e0911a0aac44fb059c15ba6da2 ]
      
      UDP IPv6 packets auto flowlabels are using a 32bit secret
      (static u32 hashrnd in net/core/flow_dissector.c) and
      apply jhash() over fields known by the receivers.
      
      Attackers can easily infer the 32bit secret and use this information
      to identify a device and/or user, since this 32bit secret is only
      set at boot time.
      
      Really, using jhash() to generate cookies sent on the wire
      is a serious security concern.
      
      Trying to change the rol32(hash, 16) in ip6_make_flowlabel() would be
      a dead end. Trying to periodically change the secret (like in sch_sfq.c)
      could change paths taken in the network for long lived flows.
      
      Let's switch to siphash, as we did in commit df453700e8d8
      ("inet: switch IP ID generator to siphash")
      
      Using a cryptographically strong pseudo random function will solve this
      privacy issue and more generally remove other weak points in the stack.
      
      Packet schedulers using skb_get_hash_perturb() benefit from this change.
      
      Fixes: b5677416 ("ipv6: Enable auto flow labels by default")
      Fixes: 42240901 ("ipv6: Implement different admin modes for automatic flow labels")
      Fixes: 67800f9b ("ipv6: Call skb_get_hash_flowi6 to get skb->hash in ip6_make_flowlabel")
      Fixes: cb1ce2ef ("ipv6: Implement automatic flow label generation on transmit")
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Reported-by: NJonathan Berger <jonathann1@walla.com>
      Reported-by: NAmit Klein <aksecurity@gmail.com>
      Reported-by: NBenny Pinkas <benny@pinkas.net>
      Cc: Tom Herbert <tom@herbertland.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      558d2bda
    • K
      r8152: add device id for Lenovo ThinkPad USB-C Dock Gen 2 · f6ef3599
      Kazutoshi Noguchi 提交于
      [ Upstream commit b3060531979422d5bb18d80226f978910284dc70 ]
      
      This device is sold as 'ThinkPad USB-C Dock Gen 2 (40AS)'.
      Chipset is RTL8153 and works with r8152.
      Without this, the generic cdc_ether grabs the device, and the device jam
      connected networks up when the machine suspends.
      Signed-off-by: NKazutoshi Noguchi <noguchi.kazutosi@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f6ef3599
    • V
      net: dsa: fix switch tree list · c33f7efe
      Vivien Didelot 提交于
      [ Upstream commit 50c7d2ba9de20f60a2d527ad6928209ef67e4cdd ]
      
      If there are multiple switch trees on the device, only the last one
      will be listed, because the arguments of list_add_tail are swapped.
      
      Fixes: 83c0afae ("net: dsa: Add new binding implementation")
      Signed-off-by: NVivien Didelot <vivien.didelot@gmail.com>
      Reviewed-by: NFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c33f7efe
    • A
      net: usb: lan78xx: Connect PHY before registering MAC · 6b5bf3f3
      Andrew Lunn 提交于
      [ Upstream commit 38b4fe320119859c11b1dc06f6b4987a16344fa1 ]
      
      As soon as the netdev is registers, the kernel can start using the
      interface. If the driver connects the MAC to the PHY after the netdev
      is registered, there is a race condition where the interface can be
      opened without having the PHY connected.
      
      Change the order to close this race condition.
      
      Fixes: 92571a1a ("lan78xx: Connect phy early")
      Reported-by: NDaniel Wagner <dwagner@suse.de>
      Signed-off-by: NAndrew Lunn <andrew@lunn.ch>
      Tested-by: NDaniel Wagner <dwagner@suse.de>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6b5bf3f3
    • D
      net: bcmgenet: reset 40nm EPHY on energy detect · 07c62fc7
      Doug Berger 提交于
      [ Upstream commit 25382b991d252aed961cd434176240f9de6bb15f ]
      
      The EPHY integrated into the 40nm Set-Top Box devices can falsely
      detect energy when connected to a disabled peer interface. When the
      peer interface is enabled the EPHY will detect and report the link
      as active, but on occasion may get into a state where it is not
      able to exchange data with the connected GENET MAC. This issue has
      not been observed when the link parameters are auto-negotiated;
      however, it has been observed with a manually configured link.
      
      It has been empirically determined that issuing a soft reset to the
      EPHY when energy is detected prevents it from getting into this bad
      state.
      
      Fixes: 1c1008c7 ("net: bcmgenet: add main driver file")
      Signed-off-by: NDoug Berger <opendmb@gmail.com>
      Acked-by: NFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      07c62fc7
    • D
      net: phy: bcm7xxx: define soft_reset for 40nm EPHY · 6d3ccc2a
      Doug Berger 提交于
      [ Upstream commit fe586b823372a9f43f90e2c6aa0573992ce7ccb7 ]
      
      The internal 40nm EPHYs use a "Workaround for putting the PHY in
      IDDQ mode." These PHYs require a soft reset to restore functionality
      after they are powered back up.
      
      This commit defines the soft_reset function to use genphy_soft_reset
      during phy_init_hw to accommodate this.
      
      Fixes: 6e2d85ec0559 ("net: phy: Stop with excessive soft reset")
      Signed-off-by: NDoug Berger <opendmb@gmail.com>
      Acked-by: NFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6d3ccc2a
    • D
      net: bcmgenet: don't set phydev->link from MAC · 97cc6827
      Doug Berger 提交于
      [ Upstream commit 7de48402faa32298c3551ea32c76ccb4f9d3025d ]
      
      When commit 28b2e0d2 ("net: phy: remove parameter new_link from
      phy_mac_interrupt()") removed the new_link parameter it set the
      phydev->link state from the MAC before invoking phy_mac_interrupt().
      
      However, once commit 88d6272acaaa ("net: phy: avoid unneeded MDIO
      reads in genphy_read_status") was added this initialization prevents
      the proper determination of the connection parameters by the function
      genphy_read_status().
      
      This commit removes that initialization to restore the proper
      functionality.
      
      Fixes: 88d6272acaaa ("net: phy: avoid unneeded MDIO reads in genphy_read_status")
      Signed-off-by: NDoug Berger <opendmb@gmail.com>
      Acked-by: NFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      97cc6827
    • F
      net: dsa: b53: Do not clear existing mirrored port mask · 57e286f6
      Florian Fainelli 提交于
      [ Upstream commit c763ac436b668d7417f0979430ec0312ede4093d ]
      
      Clearing the existing bitmask of mirrored ports essentially prevents us
      from capturing more than one port at any given time. This is clearly
      wrong, do not clear the bitmask prior to setting up the new port.
      Reported-by: NHubert Feurstein <h.feurstein@gmail.com>
      Fixes: ed3af5fd ("net: dsa: b53: Add support for port mirroring")
      Signed-off-by: NFlorian Fainelli <f.fainelli@gmail.com>
      Reviewed-by: NVivien Didelot <vivien.didelot@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      57e286f6
    • A
      net/mlx5e: Fix ethtool self test: link speed · db91be8e
      Aya Levin 提交于
      [ Upstream commit 534e7366f41b0c689b01af4375aefcd1462adedf ]
      
      Ethtool self test contains a test for link speed. This test reads the
      PTYS register and determines whether the current speed is valid or not.
      Change current implementation to use the function mlx5e_port_linkspeed()
      that does the same check and fails when speed is invalid. This code
      redundancy lead to a bug when mlx5e_port_linkspeed() was updated with
      expended speeds and the self test was not.
      
      Fixes: 2c81bfd5 ("net/mlx5e: Move port speed code from en_ethtool.c to en/port.c")
      Signed-off-by: NAya Levin <ayal@mellanox.com>
      Reviewed-by: NMoshe Shemesh <moshe@mellanox.com>
      Signed-off-by: NSaeed Mahameed <saeedm@mellanox.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      db91be8e
    • H
      r8169: fix wrong PHY ID issue with RTL8168dp · 5eb1967b
      Heiner Kallweit 提交于
      [ Upstream commit 62bdc8fd1c21d4263ebd18bec57f82532d09249f ]
      
      As reported in [0] at least one RTL8168dp version has problems
      establishing a link. This chip version has an integrated RTL8211b PHY,
      however the chip seems to report a wrong PHY ID, resulting in a wrong
      PHY driver (for Generic Realtek PHY) being loaded.
      Work around this issue by adding a hook to r8168dp_2_mdio_read()
      for returning the correct PHY ID.
      
      [0] https://bbs.archlinux.org/viewtopic.php?id=246508
      
      Fixes: 242cd9b5 ("r8169: use phy_resume/phy_suspend")
      Signed-off-by: NHeiner Kallweit <hkallweit1@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5eb1967b
    • M
      net/mlx5e: Fix handling of compressed CQEs in case of low NAPI budget · 9e7c4fa2
      Maxim Mikityanskiy 提交于
      [ Upstream commit 9df86bdb6746d7fcfc2fda715f7a7c3d0ddb2654 ]
      
      When CQE compression is enabled, compressed CQEs use the following
      structure: a title is followed by one or many blocks, each containing 8
      mini CQEs (except the last, which may contain fewer mini CQEs).
      
      Due to NAPI budget restriction, a complete structure is not always
      parsed in one NAPI run, and some blocks with mini CQEs may be deferred
      to the next NAPI poll call - we have the mlx5e_decompress_cqes_cont call
      in the beginning of mlx5e_poll_rx_cq. However, if the budget is
      extremely low, some blocks may be left even after that, but the code
      that follows the mlx5e_decompress_cqes_cont call doesn't check it and
      assumes that a new CQE begins, which may not be the case. In such cases,
      random memory corruptions occur.
      
      An extremely low NAPI budget of 8 is used when busy_poll or busy_read is
      active.
      
      This commit adds a check to make sure that the previous compressed CQE
      has been completely parsed after mlx5e_decompress_cqes_cont, otherwise
      it prevents a new CQE from being fetched in the middle of a compressed
      CQE.
      
      This commit fixes random crashes in __build_skb, __page_pool_put_page
      and other not-related-directly places, that used to happen when both CQE
      compression and busy_poll/busy_read were enabled.
      
      Fixes: 7219ab34 ("net/mlx5e: CQE compression")
      Signed-off-by: NMaxim Mikityanskiy <maximmi@mellanox.com>
      Signed-off-by: NSaeed Mahameed <saeedm@mellanox.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9e7c4fa2
    • P
      selftests: fib_tests: add more tests for metric update · 0c3355cc
      Paolo Abeni 提交于
      [ Upstream commit 37de3b354150450ba12275397155e68113e99901 ]
      
      This patch adds two more tests to ipv4_addr_metric_test() to
      explicitly cover the scenarios fixed by the previous patch.
      Suggested-by: NDavid Ahern <dsahern@gmail.com>
      Signed-off-by: NPaolo Abeni <pabeni@redhat.com>
      Reviewed-by: NDavid Ahern <dsahern@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0c3355cc
    • P
      ipv4: fix route update on metric change. · b166e883
      Paolo Abeni 提交于
      [ Upstream commit 0b834ba00ab5337e938c727e216e1f5249794717 ]
      
      Since commit af4d768a ("net/ipv4: Add support for specifying metric
      of connected routes"), when updating an IP address with a different metric,
      the associated connected route is updated, too.
      
      Still, the mentioned commit doesn't handle properly some corner cases:
      
      $ ip addr add dev eth0 192.168.1.0/24
      $ ip addr add dev eth0 192.168.2.1/32 peer 192.168.2.2
      $ ip addr add dev eth0 192.168.3.1/24
      $ ip addr change dev eth0 192.168.1.0/24 metric 10
      $ ip addr change dev eth0 192.168.2.1/32 peer 192.168.2.2 metric 10
      $ ip addr change dev eth0 192.168.3.1/24 metric 10
      $ ip -4 route
      192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.0
      192.168.2.2 dev eth0 proto kernel scope link src 192.168.2.1
      192.168.3.0/24 dev eth0 proto kernel scope link src 192.168.2.1 metric 10
      
      Only the last route is correctly updated.
      
      The problem is the current test in fib_modify_prefix_metric():
      
      	if (!(dev->flags & IFF_UP) ||
      	    ifa->ifa_flags & (IFA_F_SECONDARY | IFA_F_NOPREFIXROUTE) ||
      	    ipv4_is_zeronet(prefix) ||
      	    prefix == ifa->ifa_local || ifa->ifa_prefixlen == 32)
      
      Which should be the logical 'not' of the pre-existing test in
      fib_add_ifaddr():
      
      	if (!ipv4_is_zeronet(prefix) && !(ifa->ifa_flags & IFA_F_SECONDARY) &&
      	    (prefix != addr || ifa->ifa_prefixlen < 32))
      
      To properly negate the original expression, we need to change the last
      logical 'or' to a logical 'and'.
      
      Fixes: af4d768a ("net/ipv4: Add support for specifying metric of connected routes")
      Reported-and-suggested-by: NBeniamino Galvani <bgalvani@redhat.com>
      Signed-off-by: NPaolo Abeni <pabeni@redhat.com>
      Reviewed-by: NDavid Ahern <dsahern@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b166e883
    • E
      net: add READ_ONCE() annotation in __skb_wait_for_more_packets() · cd3bcb44
      Eric Dumazet 提交于
      [ Upstream commit 7c422d0ce97552dde4a97e6290de70ec6efb0fc6 ]
      
      __skb_wait_for_more_packets() can be called while other cpus
      can feed packets to the socket receive queue.
      
      KCSAN reported :
      
      BUG: KCSAN: data-race in __skb_wait_for_more_packets / __udp_enqueue_schedule_skb
      
      write to 0xffff888102e40b58 of 8 bytes by interrupt on cpu 0:
       __skb_insert include/linux/skbuff.h:1852 [inline]
       __skb_queue_before include/linux/skbuff.h:1958 [inline]
       __skb_queue_tail include/linux/skbuff.h:1991 [inline]
       __udp_enqueue_schedule_skb+0x2d7/0x410 net/ipv4/udp.c:1470
       __udp_queue_rcv_skb net/ipv4/udp.c:1940 [inline]
       udp_queue_rcv_one_skb+0x7bd/0xc70 net/ipv4/udp.c:2057
       udp_queue_rcv_skb+0xb5/0x400 net/ipv4/udp.c:2074
       udp_unicast_rcv_skb.isra.0+0x7e/0x1c0 net/ipv4/udp.c:2233
       __udp4_lib_rcv+0xa44/0x17c0 net/ipv4/udp.c:2300
       udp_rcv+0x2b/0x40 net/ipv4/udp.c:2470
       ip_protocol_deliver_rcu+0x4d/0x420 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:5010
       __netif_receive_skb+0x37/0xf0 net/core/dev.c:5124
       process_backlog+0x1d3/0x420 net/core/dev.c:5955
      
      read to 0xffff888102e40b58 of 8 bytes by task 13035 on cpu 1:
       __skb_wait_for_more_packets+0xfa/0x320 net/core/datagram.c:100
       __skb_recv_udp+0x374/0x500 net/ipv4/udp.c:1683
       udp_recvmsg+0xe1/0xb10 net/ipv4/udp.c:1712
       inet_recvmsg+0xbb/0x250 net/ipv4/af_inet.c:838
       sock_recvmsg_nosec+0x5c/0x70 net/socket.c:871
       ___sys_recvmsg+0x1a0/0x3e0 net/socket.c:2480
       do_recvmmsg+0x19a/0x5c0 net/socket.c:2601
       __sys_recvmmsg+0x1ef/0x200 net/socket.c:2680
       __do_sys_recvmmsg net/socket.c:2703 [inline]
       __se_sys_recvmmsg net/socket.c:2696 [inline]
       __x64_sys_recvmmsg+0x89/0xb0 net/socket.c:2696
       do_syscall_64+0xcc/0x370 arch/x86/entry/common.c:290
       entry_SYSCALL_64_after_hwframe+0x44/0xa9
      
      Reported by Kernel Concurrency Sanitizer on:
      CPU: 1 PID: 13035 Comm: syz-executor.3 Not tainted 5.4.0-rc3+ #0
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Reported-by: Nsyzbot <syzkaller@googlegroups.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      cd3bcb44
    • E
      net: use skb_queue_empty_lockless() in busy poll contexts · 4f3df7f1
      Eric Dumazet 提交于
      [ Upstream commit 3f926af3f4d688e2e11e7f8ed04e277a14d4d4a4 ]
      
      Busy polling usually runs without locks.
      Let's use skb_queue_empty_lockless() instead of skb_queue_empty()
      
      Also uses READ_ONCE() in __skb_try_recv_datagram() to address
      a similar potential problem.
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4f3df7f1
    • E
      net: use skb_queue_empty_lockless() in poll() handlers · eaf548fe
      Eric Dumazet 提交于
      [ Upstream commit 3ef7cf57c72f32f61e97f8fa401bc39ea1f1a5d4 ]
      
      Many poll() handlers are lockless. Using skb_queue_empty_lockless()
      instead of skb_queue_empty() is more appropriate.
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      eaf548fe
    • E
      udp: use skb_queue_empty_lockless() · afa1f5e9
      Eric Dumazet 提交于
      [ Upstream commit 137a0dbe3426fd7bcfe3f8117b36a87b3590e4eb ]
      
      syzbot reported a data-race [1].
      
      We should use skb_queue_empty_lockless() to document that we are
      not ensuring a mutual exclusion and silence KCSAN.
      
      [1]
      BUG: KCSAN: data-race in __skb_recv_udp / __udp_enqueue_schedule_skb
      
      write to 0xffff888122474b50 of 8 bytes by interrupt on cpu 0:
       __skb_insert include/linux/skbuff.h:1852 [inline]
       __skb_queue_before include/linux/skbuff.h:1958 [inline]
       __skb_queue_tail include/linux/skbuff.h:1991 [inline]
       __udp_enqueue_schedule_skb+0x2c1/0x410 net/ipv4/udp.c:1470
       __udp_queue_rcv_skb net/ipv4/udp.c:1940 [inline]
       udp_queue_rcv_one_skb+0x7bd/0xc70 net/ipv4/udp.c:2057
       udp_queue_rcv_skb+0xb5/0x400 net/ipv4/udp.c:2074
       udp_unicast_rcv_skb.isra.0+0x7e/0x1c0 net/ipv4/udp.c:2233
       __udp4_lib_rcv+0xa44/0x17c0 net/ipv4/udp.c:2300
       udp_rcv+0x2b/0x40 net/ipv4/udp.c:2470
       ip_protocol_deliver_rcu+0x4d/0x420 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:5010
       __netif_receive_skb+0x37/0xf0 net/core/dev.c:5124
       process_backlog+0x1d3/0x420 net/core/dev.c:5955
      
      read to 0xffff888122474b50 of 8 bytes by task 8921 on cpu 1:
       skb_queue_empty include/linux/skbuff.h:1494 [inline]
       __skb_recv_udp+0x18d/0x500 net/ipv4/udp.c:1653
       udp_recvmsg+0xe1/0xb10 net/ipv4/udp.c:1712
       inet_recvmsg+0xbb/0x250 net/ipv4/af_inet.c:838
       sock_recvmsg_nosec+0x5c/0x70 net/socket.c:871
       ___sys_recvmsg+0x1a0/0x3e0 net/socket.c:2480
       do_recvmmsg+0x19a/0x5c0 net/socket.c:2601
       __sys_recvmmsg+0x1ef/0x200 net/socket.c:2680
       __do_sys_recvmmsg net/socket.c:2703 [inline]
       __se_sys_recvmmsg net/socket.c:2696 [inline]
       __x64_sys_recvmmsg+0x89/0xb0 net/socket.c:2696
       do_syscall_64+0xcc/0x370 arch/x86/entry/common.c:290
       entry_SYSCALL_64_after_hwframe+0x44/0xa9
      
      Reported by Kernel Concurrency Sanitizer on:
      CPU: 1 PID: 8921 Comm: syz-executor.4 Not tainted 5.4.0-rc3+ #0
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Reported-by: Nsyzbot <syzkaller@googlegroups.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      afa1f5e9
    • E
      net: add skb_queue_empty_lockless() · d5ac4232
      Eric Dumazet 提交于
      [ Upstream commit d7d16a89350ab263484c0aa2b523dd3a234e4a80 ]
      
      Some paths call skb_queue_empty() without holding
      the queue lock. We must use a barrier in order
      to not let the compiler do strange things, and avoid
      KCSAN splats.
      
      Adding a barrier in skb_queue_empty() might be overkill,
      I prefer adding a new helper to clearly identify
      points where the callers might be lockless. This might
      help us finding real bugs.
      
      The corresponding WRITE_ONCE() should add zero cost
      for current compilers.
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d5ac4232
    • X
      vxlan: check tun_info options_len properly · 83532eb4
      Xin Long 提交于
      [ Upstream commit eadf52cf1852196a1363044dcda22fa5d7f296f7 ]
      
      This patch is to improve the tun_info options_len by dropping
      the skb when TUNNEL_VXLAN_OPT is set but options_len is less
      than vxlan_metadata. This can void a potential out-of-bounds
      access on ip_tun_info.
      
      Fixes: ee122c79 ("vxlan: Flow based tunneling")
      Signed-off-by: NXin Long <lucien.xin@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      83532eb4
    • E
      udp: fix data-race in udp_set_dev_scratch() · a8a5adbb
      Eric Dumazet 提交于
      [ Upstream commit a793183caa9afae907a0d7ddd2ffd57329369bf5 ]
      
      KCSAN reported a data-race in udp_set_dev_scratch() [1]
      
      The issue here is that we must not write over skb fields
      if skb is shared. A similar issue has been fixed in commit
      89c22d8c ("net: Fix skb csum races when peeking")
      
      While we are at it, use a helper only dealing with
      udp_skb_scratch(skb)->csum_unnecessary, as this allows
      udp_set_dev_scratch() to be called once and thus inlined.
      
      [1]
      BUG: KCSAN: data-race in udp_set_dev_scratch / udpv6_recvmsg
      
      write to 0xffff888120278317 of 1 bytes by task 10411 on cpu 1:
       udp_set_dev_scratch+0xea/0x200 net/ipv4/udp.c:1308
       __first_packet_length+0x147/0x420 net/ipv4/udp.c:1556
       first_packet_length+0x68/0x2a0 net/ipv4/udp.c:1579
       udp_poll+0xea/0x110 net/ipv4/udp.c:2720
       sock_poll+0xed/0x250 net/socket.c:1256
       vfs_poll include/linux/poll.h:90 [inline]
       do_select+0x7d0/0x1020 fs/select.c:534
       core_sys_select+0x381/0x550 fs/select.c:677
       do_pselect.constprop.0+0x11d/0x160 fs/select.c:759
       __do_sys_pselect6 fs/select.c:784 [inline]
       __se_sys_pselect6 fs/select.c:769 [inline]
       __x64_sys_pselect6+0x12e/0x170 fs/select.c:769
       do_syscall_64+0xcc/0x370 arch/x86/entry/common.c:290
       entry_SYSCALL_64_after_hwframe+0x44/0xa9
      
      read to 0xffff888120278317 of 1 bytes by task 10413 on cpu 0:
       udp_skb_csum_unnecessary include/net/udp.h:358 [inline]
       udpv6_recvmsg+0x43e/0xe90 net/ipv6/udp.c:310
       inet6_recvmsg+0xbb/0x240 net/ipv6/af_inet6.c:592
       sock_recvmsg_nosec+0x5c/0x70 net/socket.c:871
       ___sys_recvmsg+0x1a0/0x3e0 net/socket.c:2480
       do_recvmmsg+0x19a/0x5c0 net/socket.c:2601
       __sys_recvmmsg+0x1ef/0x200 net/socket.c:2680
       __do_sys_recvmmsg net/socket.c:2703 [inline]
       __se_sys_recvmmsg net/socket.c:2696 [inline]
       __x64_sys_recvmmsg+0x89/0xb0 net/socket.c:2696
       do_syscall_64+0xcc/0x370 arch/x86/entry/common.c:290
       entry_SYSCALL_64_after_hwframe+0x44/0xa9
      
      Reported by Kernel Concurrency Sanitizer on:
      CPU: 0 PID: 10413 Comm: syz-executor.0 Not tainted 5.4.0-rc3+ #0
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
      
      Fixes: 2276f58a ("udp: use a separate rx queue for packet reception")
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Reported-by: Nsyzbot <syzkaller@googlegroups.com>
      Cc: Paolo Abeni <pabeni@redhat.com>
      Reviewed-by: NPaolo Abeni <pabeni@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a8a5adbb
    • W
      selftests: net: reuseport_dualstack: fix uninitalized parameter · 12fab163
      Wei Wang 提交于
      [ Upstream commit d64479a3e3f9924074ca7b50bd72fa5211dca9c1 ]
      
      This test reports EINVAL for getsockopt(SOL_SOCKET, SO_DOMAIN)
      occasionally due to the uninitialized length parameter.
      Initialize it to fix this, and also use int for "test_family" to comply
      with the API standard.
      
      Fixes: d6a61f80 ("soreuseport: test mixed v4/v6 sockets")
      Reported-by: NMaciej Żenczykowski <maze@google.com>
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NWei Wang <weiwan@google.com>
      Cc: Craig Gallek <cgallek@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      12fab163
    • Z
      net: Zeroing the structure ethtool_wolinfo in ethtool_get_wol() · 321c9915
      zhanglin 提交于
      [ Upstream commit 5ff223e86f5addbfae26419cbb5d61d98f6fbf7d ]
      
      memset() the structure ethtool_wolinfo that has padded bytes
      but the padded bytes have not been zeroed out.
      Signed-off-by: Nzhanglin <zhang.lin16@zte.com.cn>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      321c9915
    • D
      net: usb: lan78xx: Disable interrupts before calling generic_handle_irq() · 9da271c1
      Daniel Wagner 提交于
      [ Upstream commit 0a29ac5bd3a988dc151c8d26910dec2557421f64 ]
      
      lan78xx_status() will run with interrupts enabled due to the change in
      ed194d136769 ("usb: core: remove local_irq_save() around ->complete()
      handler"). generic_handle_irq() expects to be run with IRQs disabled.
      
      [    4.886203] 000: irq 79 handler irq_default_primary_handler+0x0/0x8 enabled interrupts
      [    4.886243] 000: WARNING: CPU: 0 PID: 0 at kernel/irq/handle.c:152 __handle_irq_event_percpu+0x154/0x168
      [    4.896294] 000: Modules linked in:
      [    4.896301] 000: CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.3.6 #39
      [    4.896310] 000: Hardware name: Raspberry Pi 3 Model B+ (DT)
      [    4.896315] 000: pstate: 60000005 (nZCv daif -PAN -UAO)
      [    4.896321] 000: pc : __handle_irq_event_percpu+0x154/0x168
      [    4.896331] 000: lr : __handle_irq_event_percpu+0x154/0x168
      [    4.896339] 000: sp : ffff000010003cc0
      [    4.896346] 000: x29: ffff000010003cc0 x28: 0000000000000060
      [    4.896355] 000: x27: ffff000011021980 x26: ffff00001189c72b
      [    4.896364] 000: x25: ffff000011702bc0 x24: ffff800036d6e400
      [    4.896373] 000: x23: 000000000000004f x22: ffff000010003d64
      [    4.896381] 000: x21: 0000000000000000 x20: 0000000000000002
      [    4.896390] 000: x19: ffff8000371c8480 x18: 0000000000000060
      [    4.896398] 000: x17: 0000000000000000 x16: 00000000000000eb
      [    4.896406] 000: x15: ffff000011712d18 x14: 7265746e69206465
      [    4.896414] 000: x13: ffff000010003ba0 x12: ffff000011712df0
      [    4.896422] 000: x11: 0000000000000001 x10: ffff000011712e08
      [    4.896430] 000: x9 : 0000000000000001 x8 : 000000000003c920
      [    4.896437] 000: x7 : ffff0000118cc410 x6 : ffff0000118c7f00
      [    4.896445] 000: x5 : 000000000003c920 x4 : 0000000000004510
      [    4.896453] 000: x3 : ffff000011712dc8 x2 : 0000000000000000
      [    4.896461] 000: x1 : 73a3f67df94c1500 x0 : 0000000000000000
      [    4.896466] 000: Call trace:
      [    4.896471] 000:  __handle_irq_event_percpu+0x154/0x168
      [    4.896481] 000:  handle_irq_event_percpu+0x50/0xb0
      [    4.896489] 000:  handle_irq_event+0x40/0x98
      [    4.896497] 000:  handle_simple_irq+0xa4/0xf0
      [    4.896505] 000:  generic_handle_irq+0x24/0x38
      [    4.896513] 000:  intr_complete+0xb0/0xe0
      [    4.896525] 000:  __usb_hcd_giveback_urb+0x58/0xd8
      [    4.896533] 000:  usb_giveback_urb_bh+0xd0/0x170
      [    4.896539] 000:  tasklet_action_common.isra.0+0x9c/0x128
      [    4.896549] 000:  tasklet_hi_action+0x24/0x30
      [    4.896556] 000:  __do_softirq+0x120/0x23c
      [    4.896564] 000:  irq_exit+0xb8/0xd8
      [    4.896571] 000:  __handle_domain_irq+0x64/0xb8
      [    4.896579] 000:  bcm2836_arm_irqchip_handle_irq+0x60/0xc0
      [    4.896586] 000:  el1_irq+0xb8/0x140
      [    4.896592] 000:  arch_cpu_idle+0x10/0x18
      [    4.896601] 000:  do_idle+0x200/0x280
      [    4.896608] 000:  cpu_startup_entry+0x20/0x28
      [    4.896615] 000:  rest_init+0xb4/0xc0
      [    4.896623] 000:  arch_call_rest_init+0xc/0x14
      [    4.896632] 000:  start_kernel+0x454/0x480
      
      Fixes: ed194d136769 ("usb: core: remove local_irq_save() around ->complete() handler")
      Cc: Woojung Huh <woojung.huh@microchip.com>
      Cc: Marc Zyngier <maz@kernel.org>
      Cc: Andrew Lunn <andrew@lunn.ch>
      Cc: Stefan Wahren <wahrenst@gmx.net>
      Cc: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
      Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: David Miller <davem@davemloft.net>
      Signed-off-by: NDaniel Wagner <dwagner@suse.de>
      Tested-by: NStefan Wahren <wahrenst@gmx.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9da271c1
    • G
      netns: fix GFP flags in rtnl_net_notifyid() · 40400fdd
      Guillaume Nault 提交于
      [ Upstream commit d4e4fdf9e4a27c87edb79b1478955075be141f67 ]
      
      In rtnl_net_notifyid(), we certainly can't pass a null GFP flag to
      rtnl_notify(). A GFP_KERNEL flag would be fine in most circumstances,
      but there are a few paths calling rtnl_net_notifyid() from atomic
      context or from RCU critical sections. The later also precludes the use
      of gfp_any() as it wouldn't detect the RCU case. Also, the nlmsg_new()
      call is wrong too, as it uses GFP_KERNEL unconditionally.
      
      Therefore, we need to pass the GFP flags as parameter and propagate it
      through function calls until the proper flags can be determined.
      
      In most cases, GFP_KERNEL is fine. The exceptions are:
        * openvswitch: ovs_vport_cmd_get() and ovs_vport_cmd_dump()
          indirectly call rtnl_net_notifyid() from RCU critical section,
      
        * rtnetlink: rtmsg_ifinfo_build_skb() already receives GFP flags as
          parameter.
      
      Also, in ovs_vport_cmd_build_info(), let's change the GFP flags used
      by nlmsg_new(). The function is allowed to sleep, so better make the
      flags consistent with the ones used in the following
      ovs_vport_cmd_fill_info() call.
      
      Found by code inspection.
      
      Fixes: 9a963454 ("netns: notify netns id events")
      Signed-off-by: NGuillaume Nault <gnault@redhat.com>
      Acked-by: NNicolas Dichtel <nicolas.dichtel@6wind.com>
      Acked-by: NPravin B Shelar <pshelar@ovn.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      40400fdd
    • E
      net/mlx4_core: Dynamically set guaranteed amount of counters per VF · 1d72dbb4
      Eran Ben Elisha 提交于
      [ Upstream commit e19868efea0c103f23b4b7e986fd0a703822111f ]
      
      Prior to this patch, the amount of counters guaranteed per VF in the
      resource tracker was MLX4_VF_COUNTERS_PER_PORT * MLX4_MAX_PORTS. It was
      set regardless if the VF was single or dual port.
      This caused several VFs to have no guaranteed counters although the
      system could satisfy their request.
      
      The fix is to dynamically guarantee counters, based on each VF
      specification.
      
      Fixes: 9de92c60 ("net/mlx4_core: Adjust counter grant policy in the resource tracker")
      Signed-off-by: NEran Ben Elisha <eranbe@mellanox.com>
      Signed-off-by: NJack Morgenstein <jackm@dev.mellanox.co.il>
      Signed-off-by: NTariq Toukan <tariqt@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1d72dbb4