1. 09 Mar, 2016 5 commits
    • Pavel Shilovsky's avatar
      CIFS: Fix SMB2+ interim response processing for read requests · 207600d2
      Pavel Shilovsky authored
      commit 6cc3b242 upstream.
      
      For interim responses we only need to parse a header and update
      a number credits. Now it is done for all SMB2+ command except
      SMB2_READ which is wrong. Fix this by adding such processing.
      Signed-off-by: default avatarPavel Shilovsky <pshilovsky@samba.org>
      Tested-by: default avatarShirish Pargaonkar <shirishpargaonkar@gmail.com>
      Signed-off-by: default avatarSteve French <smfrench@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      207600d2
    • Justin Maggard's avatar
      cifs: fix out-of-bounds access in lease parsing · ee86b25d
      Justin Maggard authored
      commit deb7deff upstream.
      
      When opening a file, SMB2_open() attempts to parse the lease state from the
      SMB2 CREATE Response.  However, the parsing code was not careful to ensure
      that the create contexts are not empty or invalid, which can lead to out-
      of-bounds memory access.  This can be seen easily by trying
      to read a file from a OSX 10.11 SMB3 server.  Here is sample crash output:
      
      BUG: unable to handle kernel paging request at ffff8800a1a77cc6
      IP: [<ffffffff8828a734>] SMB2_open+0x804/0x960
      PGD 8f77067 PUD 0
      Oops: 0000 [#1] SMP
      Modules linked in:
      CPU: 3 PID: 2876 Comm: cp Not tainted 4.5.0-rc3.x86_64.1+ #14
      Hardware name: NETGEAR ReadyNAS 314          /ReadyNAS 314          , BIOS 4.6.5 10/11/2012
      task: ffff880073cdc080 ti: ffff88005b31c000 task.ti: ffff88005b31c000
      RIP: 0010:[<ffffffff8828a734>]  [<ffffffff8828a734>] SMB2_open+0x804/0x960
      RSP: 0018:ffff88005b31fa08  EFLAGS: 00010282
      RAX: 0000000000000015 RBX: 0000000000000000 RCX: 0000000000000006
      RDX: 0000000000000000 RSI: 0000000000000246 RDI: ffff88007eb8c8b0
      RBP: ffff88005b31fad8 R08: 666666203d206363 R09: 6131613030383866
      R10: 3030383866666666 R11: 00000000000002b0 R12: ffff8800660fd800
      R13: ffff8800a1a77cc2 R14: 00000000424d53fe R15: ffff88005f5a28c0
      FS:  00007f7c8a2897c0(0000) GS:ffff88007eb80000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
      CR2: ffff8800a1a77cc6 CR3: 000000005b281000 CR4: 00000000000006e0
      Stack:
       ffff88005b31fa70 ffffffff88278789 00000000000001d3 ffff88005f5a2a80
       ffffffff00000003 ffff88005d029d00 ffff88006fde05a0 0000000000000000
       ffff88005b31fc78 ffff88006fde0780 ffff88005b31fb2f 0000000100000fe0
      Call Trace:
       [<ffffffff88278789>] ? cifsConvertToUTF16+0x159/0x2d0
       [<ffffffff8828cf68>] smb2_open_file+0x98/0x210
       [<ffffffff8811e80c>] ? __kmalloc+0x1c/0xe0
       [<ffffffff882685f4>] cifs_open+0x2a4/0x720
       [<ffffffff88122cef>] do_dentry_open+0x1ff/0x310
       [<ffffffff88268350>] ? cifsFileInfo_get+0x30/0x30
       [<ffffffff88123d92>] vfs_open+0x52/0x60
       [<ffffffff88131dd0>] path_openat+0x170/0xf70
       [<ffffffff88097d48>] ? remove_wait_queue+0x48/0x50
       [<ffffffff88133a29>] do_filp_open+0x79/0xd0
       [<ffffffff8813f2ca>] ? __alloc_fd+0x3a/0x170
       [<ffffffff881240c4>] do_sys_open+0x114/0x1e0
       [<ffffffff881241a9>] SyS_open+0x19/0x20
       [<ffffffff8896e257>] entry_SYSCALL_64_fastpath+0x12/0x6a
      Code: 4d 8d 6c 07 04 31 c0 4c 89 ee e8 47 6f e5 ff 31 c9 41 89 ce 44 89 f1 48 c7 c7 28 b1 bd 88 31 c0 49 01 cd 4c 89 ee e8 2b 6f e5 ff <45> 0f b7 75 04 48 c7 c7 31 b1 bd 88 31 c0 4d 01 ee 4c 89 f6 e8
      RIP  [<ffffffff8828a734>] SMB2_open+0x804/0x960
       RSP <ffff88005b31fa08>
      CR2: ffff8800a1a77cc6
      ---[ end trace d9f69ba64feee469 ]---
      Signed-off-by: default avatarJustin Maggard <jmaggard@netgear.com>
      Signed-off-by: default avatarSteve French <smfrench@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ee86b25d
    • Borislav Petkov's avatar
      EDAC, mc_sysfs: Fix freeing bus' name · 42b57326
      Borislav Petkov authored
      commit 12e26969 upstream.
      
      I get the splat below when modprobing/rmmoding EDAC drivers. It happens
      because bus->name is invalid after bus_unregister() has run. The Code: section
      below corresponds to:
      
        .loc 1 1108 0
        movq    672(%rbx), %rax # mci_1(D)->bus, mci_1(D)->bus
        .loc 1 1109 0
        popq    %rbx    #
      
        .loc 1 1108 0
        movq    (%rax), %rdi    # _7->name,
        jmp     kfree   #
      
      and %rax has some funky stuff 2030203020312030 which looks a lot like
      something walked over it.
      
      Fix that by saving the name ptr before doing stuff to string it points to.
      
        general protection fault: 0000 [#1] SMP
        Modules linked in: ...
        CPU: 4 PID: 10318 Comm: modprobe Tainted: G          I EN  3.12.51-11-default+ #48
        Hardware name: HP ProLiant DL380 G7, BIOS P67 05/05/2011
        task: ffff880311320280 ti: ffff88030da3e000 task.ti: ffff88030da3e000
        RIP: 0010:[<ffffffffa019da92>]  [<ffffffffa019da92>] edac_unregister_sysfs+0x22/0x30 [edac_core]
        RSP: 0018:ffff88030da3fe28  EFLAGS: 00010292
        RAX: 2030203020312030 RBX: ffff880311b4e000 RCX: 000000000000095c
        RDX: 0000000000000001 RSI: ffff880327bb9600 RDI: 0000000000000286
        RBP: ffff880311b4e750 R08: 0000000000000000 R09: ffffffff81296110
        R10: 0000000000000400 R11: 0000000000000000 R12: ffff88030ba1ac68
        R13: 0000000000000001 R14: 00000000011b02f0 R15: 0000000000000000
        FS:  00007fc9bf8f5700(0000) GS:ffff8801a7c40000(0000) knlGS:0000000000000000
        CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
        CR2: 0000000000403c90 CR3: 000000019ebdf000 CR4: 00000000000007e0
        Stack:
        Call Trace:
          i7core_unregister_mci.isra.9
          i7core_remove
          pci_device_remove
          __device_release_driver
          driver_detach
          bus_remove_driver
          pci_unregister_driver
          i7core_exit
          SyS_delete_module
          system_call_fastpath
          0x7fc9bf426536
        Code: 2e 0f 1f 84 00 00 00 00 00 66 66 66 66 90 53 48 89 fb e8 52 2a 1f e1 48 8b bb a0 02 00 00 e8 46 59 1f e1 48 8b 83 a0 02 00 00 5b <48> 8b 38 e9 26 9a fe e0 66 0f 1f 44 00 00 66 66 66 66 90 48 8b
        RIP  [<ffffffffa019da92>] edac_unregister_sysfs+0x22/0x30 [edac_core]
         RSP <ffff88030da3fe28>
      Signed-off-by: default avatarBorislav Petkov <bp@suse.de>
      Cc: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
      Fixes: 7a623c03 ("edac: rewrite the sysfs code to use struct device")
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      42b57326
    • Jeff Layton's avatar
      locks: fix unlock when fcntl_setlk races with a close · 7b667ced
      Jeff Layton authored
      commit 7f3697e2 upstream.
      
      Dmitry reported that he was able to reproduce the WARN_ON_ONCE that
      fires in locks_free_lock_context when the flc_posix list isn't empty.
      
      The problem turns out to be that we're basically rebuilding the
      file_lock from scratch in fcntl_setlk when we discover that the setlk
      has raced with a close. If the l_whence field is SEEK_CUR or SEEK_END,
      then we may end up with fl_start and fl_end values that differ from
      when the lock was initially set, if the file position or length of the
      file has changed in the interim.
      
      Fix this by just reusing the same lock request structure, and simply
      override fl_type value with F_UNLCK as appropriate. That ensures that
      we really are unlocking the lock that was initially set.
      
      While we're there, make sure that we do pop a WARN_ON_ONCE if the
      removal ever fails. Also return -EBADF in this event, since that's
      what we would have returned if the close had happened earlier.
      
      Cc: Alexander Viro <viro@zeniv.linux.org.uk>
      Fixes: c293621b (stale POSIX lock handling)
      Reported-by: default avatarDmitry Vyukov <dvyukov@google.com>
      Signed-off-by: default avatarJeff Layton <jeff.layton@primarydata.com>
      Acked-by: default avatar"J. Bruce Fields" <bfields@fieldses.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7b667ced
    • Hannes Reinecke's avatar
      bio: return EINTR if copying to user space got interrupted · 8a3b2a49
      Hannes Reinecke authored
      commit 2d99b55d upstream.
      
      Commit 35dc2483 introduced a check for
      current->mm to see if we have a user space context and only copies data
      if we do. Now if an IO gets interrupted by a signal data isn't copied
      into user space any more (as we don't have a user space context) but
      user space isn't notified about it.
      
      This patch modifies the behaviour to return -EINTR from bio_uncopy_user()
      to notify userland that a signal has interrupted the syscall, otherwise
      it could lead to a situation where the caller may get a buffer with
      no data returned.
      
      This can be reproduced by issuing SG_IO ioctl()s in one thread while
      constantly sending signals to it.
      
      Fixes: 35dc2483 [SCSI] sg: Fix user memory corruption when SG_IO is interrupted by a signal
      Signed-off-by: default avatarJohannes Thumshirn <jthumshirn@suse.de>
      Signed-off-by: default avatarHannes Reinecke <hare@suse.de>
      Cc: stable@vger.kernel.org # v.3.11+
      Signed-off-by: default avatarJens Axboe <axboe@fb.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8a3b2a49
  2. 03 Mar, 2016 35 commits