1. 28 Jan, 2014 1 commit
    • Geert Uytterhoeven's avatar
      spi: Fix crash with double message finalisation on error handling · 1f802f82
      Geert Uytterhoeven authored
      This reverts commit e120cc0d.
      
      It causes a NULL pointer dereference with drivers using the generic
      spi_transfer_one_message(), which always calls
      spi_finalize_current_message(), which zeroes master->cur_msg.
      
      Drivers implementing transfer_one_message() theirselves must always call
      spi_finalize_current_message(), even if the transfer failed:
      
       * @transfer_one_message: the subsystem calls the driver to transfer a single
       *      message while queuing transfers that arrive in the meantime. When the
       *      driver is finished with this message, it must call
       *      spi_finalize_current_message() so the subsystem can issue the next
       *      transfer
      Signed-off-by: default avatarGeert Uytterhoeven <geert+renesas@linux-m68k.org>
      Signed-off-by: default avatarMark Brown <broonie@linaro.org>
      1f802f82
  2. 23 Jan, 2014 8 commits
  3. 21 Jan, 2014 4 commits
  4. 17 Jan, 2014 3 commits
  5. 16 Jan, 2014 1 commit
  6. 14 Jan, 2014 4 commits
  7. 13 Jan, 2014 15 commits
  8. 12 Jan, 2014 4 commits
    • Linus Torvalds's avatar
      Linux 3.13-rc8 · 7e22e911
      Linus Torvalds authored
      7e22e911
    • Steven Rostedt's avatar
      SELinux: Fix possible NULL pointer dereference in selinux_inode_permission() · 3dc91d43
      Steven Rostedt authored
      While running stress tests on adding and deleting ftrace instances I hit
      this bug:
      
        BUG: unable to handle kernel NULL pointer dereference at 0000000000000020
        IP: selinux_inode_permission+0x85/0x160
        PGD 63681067 PUD 7ddbe067 PMD 0
        Oops: 0000 [#1] PREEMPT
        CPU: 0 PID: 5634 Comm: ftrace-test-mki Not tainted 3.13.0-rc4-test-00033-gd2a6dde-dirty #20
        Hardware name:                  /DG965MQ, BIOS MQ96510J.86A.0372.2006.0605.1717 06/05/2006
        task: ffff880078375800 ti: ffff88007ddb0000 task.ti: ffff88007ddb0000
        RIP: 0010:[<ffffffff812d8bc5>]  [<ffffffff812d8bc5>] selinux_inode_permission+0x85/0x160
        RSP: 0018:ffff88007ddb1c48  EFLAGS: 00010246
        RAX: 0000000000000000 RBX: 0000000000800000 RCX: ffff88006dd43840
        RDX: 0000000000000001 RSI: 0000000000000081 RDI: ffff88006ee46000
        RBP: ffff88007ddb1c88 R08: 0000000000000000 R09: ffff88007ddb1c54
        R10: 6e6576652f6f6f66 R11: 0000000000000003 R12: 0000000000000000
        R13: 0000000000000081 R14: ffff88006ee46000 R15: 0000000000000000
        FS:  00007f217b5b6700(0000) GS:ffffffff81e21000(0000) knlGS:0000000000000000
        CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033^M
        CR2: 0000000000000020 CR3: 000000006a0fe000 CR4: 00000000000007f0
        Call Trace:
          security_inode_permission+0x1c/0x30
          __inode_permission+0x41/0xa0
          inode_permission+0x18/0x50
          link_path_walk+0x66/0x920
          path_openat+0xa6/0x6c0
          do_filp_open+0x43/0xa0
          do_sys_open+0x146/0x240
          SyS_open+0x1e/0x20
          system_call_fastpath+0x16/0x1b
        Code: 84 a1 00 00 00 81 e3 00 20 00 00 89 d8 83 c8 02 40 f6 c6 04 0f 45 d8 40 f6 c6 08 74 71 80 cf 02 49 8b 46 38 4c 8d 4d cc 45 31 c0 <0f> b7 50 20 8b 70 1c 48 8b 41 70 89 d9 8b 78 04 e8 36 cf ff ff
        RIP  selinux_inode_permission+0x85/0x160
        CR2: 0000000000000020
      
      Investigating, I found that the inode->i_security was NULL, and the
      dereference of it caused the oops.
      
      in selinux_inode_permission():
      
      	isec = inode->i_security;
      
      	rc = avc_has_perm_noaudit(sid, isec->sid, isec->sclass, perms, 0, &avd);
      
      Note, the crash came from stressing the deletion and reading of debugfs
      files.  I was not able to recreate this via normal files.  But I'm not
      sure they are safe.  It may just be that the race window is much harder
      to hit.
      
      What seems to have happened (and what I have traced), is the file is
      being opened at the same time the file or directory is being deleted.
      As the dentry and inode locks are not held during the path walk, nor is
      the inodes ref counts being incremented, there is nothing saving these
      structures from being discarded except for an rcu_read_lock().
      
      The rcu_read_lock() protects against freeing of the inode, but it does
      not protect freeing of the inode_security_struct.  Now if the freeing of
      the i_security happens with a call_rcu(), and the i_security field of
      the inode is not changed (it gets freed as the inode gets freed) then
      there will be no issue here.  (Linus Torvalds suggested not setting the
      field to NULL such that we do not need to check if it is NULL in the
      permission check).
      
      Note, this is a hack, but it fixes the problem at hand.  A real fix is
      to restructure the destroy_inode() to call all the destructor handlers
      from the RCU callback.  But that is a major job to do, and requires a
      lot of work.  For now, we just band-aid this bug with this fix (it
      works), and work on a more maintainable solution in the future.
      
      Link: http://lkml.kernel.org/r/20140109101932.0508dec7@gandalf.local.home
      Link: http://lkml.kernel.org/r/20140109182756.17abaaa8@gandalf.local.home
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      3dc91d43
    • Hugh Dickins's avatar
      thp: fix copy_page_rep GPF by testing is_huge_zero_pmd once only · eecc1e42
      Hugh Dickins authored
      We see General Protection Fault on RSI in copy_page_rep: that RSI is
      what you get from a NULL struct page pointer.
      
        RIP: 0010:[<ffffffff81154955>]  [<ffffffff81154955>] copy_page_rep+0x5/0x10
        RSP: 0000:ffff880136e15c00  EFLAGS: 00010286
        RAX: ffff880000000000 RBX: ffff880136e14000 RCX: 0000000000000200
        RDX: 6db6db6db6db6db7 RSI: db73880000000000 RDI: ffff880dd0c00000
        RBP: ffff880136e15c18 R08: 0000000000000200 R09: 000000000005987c
        R10: 000000000005987c R11: 0000000000000200 R12: 0000000000000001
        R13: ffffea00305aa000 R14: 0000000000000000 R15: 0000000000000000
        FS:  00007f195752f700(0000) GS:ffff880c7fc20000(0000) knlGS:0000000000000000
        CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
        CR2: 0000000093010000 CR3: 00000001458e1000 CR4: 00000000000027e0
        Call Trace:
          copy_user_huge_page+0x93/0xab
          do_huge_pmd_wp_page+0x710/0x815
          handle_mm_fault+0x15d8/0x1d70
          __do_page_fault+0x14d/0x840
          do_page_fault+0x2f/0x90
          page_fault+0x22/0x30
      
      do_huge_pmd_wp_page() tests is_huge_zero_pmd(orig_pmd) four times: but
      since shrink_huge_zero_page() can free the huge_zero_page, and we have
      no hold of our own on it here (except where the fourth test holds
      page_table_lock and has checked pmd_same), it's possible for it to
      answer yes the first time, but no to the second or third test.  Change
      all those last three to tests for NULL page.
      
      (Note: this is not the same issue as trinity's DEBUG_PAGEALLOC BUG
      in copy_page_rep with RSI: ffff88009c422000, reported by Sasha Levin
      in https://lkml.org/lkml/2013/3/29/103.  I believe that one is due
      to the source page being split, and a tail page freed, while copy
      is in progress; and not a problem without DEBUG_PAGEALLOC, since
      the pmd_same check will prevent a miscopy from being made visible.)
      
      Fixes: 97ae1749 ("thp: implement refcounting for huge zero page")
      Signed-off-by: default avatarHugh Dickins <hughd@google.com>
      Cc: stable@vger.kernel.org # v3.10 v3.11 v3.12
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      eecc1e42
    • Ming Lei's avatar
      block: null_blk: fix queue leak inside removing device · 518d00b7
      Ming Lei authored
      When queue_mode is NULL_Q_MQ and null_blk is being removed,
      blk_cleanup_queue() isn't called to cleanup queue, so the queue
      allocated won't be freed.
      
      This patch calls blk_cleanup_queue() for MQ to drain all pending
      requests first and release the reference counter of queue kobject, then
      blk_mq_free_queue() will be called in queue kobject's release handler
      when queue kobject's reference counter drops to zero.
      Signed-off-by: default avatarMing Lei <tom.leiming@gmail.com>
      Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      518d00b7