1. 15 Nov, 2019 18 commits
  2. 14 Nov, 2019 3 commits
    • David S. Miller's avatar
      Merge tag 'linux-can-fixes-for-5.4-20191114' of... · d15a5020
      David S. Miller authored
      Merge tag 'linux-can-fixes-for-5.4-20191114' of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can
      Marc Kleine-Budde says:
      pull-request: can 2019-11-14
      here another pull request for net/master consisting of one patch (including my S-o-b).
      Jouni Hogander's patch fixes a memory leak found by the syzbot in the slcan
      driver's error path.
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    • David S. Miller's avatar
      Merge tag 'wireless-drivers-2019-11-14' of... · bb9b5441
      David S. Miller authored
      Merge tag 'wireless-drivers-2019-11-14' of git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers
      Kalle Valo says:
      wireless-drivers fixes for v5.4
      Hopefully last fixes for v5.4, only one iwlwifi fix this time.
      * fix A-MSDU data corruption when using CCMP/GCMP ciphers
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    • Jouni Hogander's avatar
      slcan: Fix memory leak in error path · ed50e160
      Jouni Hogander authored
      This patch is fixing memory leak reported by Syzkaller:
      BUG: memory leak unreferenced object 0xffff888067f65500 (size 4096):
        comm "syz-executor043", pid 454, jiffies 4294759719 (age 11.930s)
        hex dump (first 32 bytes):
          73 6c 63 61 6e 30 00 00 00 00 00 00 00 00 00 00 slcan0..........
          00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
          [<00000000a06eec0d>] __kmalloc+0x18b/0x2c0
          [<0000000083306e66>] kvmalloc_node+0x3a/0xc0
          [<000000006ac27f87>] alloc_netdev_mqs+0x17a/0x1080
          [<0000000061a996c9>] slcan_open+0x3ae/0x9a0
          [<000000001226f0f9>] tty_ldisc_open.isra.1+0x76/0xc0
          [<0000000019289631>] tty_set_ldisc+0x28c/0x5f0
          [<000000004de5a617>] tty_ioctl+0x48d/0x1590
          [<00000000daef496f>] do_vfs_ioctl+0x1c7/0x1510
          [<0000000059068dbc>] ksys_ioctl+0x99/0xb0
          [<000000009a6eb334>] __x64_sys_ioctl+0x78/0xb0
          [<0000000053d0332e>] do_syscall_64+0x16f/0x580
          [<0000000021b83b99>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
          [<000000008ea75434>] 0xffffffffffffffff
      Cc: Wolfgang Grandegger <wg@grandegger.com>
      Cc: Marc Kleine-Budde <mkl@pengutronix.de>
      Cc: Lukas Bulwahn <lukas.bulwahn@gmail.com>
      Signed-off-by: default avatarJouni Hogander <jouni.hogander@unikie.com>
      Signed-off-by: default avatarMarc Kleine-Budde <mkl@pengutronix.de>
  3. 13 Nov, 2019 15 commits
  4. 12 Nov, 2019 4 commits
    • Ursula Braun's avatar
      net/smc: fix refcount non-blocking connect() -part 2 · 6d6dd528
      Ursula Braun authored
      If an SMC socket is immediately terminated after a non-blocking connect()
      has been called, a memory leak is possible.
      Due to the sock_hold move in
      commit 301428ea
       ("net/smc: fix refcounting for non-blocking connect()")
      an extra sock_put() is needed in smc_connect_work(), if the internal
      TCP socket is aborted and cancels the sk_stream_wait_connect() of the
      connect worker.
      Reported-by: default avatar <syzbot+4b73ad6fc767e576e275@syzkaller.appspotmail.com>
      Fixes: 301428ea
       ("net/smc: fix refcounting for non-blocking connect()")
      Signed-off-by: default avatarUrsula Braun <ubraun@linux.ibm.com>
      Signed-off-by: default avatarKarsten Graul <kgraul@linux.ibm.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    • Xiaodong Xu's avatar
      xfrm: release device reference for invalid state · 4944a4b1
      Xiaodong Xu authored
      An ESP packet could be decrypted in async mode if the input handler for
      this packet returns -EINPROGRESS in xfrm_input(). At this moment the device
      reference in skb is held. Later xfrm_input() will be invoked again to
      resume the processing.
      If the transform state is still valid it would continue to release the
      device reference and there won't be a problem; however if the transform
      state is not valid when async resumption happens, the packet will be
      dropped while the device reference is still being held.
      When the device is deleted for some reason and the reference to this
      device is not properly released, the kernel will keep logging like:
      unregister_netdevice: waiting for ppp2 to become free. Usage count = 1
      The issue is observed when running IPsec traffic over a PPPoE device based
      on a bridge interface. By terminating the PPPoE connection on the server
      end for multiple times, the PPPoE device on the client side will eventually
      get stuck on the above warning message.
      This patch will check the async mode first and continue to release device
      reference in async resumption, before it is dropped due to invalid state.
      v2: Do not assign address family from outer_mode in the transform if the
      state is invalid
      v3: Release device reference in the error path instead of jumping to resume
      Fixes: 4ce3dbe3
       ("xfrm: Fix xfrm_input() to verify state is valid when (encap_type < 0)")
      Signed-off-by: default avatarXiaodong Xu <stid.smth@gmail.com>
      Reported-by: default avatarBo Chen <chenborfc@163.com>
      Tested-by: default avatarBo Chen <chenborfc@163.com>
      Signed-off-by: default avatarSteffen Klassert <steffen.klassert@secunet.com>
    • YueHaibing's avatar
      mdio_bus: Fix PTR_ERR applied after initialization to constant · 1d463956
      YueHaibing authored
      Fix coccinelle warning:
      ./drivers/net/phy/mdio_bus.c:67:5-12: ERROR: PTR_ERR applied after initialization to constant on line 62
      ./drivers/net/phy/mdio_bus.c:68:5-12: ERROR: PTR_ERR applied after initialization to constant on line 62
      Fix this by using IS_ERR before PTR_ERR
      Reported-by: default avatarHulk Robot <hulkci@huawei.com>
      Fixes: 71dd6c0d
       ("net: phy: add support for reset-controller")
      Signed-off-by: default avatarYueHaibing <yuehaibing@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    • Stephan Gerhold's avatar
      NFC: nxp-nci: Fix NULL pointer dereference after I2C communication error · a71a29f5
      Stephan Gerhold authored
      I2C communication errors (-EREMOTEIO) during the IRQ handler of nxp-nci
      result in a NULL pointer dereference at the moment:
          BUG: kernel NULL pointer dereference, address: 0000000000000000
          Oops: 0002 [#1] PREEMPT SMP NOPTI
          CPU: 1 PID: 355 Comm: irq/137-nxp-nci Not tainted 5.4.0-rc6 #1
          RIP: 0010:skb_queue_tail+0x25/0x50
          Call Trace:
           nci_recv_frame+0x36/0x90 [nci]
           nxp_nci_i2c_irq_thread_fn+0xd1/0x285 [nxp_nci_i2c]
           ? preempt_count_add+0x68/0xa0
           ? irq_forced_thread_fn+0x80/0x80
           ? wake_threads_waitq+0x30/0x30
           ? irq_thread_check_affinity+0xd0/0xd0
           ? kthread_park+0x90/0x90
      Afterward the kernel must be rebooted to work properly again.
      This happens because it attempts to call nci_recv_frame() with skb == NULL.
      However, unlike nxp_nci_fw_recv_frame(), nci_recv_frame() does not have any
      NULL checks for skb, causing the NULL pointer dereference.
      Change the code to call only nxp_nci_fw_recv_frame() in case of an error.
      Make sure to log it so it is obvious that a communication error occurred.
      The error above then becomes:
          nxp-nci_i2c i2c-NXP1001:00: NFC: Read failed with error -121
          nci: __nci_request: wait_for_completion_interruptible_timeout failed 0
          nxp-nci_i2c i2c-NXP1001:00: NFC: Read failed with error -121
      Fixes: 6be88670
       ("NFC: nxp-nci_i2c: Add I2C support to NXP NCI driver")
      Signed-off-by: default avatarStephan Gerhold <stephan@gerhold.net>
      Reviewed-by: default avatarAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>