1. 20 11月, 2020 2 次提交
  2. 19 11月, 2020 2 次提交
  3. 18 11月, 2020 4 次提交
  4. 17 11月, 2020 3 次提交
  5. 16 11月, 2020 2 次提交
  6. 15 11月, 2020 4 次提交
  7. 14 11月, 2020 2 次提交
  8. 13 11月, 2020 6 次提交
    • J
      mac80211: free sta in sta_info_insert_finish() on errors · 7bc40aed
      Johannes Berg 提交于
      If sta_info_insert_finish() fails, we currently keep the station
      around and free it only in the caller, but there's only one such
      caller and it always frees it immediately.
      
      As syzbot found, another consequence of this split is that we can
      put things that sleep only into __cleanup_single_sta() and not in
      sta_info_free(), but this is the only place that requires such of
      sta_info_free() now.
      
      Change this to free the station in sta_info_insert_finish(), in
      which case we can still sleep. This will also let us unify the
      cleanup code later.
      
      Cc: stable@vger.kernel.org
      Fixes: dcd479e1 ("mac80211: always wind down STA state")
      Reported-by: syzbot+32c6c38c4812d22f2f0b@syzkaller.appspotmail.com
      Reported-by: syzbot+4c81fe92e372d26c4246@syzkaller.appspotmail.com
      Reported-by: syzbot+6a7fe9faf0d1d61bc24a@syzkaller.appspotmail.com
      Reported-by: syzbot+abed06851c5ffe010921@syzkaller.appspotmail.com
      Reported-by: syzbot+b7aeb9318541a1c709f1@syzkaller.appspotmail.com
      Reported-by: syzbot+d5a9416c6cafe53b5dd0@syzkaller.appspotmail.com
      Link: https://lore.kernel.org/r/20201112112201.ee6b397b9453.I9c31d667a0ea2151441cc64ed6613d36c18a48e0@changeidSigned-off-by: NJohannes Berg <johannes.berg@intel.com>
      7bc40aed
    • X
      net: x25: Increase refcnt of "struct x25_neigh" in x25_rx_call_request · 4ee18c17
      Xie He 提交于
      The x25_disconnect function in x25_subr.c would decrease the refcount of
      "x25->neighbour" (struct x25_neigh) and reset this pointer to NULL.
      
      However, the x25_rx_call_request function in af_x25.c, which is called
      when we receive a connection request, does not increase the refcount when
      it assigns the pointer.
      
      Fix this issue by increasing the refcount of "struct x25_neigh" in
      x25_rx_call_request.
      
      This patch fixes frequent kernel crashes when using AF_X25 sockets.
      
      Fixes: 4becb7ee ("net/x25: Fix x25_neigh refcnt leak when x25 disconnect")
      Cc: Martin Schiller <ms@dev.tdt.de>
      Signed-off-by: NXie He <xie.he.0141@gmail.com>
      Link: https://lore.kernel.org/r/20201112103506.5875-1-xie.he.0141@gmail.comSigned-off-by: NJakub Kicinski <kuba@kernel.org>
      4ee18c17
    • J
      net/ncsi: Fix netlink registration · 1922a46b
      Joel Stanley 提交于
      If a user unbinds and re-binds a NC-SI aware driver the kernel will
      attempt to register the netlink interface at runtime. The structure is
      marked __ro_after_init so registration fails spectacularly at this point.
      
       # echo 1e660000.ethernet > /sys/bus/platform/drivers/ftgmac100/unbind
       # echo 1e660000.ethernet > /sys/bus/platform/drivers/ftgmac100/bind
        ftgmac100 1e660000.ethernet: Read MAC address 52:54:00:12:34:56 from chip
        ftgmac100 1e660000.ethernet: Using NCSI interface
        8<--- cut here ---
        Unable to handle kernel paging request at virtual address 80a8f858
        pgd = 8c768dd6
        [80a8f858] *pgd=80a0841e(bad)
        Internal error: Oops: 80d [#1] SMP ARM
        CPU: 0 PID: 116 Comm: sh Not tainted 5.10.0-rc3-next-20201111-00003-gdd25b227ec1e #51
        Hardware name: Generic DT based system
        PC is at genl_register_family+0x1f8/0x6d4
        LR is at 0xff26ffff
        pc : [<8073f930>]    lr : [<ff26ffff>]    psr: 20000153
        sp : 8553bc80  ip : 81406244  fp : 8553bd04
        r10: 8085d12c  r9 : 80a8f73c  r8 : 85739000
        r7 : 00000017  r6 : 80a8f860  r5 : 80c8ab98  r4 : 80a8f858
        r3 : 00000000  r2 : 00000000  r1 : 81406130  r0 : 00000017
        Flags: nzCv  IRQs on  FIQs off  Mode SVC_32  ISA ARM  Segment none
        Control: 00c5387d  Table: 85524008  DAC: 00000051
        Process sh (pid: 116, stack limit = 0x1f1988d6)
       ...
        Backtrace:
        [<8073f738>] (genl_register_family) from [<80860ac0>] (ncsi_init_netlink+0x20/0x48)
         r10:8085d12c r9:80c8fb0c r8:85739000 r7:00000000 r6:81218000 r5:85739000
         r4:8121c000
        [<80860aa0>] (ncsi_init_netlink) from [<8085d740>] (ncsi_register_dev+0x1b0/0x210)
         r5:8121c400 r4:8121c000
        [<8085d590>] (ncsi_register_dev) from [<805a8060>] (ftgmac100_probe+0x6e0/0x778)
         r10:00000004 r9:80950228 r8:8115bc10 r7:8115ab00 r6:9eae2c24 r5:813b6f88
         r4:85739000
        [<805a7980>] (ftgmac100_probe) from [<805355ec>] (platform_drv_probe+0x58/0xa8)
         r9:80c76bb0 r8:00000000 r7:80cd4974 r6:80c76bb0 r5:8115bc10 r4:00000000
        [<80535594>] (platform_drv_probe) from [<80532d58>] (really_probe+0x204/0x514)
         r7:80cd4974 r6:00000000 r5:80cd4868 r4:8115bc10
      
      Jakub pointed out that ncsi_register_dev is obviously broken, because
      there is only one family so it would never work if there was more than
      one ncsi netdev.
      
      Fix the crash by registering the netlink family once on boot, and drop
      the code to unregister it.
      
      Fixes: 955dc68c ("net/ncsi: Add generic netlink family")
      Signed-off-by: NJoel Stanley <joel@jms.id.au>
      Reviewed-by: NSamuel Mendoza-Jonas <sam@mendozajonas.com>
      Link: https://lore.kernel.org/r/20201112061210.914621-1-joel@jms.id.auSigned-off-by: NJakub Kicinski <kuba@kernel.org>
      1922a46b
    • A
      net: udp: fix IP header access and skb lookup on Fast/frag0 UDP GRO · 55e72988
      Alexander Lobakin 提交于
      udp{4,6}_lib_lookup_skb() use ip{,v6}_hdr() to get IP header of the
      packet. While it's probably OK for non-frag0 paths, this helpers
      will also point to junk on Fast/frag0 GRO when all headers are
      located in frags. As a result, sk/skb lookup may fail or give wrong
      results. To support both GRO modes, skb_gro_network_header() might
      be used. To not modify original functions, add private versions of
      udp{4,6}_lib_lookup_skb() only to perform correct sk lookups on GRO.
      
      Present since the introduction of "application-level" UDP GRO
      in 4.7-rc1.
      
      Misc: replace totally unneeded ternaries with plain ifs.
      
      Fixes: a6024562 ("udp: Add GRO functions to UDP socket")
      Suggested-by: NWillem de Bruijn <willemb@google.com>
      Cc: Eric Dumazet <edumazet@google.com>
      Signed-off-by: NAlexander Lobakin <alobakin@pm.me>
      Acked-by: NWillem de Bruijn <willemb@google.com>
      Signed-off-by: NJakub Kicinski <kuba@kernel.org>
      55e72988
    • A
      net: udp: fix UDP header access on Fast/frag0 UDP GRO · 4b1a8628
      Alexander Lobakin 提交于
      UDP GRO uses udp_hdr(skb) in its .gro_receive() callback. While it's
      probably OK for non-frag0 paths (when all headers or even the entire
      frame are already in skb head), this inline points to junk when
      using Fast GRO (napi_gro_frags() or napi_gro_receive() with only
      Ethernet header in skb head and all the rest in the frags) and breaks
      GRO packet compilation and the packet flow itself.
      To support both modes, skb_gro_header_fast() + skb_gro_header_slow()
      are typically used. UDP even has an inline helper that makes use of
      them, udp_gro_udphdr(). Use that instead of troublemaking udp_hdr()
      to get rid of the out-of-order delivers.
      
      Present since the introduction of plain UDP GRO in 5.0-rc1.
      
      Fixes: e20cf8d3 ("udp: implement GRO for plain UDP sockets.")
      Cc: Eric Dumazet <edumazet@google.com>
      Signed-off-by: NAlexander Lobakin <alobakin@pm.me>
      Acked-by: NWillem de Bruijn <willemb@google.com>
      Signed-off-by: NJakub Kicinski <kuba@kernel.org>
      4b1a8628
    • P
      devlink: Avoid overwriting port attributes of registered port · 9f73bd1c
      Parav Pandit 提交于
      Cited commit in fixes tag overwrites the port attributes for the
      registered port.
      
      Avoid such error by checking registered flag before setting attributes.
      
      Fixes: 71ad8d55 ("devlink: Replace devlink_port_attrs_set parameters with a struct")
      Signed-off-by: NParav Pandit <parav@nvidia.com>
      Reviewed-by: NJiri Pirko <jiri@nvidia.com>
      Link: https://lore.kernel.org/r/20201111034744.35554-1-parav@nvidia.comSigned-off-by: NJakub Kicinski <kuba@kernel.org>
      9f73bd1c
  9. 12 11月, 2020 6 次提交
    • F
      mac80211: minstrel: fix tx status processing corner case · b2911a84
      Felix Fietkau 提交于
      Some drivers fill the status rate list without setting the rate index after
      the final rate to -1. minstrel_ht already deals with this, but minstrel
      doesn't, which causes it to get stuck at the lowest rate on these drivers.
      
      Fix this by checking the count as well.
      
      Cc: stable@vger.kernel.org
      Fixes: cccf129f ("mac80211: add the 'minstrel' rate control algorithm")
      Signed-off-by: NFelix Fietkau <nbd@nbd.name>
      Link: https://lore.kernel.org/r/20201111183359.43528-3-nbd@nbd.nameSigned-off-by: NJohannes Berg <johannes.berg@intel.com>
      b2911a84
    • F
      mac80211: minstrel: remove deferred sampling code · 4fe40b8e
      Felix Fietkau 提交于
      Deferring sampling attempts to the second stage has some bad interactions
      with drivers that process the rate table in hardware and use the probe flag
      to indicate probing packets (e.g. most mt76 drivers). On affected drivers
      it can lead to probing not working at all.
      
      If the link conditions turn worse, it might not be such a good idea to
      do a lot of sampling for lower rates in this case.
      
      Fix this by simply skipping the sample attempt instead of deferring it,
      but keep the checks that would allow it to be sampled if it was skipped
      too often, but only if it has less than 95% success probability.
      
      Also ensure that IEEE80211_TX_CTL_RATE_CTRL_PROBE is set for all probing
      packets.
      
      Cc: stable@vger.kernel.org
      Fixes: cccf129f ("mac80211: add the 'minstrel' rate control algorithm")
      Signed-off-by: NFelix Fietkau <nbd@nbd.name>
      Link: https://lore.kernel.org/r/20201111183359.43528-2-nbd@nbd.nameSigned-off-by: NJohannes Berg <johannes.berg@intel.com>
      4fe40b8e
    • F
      mac80211: fix memory leak on filtered powersave frames · 1d182885
      Felix Fietkau 提交于
      After the status rework, ieee80211_tx_status_ext is leaking un-acknowledged
      packets for stations in powersave mode.
      To fix this, move the code handling those packets from __ieee80211_tx_status
      into ieee80211_tx_status_ext
      Reported-by: NTobias Waldvogel <tobias.waldvogel@gmail.com>
      Fixes: 3318111c ("mac80211: reduce duplication in tx status functions")
      Signed-off-by: NFelix Fietkau <nbd@nbd.name>
      Link: https://lore.kernel.org/r/20201111183359.43528-1-nbd@nbd.nameSigned-off-by: NJohannes Berg <johannes.berg@intel.com>
      1d182885
    • C
      rfkill: Fix use-after-free in rfkill_resume() · 94e2bd0b
      Claire Chang 提交于
      If a device is getting removed or reprobed during resume, use-after-free
      might happen. For example, h5_btrtl_resume() schedules a work queue for
      device reprobing, which of course requires removal first.
      
      If the removal happens in parallel with the device_resume() and wins the
      race to acquire device_lock(), removal may remove the device from the PM
      lists and all, but device_resume() is already running and will continue
      when the lock can be acquired, thus calling rfkill_resume().
      
      During this, if rfkill_set_block() is then called after the corresponding
      *_unregister() and kfree() are called, there will be an use-after-free
      in hci_rfkill_set_block():
      
      BUG: KASAN: use-after-free in hci_rfkill_set_block+0x58/0xc0 [bluetooth]
      ...
      Call trace:
        dump_backtrace+0x0/0x154
        show_stack+0x20/0x2c
        dump_stack+0xbc/0x12c
        print_address_description+0x88/0x4b0
        __kasan_report+0x144/0x168
        kasan_report+0x10/0x18
        check_memory_region+0x19c/0x1ac
        __kasan_check_write+0x18/0x24
        hci_rfkill_set_block+0x58/0xc0 [bluetooth]
        rfkill_set_block+0x9c/0x120
        rfkill_resume+0x34/0x70
        dpm_run_callback+0xf0/0x1f4
        device_resume+0x210/0x22c
      
      Fix this by checking rfkill->registered in rfkill_resume(). device_del()
      in rfkill_unregister() requires device_lock() and the whole rfkill_resume()
      is also protected by the same lock via device_resume(), we can make sure
      either the rfkill->registered is false before rfkill_resume() starts or the
      rfkill device won't be unregistered before rfkill_resume() returns.
      
      As async_resume() holds a reference to the device, at this level there can
      be no use-after-free; only in the user that doesn't expect this scenario.
      
      Fixes: 8589086f ("Bluetooth: hci_h5: Turn off RTL8723BS on suspend, reprobe on resume")
      Signed-off-by: NClaire Chang <tientzu@chromium.org>
      Link: https://lore.kernel.org/r/20201110084908.219088-1-tientzu@chromium.org
      [edit commit message for clarity and add more info provided later]
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      94e2bd0b
    • M
      net/x25: Fix null-ptr-deref in x25_connect · 36118230
      Martin Schiller 提交于
      This fixes a regression for blocking connects introduced by commit
      4becb7ee ("net/x25: Fix x25_neigh refcnt leak when x25 disconnect").
      
      The x25->neighbour is already set to "NULL" by x25_disconnect() now,
      while a blocking connect is waiting in
      x25_wait_for_connection_establishment(). Therefore x25->neighbour must
      not be accessed here again and x25->state is also already set to
      X25_STATE_0 by x25_disconnect().
      
      Fixes: 4becb7ee ("net/x25: Fix x25_neigh refcnt leak when x25 disconnect")
      Signed-off-by: NMartin Schiller <ms@dev.tdt.de>
      Reviewed-by: NXie He <xie.he.0141@gmail.com>
      Link: https://lore.kernel.org/r/20201109065449.9014-1-ms@dev.tdt.deSigned-off-by: NJakub Kicinski <kuba@kernel.org>
      36118230
    • W
      tipc: fix memory leak in tipc_topsrv_start() · fa6882c6
      Wang Hai 提交于
      kmemleak report a memory leak as follows:
      
      unreferenced object 0xffff88810a596800 (size 512):
        comm "ip", pid 21558, jiffies 4297568990 (age 112.120s)
        hex dump (first 32 bytes):
          00 00 00 00 ad 4e ad de ff ff ff ff 00 00 00 00  .....N..........
          ff ff ff ff ff ff ff ff 00 83 60 b0 ff ff ff ff  ..........`.....
        backtrace:
          [<0000000022bbe21f>] tipc_topsrv_init_net+0x1f3/0xa70
          [<00000000fe15ddf7>] ops_init+0xa8/0x3c0
          [<00000000138af6f2>] setup_net+0x2de/0x7e0
          [<000000008c6807a3>] copy_net_ns+0x27d/0x530
          [<000000006b21adbd>] create_new_namespaces+0x382/0xa30
          [<00000000bb169746>] unshare_nsproxy_namespaces+0xa1/0x1d0
          [<00000000fe2e42bc>] ksys_unshare+0x39c/0x780
          [<0000000009ba3b19>] __x64_sys_unshare+0x2d/0x40
          [<00000000614ad866>] do_syscall_64+0x56/0xa0
          [<00000000a1b5ca3c>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
      
      'srv' is malloced in tipc_topsrv_start() but not free before
      leaving from the error handling cases. We need to free it.
      
      Fixes: 5c45ab24 ("tipc: make struct tipc_server private for server.c")
      Reported-by: NHulk Robot <hulkci@huawei.com>
      Signed-off-by: NWang Hai <wanghai38@huawei.com>
      Link: https://lore.kernel.org/r/20201109140913.47370-1-wanghai38@huawei.comSigned-off-by: NJakub Kicinski <kuba@kernel.org>
      fa6882c6
  10. 11 11月, 2020 3 次提交
    • U
      net/af_iucv: fix null pointer dereference on shutdown · 4031eeaf
      Ursula Braun 提交于
      syzbot reported the following KASAN finding:
      
      BUG: KASAN: nullptr-dereference in iucv_send_ctrl+0x390/0x3f0 net/iucv/af_iucv.c:385
      Read of size 2 at addr 000000000000021e by task syz-executor907/519
      
      CPU: 0 PID: 519 Comm: syz-executor907 Not tainted 5.9.0-syzkaller-07043-gbcf9877ad213 #0
      Hardware name: IBM 3906 M04 701 (KVM/Linux)
      Call Trace:
       [<00000000c576af60>] unwind_start arch/s390/include/asm/unwind.h:65 [inline]
       [<00000000c576af60>] show_stack+0x180/0x228 arch/s390/kernel/dumpstack.c:135
       [<00000000c9dcd1f8>] __dump_stack lib/dump_stack.c:77 [inline]
       [<00000000c9dcd1f8>] dump_stack+0x268/0x2f0 lib/dump_stack.c:118
       [<00000000c5fed016>] print_address_description.constprop.0+0x5e/0x218 mm/kasan/report.c:383
       [<00000000c5fec82a>] __kasan_report mm/kasan/report.c:517 [inline]
       [<00000000c5fec82a>] kasan_report+0x11a/0x168 mm/kasan/report.c:534
       [<00000000c98b5b60>] iucv_send_ctrl+0x390/0x3f0 net/iucv/af_iucv.c:385
       [<00000000c98b6262>] iucv_sock_shutdown+0x44a/0x4c0 net/iucv/af_iucv.c:1457
       [<00000000c89d3a54>] __sys_shutdown+0x12c/0x1c8 net/socket.c:2204
       [<00000000c89d3b70>] __do_sys_shutdown net/socket.c:2212 [inline]
       [<00000000c89d3b70>] __s390x_sys_shutdown+0x38/0x48 net/socket.c:2210
       [<00000000c9e36eac>] system_call+0xe0/0x28c arch/s390/kernel/entry.S:415
      
      There is nothing to shutdown if a connection has never been established.
      Besides that iucv->hs_dev is not yet initialized if a socket is in
      IUCV_OPEN state and iucv->path is not yet initialized if socket is in
      IUCV_BOUND state.
      So, just skip the shutdown calls for a socket in these states.
      
      Fixes: eac3731b ("[S390]: Add AF_IUCV socket support")
      Fixes: 82492a35 ("af_iucv: add shutdown for HS transport")
      Reviewed-by: NVasily Gorbik <gor@linux.ibm.com>
      Signed-off-by: NUrsula Braun <ubraun@linux.ibm.com>
      [jwi: correct one Fixes tag]
      Signed-off-by: NJulian Wiedmann <jwi@linux.ibm.com>
      Signed-off-by: NJakub Kicinski <kuba@kernel.org>
      4031eeaf
    • M
      net: Update window_clamp if SOCK_RCVBUF is set · 909172a1
      Mao Wenan 提交于
      When net.ipv4.tcp_syncookies=1 and syn flood is happened,
      cookie_v4_check or cookie_v6_check tries to redo what
      tcp_v4_send_synack or tcp_v6_send_synack did,
      rsk_window_clamp will be changed if SOCK_RCVBUF is set,
      which will make rcv_wscale is different, the client
      still operates with initial window scale and can overshot
      granted window, the client use the initial scale but local
      server use new scale to advertise window value, and session
      work abnormally.
      
      Fixes: e88c64f0 ("tcp: allow effective reduction of TCP's rcv-buffer via setsockopt")
      Signed-off-by: NMao Wenan <wenan.mao@linux.alibaba.com>
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Link: https://lore.kernel.org/r/1604967391-123737-1-git-send-email-wenan.mao@linux.alibaba.comSigned-off-by: NJakub Kicinski <kuba@kernel.org>
      909172a1
    • P
      netlabel: fix our progress tracking in netlbl_unlabel_staticlist() · 866358ec
      Paul Moore 提交于
      The current NetLabel code doesn't correctly keep track of the netlink
      dump state in some cases, in particular when multiple interfaces with
      large configurations are loaded.  The problem manifests itself by not
      reporting the full configuration to userspace, even though it is
      loaded and active in the kernel.  This patch fixes this by ensuring
      that the dump state is properly reset when necessary inside the
      netlbl_unlabel_staticlist() function.
      
      Fixes: 8cc44579 ("NetLabel: Introduce static network labels for unlabeled connections")
      Signed-off-by: NPaul Moore <paul@paul-moore.com>
      Link: https://lore.kernel.org/r/160484450633.3752.16512718263560813473.stgit@siflSigned-off-by: NJakub Kicinski <kuba@kernel.org>
      866358ec
  11. 10 11月, 2020 4 次提交
  12. 09 11月, 2020 1 次提交
  13. 07 11月, 2020 1 次提交