1. 25 Sep, 2019 4 commits
    • Takeshi Misawa's avatar
      ppp: Fix memory leak in ppp_write · 4c247de5
      Takeshi Misawa authored
      When ppp is closing, __ppp_xmit_process() failed to enqueue skb
      and skb allocated in ppp_write() is leaked.
      
      syzbot reported :
      BUG: memory leak
      unreferenced object 0xffff88812a17bc00 (size 224):
        comm "syz-executor673", pid 6952, jiffies 4294942888 (age 13.040s)
        hex dump (first 32 bytes):
          00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
          00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
        backtrace:
          [<00000000d110fff9>] kmemleak_alloc_recursive include/linux/kmemleak.h:43 [inline]
          [<00000000d110fff9>] slab_post_alloc_hook mm/slab.h:522 [inline]
          [<00000000d110fff9>] slab_alloc_node mm/slab.c:3262 [inline]
          [<00000000d110fff9>] kmem_cache_alloc_node+0x163/0x2f0 mm/slab.c:3574
          [<000000002d616113>] __alloc_skb+0x6e/0x210 net/core/skbuff.c:197
          [<000000000167fc45>] alloc_skb include/linux/skbuff.h:1055 [inline]
          [<000000000167fc45>] ppp_write+0x48/0x120 drivers/net/ppp/ppp_generic.c:502
          [<000000009ab42c0b>] __vfs_write+0x43/0xa0 fs/read_write.c:494
          [<00000000086b2e22>] vfs_write fs/read_write.c:558 [inline]
          [<00000000086b2e22>] vfs_write+0xee/0x210 fs/read_write.c:542
          [<00000000a2b70ef9>] ksys_write+0x7c/0x130 fs/read_write.c:611
          [<00000000ce5e0fdd>] __do_sys_write fs/read_write.c:623 [inline]
          [<00000000ce5e0fdd>] __se_sys_write fs/read_write.c:620 [inline]
          [<00000000ce5e0fdd>] __x64_sys_write+0x1e/0x30 fs/read_write.c:620
          [<00000000d9d7b370>] do_syscall_64+0x76/0x1a0 arch/x86/entry/common.c:296
          [<0000000006e6d506>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
      
      Fix this by freeing skb, if ppp is closing.
      
      Fixes: 6d066734 ("ppp: avoid loop in xmit recursion detection code")
      Reported-and-tested-by: syzbot+d9c8bf24e56416d7ce2c@syzkaller.appspotmail.com
      Signed-off-by: default avatarTakeshi Misawa <jeliantsurux@gmail.com>
      Reviewed-by: default avatarGuillaume Nault <gnault@redhat.com>
      Tested-by: default avatarGuillaume Nault <gnault@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4c247de5
    • David S. Miller's avatar
      Merge branch 'ibmvnic-serialization-fixes' · 8875cf9c
      David S. Miller authored
      Juliet Kim says:
      
      ====================
      net/ibmvnic: serialization fixes
      
      This series includes two fixes. The first improves reset code to allow
      linkwatch_event to proceed during reset. The second ensures that no more
      than one thread runs in reset at a time.
      
      v2:
      - Separate change param reset from do_reset()
      - Return IBMVNIC_OPEN_FAILED if __ibmvnic_open fails
      - Remove setting wait_for_reset to false from __ibmvnic_reset(), this
        is done in wait_for_reset()
      - Move the check for force_reset_recovery from patch 1 to patch 2
      
      v3:
      - Restore reset’s successful return in open failure case
      
      v4:
      - Change resetting flag access to atomic
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8875cf9c
    • Juliet Kim's avatar
      net/ibmvnic: prevent more than one thread from running in reset · 7ed5b31f
      Juliet Kim authored
      The current code allows more than one thread to run in reset. This can
      corrupt struct adapter data. Check adapter->resetting before performing
      a reset, if there is another reset running delay (100 msec) before trying
      again.
      Signed-off-by: default avatarJuliet Kim <julietk@linux.vnet.ibm.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      7ed5b31f
    • Juliet Kim's avatar
      net/ibmvnic: unlock rtnl_lock in reset so linkwatch_event can run · b27507bb
      Juliet Kim authored
      Commit a5681e20 ("net/ibmnvic: Fix deadlock problem in reset")
      made the change to hold the RTNL lock during a reset to avoid deadlock
      but linkwatch_event is fired during the reset and needs the RTNL lock.
      That keeps linkwatch_event process from proceeding until the reset
      is complete. The reset process cannot tolerate the linkwatch_event
      processing after reset completes, so release the RTNL lock during the
      process to allow a chance for linkwatch_event to run during reset.
      This does not guarantee that the linkwatch_event will be processed as
      soon as link state changes, but is an improvement over the current code
      where linkwatch_event processing is always delayed, which prevents
      transmissions on the device from being deactivated leading transmit
      watchdog timer to time-out.
      
      Release the RTNL lock before link state change and re-acquire after
      the link state change to allow linkwatch_event to grab the RTNL lock
      and run during the reset.
      
      Fixes: a5681e20 ("net/ibmnvic: Fix deadlock problem in reset")
      Signed-off-by: default avatarJuliet Kim <julietk@linux.vnet.ibm.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b27507bb
  2. 24 Sep, 2019 9 commits
  3. 22 Sep, 2019 12 commits
  4. 21 Sep, 2019 10 commits
  5. 20 Sep, 2019 4 commits
  6. 19 Sep, 2019 1 commit