1. 22 Aug, 2016 40 commits
    • Vegard Nossum's avatar
      block: fix use-after-free in seq file · 8bc7adaf
      Vegard Nossum authored
      [ Upstream commit 77da1605 ]
      
      I got a KASAN report of use-after-free:
      
          ==================================================================
          BUG: KASAN: use-after-free in klist_iter_exit+0x61/0x70 at addr ffff8800b6581508
          Read of size 8 by task trinity-c1/315
          =============================================================================
          BUG kmalloc-32 (Not tainted): kasan: bad access detected
          -----------------------------------------------------------------------------
      
          Disabling lock debugging due to kernel taint
          INFO: Allocated in disk_seqf_start+0x66/0x110 age=144 cpu=1 pid=315
                  ___slab_alloc+0x4f1/0x520
                  __slab_alloc.isra.58+0x56/0x80
                  kmem_cache_alloc_trace+0x260/0x2a0
                  disk_seqf_start+0x66/0x110
                  traverse+0x176/0x860
                  seq_read+0x7e3/0x11a0
                  proc_reg_read+0xbc/0x180
                  do_loop_readv_writev+0x134/0x210
                  do_readv_writev+0x565/0x660
                  vfs_readv+0x67/0xa0
                  do_preadv+0x126/0x170
                  SyS_preadv+0xc/0x10
                  do_syscall_64+0x1a1/0x460
                  return_from_SYSCALL_64+0x0/0x6a
          INFO: Freed in disk_seqf_stop+0x42/0x50 age=160 cpu=1 pid=315
                  __slab_free+0x17a/0x2c0
                  kfree+0x20a/0x220
                  disk_seqf_stop+0x42/0x50
                  traverse+0x3b5/0x860
                  seq_read+0x7e3/0x11a0
                  proc_reg_read+0xbc/0x180
                  do_loop_readv_writev+0x134/0x210
                  do_readv_writev+0x565/0x660
                  vfs_readv+0x67/0xa0
                  do_preadv+0x126/0x170
                  SyS_preadv+0xc/0x10
                  do_syscall_64+0x1a1/0x460
                  return_from_SYSCALL_64+0x0/0x6a
      
          CPU: 1 PID: 315 Comm: trinity-c1 Tainted: G    B           4.7.0+ #62
          Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Ubuntu-1.8.2-1ubuntu1 04/01/2014
           ffffea0002d96000 ffff880119b9f918 ffffffff81d6ce81 ffff88011a804480
           ffff8800b6581500 ffff880119b9f948 ffffffff8146c7bd ffff88011a804480
           ffffea0002d96000 ffff8800b6581500 fffffffffffffff4 ffff880119b9f970
          Call Trace:
           [<ffffffff81d6ce81>] dump_stack+0x65/0x84
           [<ffffffff8146c7bd>] print_trailer+0x10d/0x1a0
           [<ffffffff814704ff>] object_err+0x2f/0x40
           [<ffffffff814754d1>] kasan_report_error+0x221/0x520
           [<ffffffff8147590e>] __asan_report_load8_noabort+0x3e/0x40
           [<ffffffff83888161>] klist_iter_exit+0x61/0x70
           [<ffffffff82404389>] class_dev_iter_exit+0x9/0x10
           [<ffffffff81d2e8ea>] disk_seqf_stop+0x3a/0x50
           [<ffffffff8151f812>] seq_read+0x4b2/0x11a0
           [<ffffffff815f8fdc>] proc_reg_read+0xbc/0x180
           [<ffffffff814b24e4>] do_loop_readv_writev+0x134/0x210
           [<ffffffff814b4c45>] do_readv_writev+0x565/0x660
           [<ffffffff814b8a17>] vfs_readv+0x67/0xa0
           [<ffffffff814b8de6>] do_preadv+0x126/0x170
           [<ffffffff814b92ec>] SyS_preadv+0xc/0x10
      
      This problem can occur in the following situation:
      
      open()
       - pread()
          - .seq_start()
             - iter = kmalloc() // succeeds
             - seqf->private = iter
          - .seq_stop()
             - kfree(seqf->private)
       - pread()
          - .seq_start()
             - iter = kmalloc() // fails
          - .seq_stop()
             - class_dev_iter_exit(seqf->private) // boom! old pointer
      
      As the comment in disk_seqf_stop() says, stop is called even if start
      failed, so we need to reinitialise the private pointer to NULL when seq
      iteration stops.
      
      An alternative would be to set the private pointer to NULL when the
      kmalloc() in disk_seqf_start() fails.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarVegard Nossum <vegard.nossum@oracle.com>
      Acked-by: default avatarTejun Heo <tj@kernel.org>
      Signed-off-by: default avatarJens Axboe <axboe@fb.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      8bc7adaf
    • James Hogan's avatar
      metag: Fix __cmpxchg_u32 asm constraint for CMP · ddc1102b
      James Hogan authored
      [ Upstream commit 6154c187 ]
      
      The LNKGET based atomic sequence in __cmpxchg_u32 has slightly incorrect
      constraints for the return value which under certain circumstances can
      allow an address unit register to be used as the first operand of a CMP
      instruction. This isn't a valid instruction however as the encodings
      only allow a data unit to be specified. This would result in an
      assembler error like the following:
      
        Error: failed to assemble instruction: "CMP A0.2,D0Ar6"
      
      Fix by changing the constraint from "=&da" (assigned, early clobbered,
      data or address unit register) to "=&d" (data unit register only).
      
      The constraint for the second operand, "bd" (an op2 register where op1
      is a data unit register and the instruction supports O2R) is already
      correct assuming the first operand is a data unit register.
      
      Other cases of CMP in inline asm have had their constraints checked, and
      appear to all be fine.
      
      Fixes: 6006c0d8 ("metag: Atomics, locks and bitops")
      Signed-off-by: default avatarJames Hogan <james.hogan@imgtec.com>
      Cc: linux-metag@vger.kernel.org
      Cc: <stable@vger.kernel.org> # 3.9.x-
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      ddc1102b
    • Maruthi Srinivas Bayyavarapu's avatar
      ALSA: hda: add AMD Bonaire AZ PCI ID with proper driver caps · 71f1b13f
      Maruthi Srinivas Bayyavarapu authored
      [ Upstream commit fd48331f ]
      
      This commit fixes garbled audio on Bonaire HDMI
      Signed-off-by: default avatarMaruthi Bayyavarapu <maruthi.bayyavarapu@amd.com>
      Reviewed-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      71f1b13f
    • Fabian Frederick's avatar
      sysv, ipc: fix security-layer leaking · 7dd90826
      Fabian Frederick authored
      [ Upstream commit 9b24fef9 ]
      
      Commit 53dad6d3 ("ipc: fix race with LSMs") updated ipc_rcu_putref()
      to receive rcu freeing function but used generic ipc_rcu_free() instead
      of msg_rcu_free() which does security cleaning.
      
      Running LTP msgsnd06 with kmemleak gives the following:
      
        cat /sys/kernel/debug/kmemleak
      
        unreferenced object 0xffff88003c0a11f8 (size 8):
          comm "msgsnd06", pid 1645, jiffies 4294672526 (age 6.549s)
          hex dump (first 8 bytes):
            1b 00 00 00 01 00 00 00                          ........
          backtrace:
            kmemleak_alloc+0x23/0x40
            kmem_cache_alloc_trace+0xe1/0x180
            selinux_msg_queue_alloc_security+0x3f/0xd0
            security_msg_queue_alloc+0x2e/0x40
            newque+0x4e/0x150
            ipcget+0x159/0x1b0
            SyS_msgget+0x39/0x40
            entry_SYSCALL_64_fastpath+0x13/0x8f
      
      Manfred Spraul suggested to fix sem.c as well and Davidlohr Bueso to
      only use ipc_rcu_free in case of security allocation failure in newary()
      
      Fixes: 53dad6d3 ("ipc: fix race with LSMs")
      Link: http://lkml.kernel.org/r/1470083552-22966-1-git-send-email-fabf@skynet.beSigned-off-by: default avatarFabian Frederick <fabf@skynet.be>
      Cc: Davidlohr Bueso <dbueso@suse.de>
      Cc: Manfred Spraul <manfred@colorfullife.com>
      Cc: <stable@vger.kernel.org>	[3.12+]
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      7dd90826
    • Jia He's avatar
      mm/hugetlb: avoid soft lockup in set_max_huge_pages() · b4f191a7
      Jia He authored
      [ Upstream commit 649920c6 ]
      
      In powerpc servers with large memory(32TB), we watched several soft
      lockups for hugepage under stress tests.
      
      The call traces are as follows:
      1.
      get_page_from_freelist+0x2d8/0xd50
      __alloc_pages_nodemask+0x180/0xc20
      alloc_fresh_huge_page+0xb0/0x190
      set_max_huge_pages+0x164/0x3b0
      
      2.
      prep_new_huge_page+0x5c/0x100
      alloc_fresh_huge_page+0xc8/0x190
      set_max_huge_pages+0x164/0x3b0
      
      This patch fixes such soft lockups.  It is safe to call cond_resched()
      there because it is out of spin_lock/unlock section.
      
      Link: http://lkml.kernel.org/r/1469674442-14848-1-git-send-email-hejianet@gmail.comSigned-off-by: default avatarJia He <hejianet@gmail.com>
      Reviewed-by: default avatarNaoya Horiguchi <n-horiguchi@ah.jp.nec.com>
      Acked-by: default avatarMichal Hocko <mhocko@suse.com>
      Acked-by: default avatarDave Hansen <dave.hansen@linux.intel.com>
      Cc: Mike Kravetz <mike.kravetz@oracle.com>
      Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
      Cc: Paul Gortmaker <paul.gortmaker@windriver.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      b4f191a7
    • Mike Snitzer's avatar
      dm flakey: error READ bios during the down_interval · 7154bbe8
      Mike Snitzer authored
      [ Upstream commit 99f3c90d ]
      
      When the corrupt_bio_byte feature was introduced it caused READ bios to
      no longer be errored with -EIO during the down_interval.  This had to do
      with the complexity of needing to submit READs if the corrupt_bio_byte
      feature was used.
      
      Fix it so READ bios are properly errored with -EIO; doing so early in
      flakey_map() as long as there isn't a match for the corrupt_bio_byte
      feature.
      
      Fixes: a3998799 ("dm flakey: add corrupt_bio_byte feature")
      Reported-by: default avatarAkira Hayakawa <ruby.wktk@gmail.com>
      Signed-off-by: default avatarMike Snitzer <snitzer@redhat.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      7154bbe8
    • Laura Abbott's avatar
      ftrace/recordmcount: Work around for addition of metag magic but not relocations · 8a7e3694
      Laura Abbott authored
      [ Upstream commit b2e1c26f ]
      
      glibc recently did a sync up (94e73c95d9b5 "elf.h: Sync with the gabi
      webpage") that added a #define for EM_METAG but did not add relocations
      
      This triggers build errors:
      
      scripts/recordmcount.c: In function 'do_file':
      scripts/recordmcount.c:466:28: error: 'R_METAG_ADDR32' undeclared (first use in this function)
        case EM_METAG:  reltype = R_METAG_ADDR32;
                                  ^~~~~~~~~~~~~~
      scripts/recordmcount.c:466:28: note: each undeclared identifier is reported only once for each function it appears in
      scripts/recordmcount.c:468:20: error: 'R_METAG_NONE' undeclared (first use in this function)
           rel_type_nop = R_METAG_NONE;
                          ^~~~~~~~~~~~
      
      Work around this change with some more #ifdefery for the relocations.
      
      Fedora Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1354034
      
      Link: http://lkml.kernel.org/r/1468005530-14757-1-git-send-email-labbott@redhat.com
      
      Cc: stable@vger.kernel.org # v3.9+
      Cc: James Hogan <james.hogan@imgtec.com>
      Fixes: 00512bdd ("metag: ftrace support")
      Reported-by: default avatarRoss Burton <ross.burton@intel.com>
      Signed-off-by: default avatarLaura Abbott <labbott@redhat.com>
      Signed-off-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      8a7e3694
    • Konstantin Neumoin's avatar
      balloon: check the number of available pages in leak balloon · 0335e86f
      Konstantin Neumoin authored
      [ Upstream commit 37cf99e0 ]
      
      The balloon has a special mechanism that is subscribed to the oom
      notification which leads to deflation for a fixed number of pages.
      The number is always fixed even when the balloon is fully deflated.
      But leak_balloon did not expect that the pages to deflate will be more
      than taken, and raise a "BUG" in balloon_page_dequeue when page list
      will be empty.
      
      So, the simplest solution would be to check that the number of releases
      pages is less or equal to the number taken pages.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarKonstantin Neumoin <kneumoin@virtuozzo.com>
      Signed-off-by: default avatarDenis V. Lunev <den@openvz.org>
      CC: Michael S. Tsirkin <mst@redhat.com>
      Signed-off-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      0335e86f
    • Sasha Levin's avatar
      x86/syscalls/64: Add compat_sys_keyctl for 32-bit userspace · 40ca045f
      Sasha Levin authored
      [ Upstream commit f7d66562 ]
      
      x86_64 needs to use compat_sys_keyctl for 32-bit userspace rather than
      calling sys_keyctl(). The latter will work in a lot of cases, thereby
      hiding the issue.
      Reported-by: default avatarStephan Mueller <smueller@chronox.de>
      Tested-by: default avatarStephan Mueller <smueller@chronox.de>
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: keyrings@vger.kernel.org
      Cc: linux-security-module@vger.kernel.org
      Cc: stable@vger.kernel.org
      Link: http://lkml.kernel.org/r/146961615805.14395.5581949237156769439.stgit@warthog.procyon.org.ukSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      40ca045f
    • Keith Packard's avatar
      ALSA: hda/realtek: Enable HP amp and mute LED on HP Folio 9480m [v3] · 0ff4673f
      Keith Packard authored
      [ Upstream commit 98973f2f ]
      
      This laptop needs GPIO4 pulled high to enable the headphone amplifier,
      and has a mute LED on GPIO3. I modelled the patch on the existing
      GPIO4 code which pulls the line low for the same purpose; this time,
      the HP amp line is pulled high.
      
      v2: Disable the headphone amplifier when no headphone is connected.
          Don't disable power savings to preserve the LED state.
      
      v3: Remove headset-specific hooks and code; this is just a headphone.
      Signed-off-by: default avatarKeith Packard <keithp@keithp.com>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      0ff4673f
    • Mikulas Patocka's avatar
      drm/nouveau/fbcon: fix font width not divisible by 8 · b8463d76
      Mikulas Patocka authored
      [ Upstream commit 28668f43 ]
      
      The patch f045f459 ("drm/nouveau/fbcon: fix out-of-bounds memory accesses")
      tries to fix some out of memory accesses. Unfortunatelly, the patch breaks the
      display when using fonts with width that is not divisiable by 8.
      
      The monochrome bitmap for each character is stored in memory by lines from top
      to bottom. Each line is padded to a full byte.
      
      For example, for 22x11 font, each line is padded to 16 bits, so each
      character is consuming 44 bytes total, that is 11 32-bit words. The patch
      f045f459 changed the logic to "dsize = ALIGN(image->width *
      image->height, 32) >> 5", that is just 8 words - this is incorrect and it
      causes display corruption.
      
      This patch adds the necesary padding of lines to 8 bytes.
      
      This patch should be backported to stable kernels where f045f459 was
      backported.
      Signed-off-by: default avatarMikulas Patocka <mpatocka@redhat.com>
      Fixes: f045f459 ("drm/nouveau/fbcon: fix out-of-bounds memory accesses")
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarBen Skeggs <bskeggs@redhat.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      b8463d76
    • Richard Weinberger's avatar
      ubi: Make volume resize power cut aware · bd0e924c
      Richard Weinberger authored
      [ Upstream commit 4946784b ]
      
      When the volume resize operation shrinks a volume,
      LEBs will be unmapped. Since unmapping will not erase these
      LEBs immediately we have to wait for that operation to finish.
      Otherwise in case of a power cut right after writing the new
      volume table the UBI attach process can find more LEBs than the
      volume table knows. This will render the UBI image unattachable.
      
      Fix this issue by waiting for erase to complete and write the new
      volume table afterward.
      
      Cc: <stable@vger.kernel.org>
      Reported-by: default avatarBoris Brezillon <boris.brezillon@free-electrons.com>
      Reviewed-by: default avatarBoris Brezillon <boris.brezillon@free-electrons.com>
      Signed-off-by: default avatarRichard Weinberger <richard@nod.at>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      bd0e924c
    • Iosif Harutyunov's avatar
      ubi: Fix race condition between ubi device creation and udev · cdf25333
      Iosif Harutyunov authored
      [ Upstream commit 714fb87e ]
      
      Install the UBI device object before we arm sysfs.
      Otherwise udev tries to read sysfs attributes before UBI is ready and
      udev rules will not match.
      
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarIosif Harutyunov <iharutyunov@sonicwall.com>
      [rw: massaged commit message]
      Signed-off-by: default avatarRichard Weinberger <richard@nod.at>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      cdf25333
    • Wei Fang's avatar
      fuse: fix wrong assignment of ->flags in fuse_send_init() · 6d1b8d7a
      Wei Fang authored
      [ Upstream commit 9446385f ]
      
      FUSE_HAS_IOCTL_DIR should be assigned to ->flags, it may be a typo.
      Signed-off-by: default avatarWei Fang <fangwei1@huawei.com>
      Signed-off-by: default avatarMiklos Szeredi <mszeredi@redhat.com>
      Fixes: 69fe05c9 ("fuse: add missing INIT flags")
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      6d1b8d7a
    • Maxim Patlasov's avatar
      fuse: fuse_flush must check mapping->flags for errors · a8f8b0f5
      Maxim Patlasov authored
      [ Upstream commit 9ebce595 ]
      
      fuse_flush() calls write_inode_now() that triggers writeback, but actual
      writeback will happen later, on fuse_sync_writes(). If an error happens,
      fuse_writepage_end() will set error bit in mapping->flags. So, we have to
      check mapping->flags after fuse_sync_writes().
      Signed-off-by: default avatarMaxim Patlasov <mpatlasov@virtuozzo.com>
      Signed-off-by: default avatarMiklos Szeredi <mszeredi@redhat.com>
      Fixes: 4d99ff8f ("fuse: Turn writeback cache on")
      Cc: <stable@vger.kernel.org> # v3.15+
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      a8f8b0f5
    • Alexey Kuznetsov's avatar
      fuse: fsync() did not return IO errors · 689c2a89
      Alexey Kuznetsov authored
      [ Upstream commit ac7f052b ]
      
      Due to implementation of fuse writeback filemap_write_and_wait_range() does
      not catch errors. We have to do this directly after fuse_sync_writes()
      Signed-off-by: default avatarAlexey Kuznetsov <kuznet@virtuozzo.com>
      Signed-off-by: default avatarMaxim Patlasov <mpatlasov@virtuozzo.com>
      Signed-off-by: default avatarMiklos Szeredi <mszeredi@redhat.com>
      Fixes: 4d99ff8f ("fuse: Turn writeback cache on")
      Cc: <stable@vger.kernel.org> # v3.15+
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      689c2a89
    • Vineet Gupta's avatar
      ARC: mm: don't loose PTE_SPECIAL in pte_modify() · 77c6ffdb
      Vineet Gupta authored
      [ Upstream commit 3925a16a ]
      
      LTP madvise05 was generating mm splat
      
      | [ARCLinux]# /sd/ltp/testcases/bin/madvise05
      | BUG: Bad page map in process madvise05  pte:80e08211 pmd:9f7d4000
      | page:9fdcfc90 count:1 mapcount:-1 mapping:  (null) index:0x0 flags: 0x404(referenced|reserved)
      | page dumped because: bad pte
      | addr:200b8000 vm_flags:00000070 anon_vma:  (null) mapping:  (null) index:1005c
      | file:  (null) fault:  (null) mmap:  (null) readpage:  (null)
      | CPU: 2 PID: 6707 Comm: madvise05
      
      And for newer kernels, the system was rendered unusable afterwards.
      
      The problem was mprotect->pte_modify() clearing PTE_SPECIAL (which is
      set to identify the special zero page wired to the pte).
      When pte was finally unmapped, special casing for zero page was not
      done, and instead it was treated as a "normal" page, tripping on the
      map counts etc.
      
      This fixes ARC STAR 9001053308
      
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarVineet Gupta <vgupta@synopsys.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      77c6ffdb
    • Alex Deucher's avatar
      drm/radeon: fix firmware info version checks · 2d6adadf
      Alex Deucher authored
      [ Upstream commit 3edc38a0 ]
      
      Some of the checks didn't handle frev 2 tables properly.
      Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      2d6adadf
    • David Howells's avatar
      KEYS: 64-bit MIPS needs to use compat_sys_keyctl for 32-bit userspace · be17cd2e
      David Howells authored
      [ Upstream commit 20f06ed9 ]
      
      MIPS64 needs to use compat_sys_keyctl for 32-bit userspace rather than
      calling sys_keyctl.  The latter will work in a lot of cases, thereby hiding
      the issue.
      Reported-by: default avatarStephan Mueller <smueller@chronox.de>
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      cc: stable@vger.kernel.org
      Cc: linux-mips@linux-mips.org
      Cc: linux-kernel@vger.kernel.org
      Cc: linux-security-module@vger.kernel.org
      Cc: keyrings@vger.kernel.org
      Patchwork: https://patchwork.linux-mips.org/patch/13832/Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      be17cd2e
    • Paul Mackerras's avatar
      KVM: PPC: Book3S HV: Save/restore TM state in H_CEDE · 8c0c7bb9
      Paul Mackerras authored
      [ Upstream commit 93d17397 ]
      
      It turns out that if the guest does a H_CEDE while the CPU is in
      a transactional state, and the H_CEDE does a nap, and the nap
      loses the architected state of the CPU (which is is allowed to do),
      then we lose the checkpointed state of the virtual CPU.  In addition,
      the transactional-memory state recorded in the MSR gets reset back
      to non-transactional, and when we try to return to the guest, we take
      a TM bad thing type of program interrupt because we are trying to
      transition from non-transactional to transactional with a hrfid
      instruction, which is not permitted.
      
      The result of the program interrupt occurring at that point is that
      the host CPU will hang in an infinite loop with interrupts disabled.
      Thus this is a denial of service vulnerability in the host which can
      be triggered by any guest (and depending on the guest kernel, it can
      potentially triggered by unprivileged userspace in the guest).
      
      This vulnerability has been assigned the ID CVE-2016-5412.
      
      To fix this, we save the TM state before napping and restore it
      on exit from the nap, when handling a H_CEDE in real mode.  The
      case where H_CEDE exits to host virtual mode is already OK (as are
      other hcalls which exit to host virtual mode) because the exit
      path saves the TM state.
      
      Cc: stable@vger.kernel.org # v3.15+
      Signed-off-by: default avatarPaul Mackerras <paulus@ozlabs.org>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      8c0c7bb9
    • Paul Mackerras's avatar
      KVM: PPC: Book3S HV: Pull out TM state save/restore into separate procedures · 15b4c06d
      Paul Mackerras authored
      [ Upstream commit f024ee09 ]
      
      This moves the transactional memory state save and restore sequences
      out of the guest entry/exit paths into separate procedures.  This is
      so that these sequences can be used in going into and out of nap
      in a subsequent patch.
      
      The only code changes here are (a) saving and restore LR on the
      stack, since these new procedures get called with a bl instruction,
      (b) explicitly saving r1 into the PACA instead of assuming that
      HSTATE_HOST_R1(r13) is already set, and (c) removing an unnecessary
      and redundant setting of MSR[TM] that should have been removed by
      commit 9d4d0bdd9e0a ("KVM: PPC: Book3S HV: Add transactional memory
      support", 2013-09-24) but wasn't.
      
      Cc: stable@vger.kernel.org # v3.15+
      Signed-off-by: default avatarPaul Mackerras <paulus@ozlabs.org>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      15b4c06d
    • Pavel Shilovsky's avatar
      CIFS: Fix a possible invalid memory access in smb2_query_symlink() · 1eaac174
      Pavel Shilovsky authored
      [ Upstream commit 7893242e ]
      
      During following a symbolic link we received err_buf from SMB2_open().
      While the validity of SMB2 error response is checked previously
      in smb2_check_message() a symbolic link payload is not checked at all.
      Fix it by adding such checks.
      
      Cc: Dan Carpenter <dan.carpenter@oracle.com>
      CC: Stable <stable@vger.kernel.org>
      Signed-off-by: default avatarPavel Shilovsky <pshilovsky@samba.org>
      Signed-off-by: default avatarSteve French <smfrench@gmail.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      1eaac174
    • Aurelien Aptel's avatar
      fs/cifs: make share unaccessible at root level mountable · a10e07c7
      Aurelien Aptel authored
      [ Upstream commit a6b5058f ]
      
      if, when mounting //HOST/share/sub/dir/foo we can query /sub/dir/foo but
      not any of the path components above:
      
      - store the /sub/dir/foo prefix in the cifs super_block info
      - in the superblock, set root dentry to the subpath dentry (instead of
        the share root)
      - set a flag in the superblock to remember it
      - use prefixpath when building path from a dentry
      
      fixes bso#8950
      Signed-off-by: default avatarAurelien Aptel <aaptel@suse.com>
      CC: Stable <stable@vger.kernel.org>
      Reviewed-by: default avatarPavel Shilovsky <pshilovsky@samba.org>
      Signed-off-by: default avatarSteve French <smfrench@gmail.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      a10e07c7
    • Dmitry Torokhov's avatar
      Input: i8042 - break load dependency between atkbd/psmouse and i8042 · 2bad2554
      Dmitry Torokhov authored
      [ Upstream commit 40974618 ]
      
      As explained in 1407814240-4275-1-git-send-email-decui@microsoft.com we
      have a hard load dependency between i8042 and atkbd which prevents
      keyboard from working on Gen2 Hyper-V VMs.
      
      > hyperv_keyboard invokes serio_interrupt(), which needs a valid serio
      > driver like atkbd.c.  atkbd.c depends on libps2.c because it invokes
      > ps2_command().  libps2.c depends on i8042.c because it invokes
      > i8042_check_port_owner().  As a result, hyperv_keyboard actually
      > depends on i8042.c.
      >
      > For a Generation 2 Hyper-V VM (meaning no i8042 device emulated), if a
      > Linux VM (like Arch Linux) happens to configure CONFIG_SERIO_I8042=m
      > rather than =y, atkbd.ko can't load because i8042.ko can't load(due to
      > no i8042 device emulated) and finally hyperv_keyboard can't work and
      > the user can't input: https://bugs.archlinux.org/task/39820
      > (Ubuntu/RHEL/SUSE aren't affected since they use CONFIG_SERIO_I8042=y)
      
      To break the dependency we move away from using i8042_check_port_owner()
      and instead allow serio port owner specify a mutex that clients should use
      to serialize PS/2 command stream.
      Reported-by: default avatarMark Laws <mdl@60hz.org>
      Tested-by: default avatarMark Laws <mdl@60hz.org>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      2bad2554
    • Ben Hutchings's avatar
      Documentation/module-signing.txt: Note need for version info if reusing a key · 5a7dd70c
      Ben Hutchings authored
      [ Upstream commit b8612e51 ]
      
      Signing a module should only make it trusted by the specific kernel it
      was built for, not anything else.  If a module signing key is used for
      multiple ABI-incompatible kernels, the modules need to include enough
      version information to distinguish them.
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarRusty Russell <rusty@rustcorp.com.au>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      5a7dd70c
    • Ben Hutchings's avatar
      module: Invalidate signatures on force-loaded modules · 1d307756
      Ben Hutchings authored
      [ Upstream commit bca014ca ]
      
      Signing a module should only make it trusted by the specific kernel it
      was built for, not anything else.  Loading a signed module meant for a
      kernel with a different ABI could have interesting effects.
      Therefore, treat all signatures as invalid when a module is
      force-loaded.
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarRusty Russell <rusty@rustcorp.com.au>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      1d307756
    • Vegard Nossum's avatar
      net/irda: fix NULL pointer dereference on memory allocation failure · 29d011ab
      Vegard Nossum authored
      [ Upstream commit d3e6952c ]
      
      I ran into this:
      
          kasan: CONFIG_KASAN_INLINE enabled
          kasan: GPF could be caused by NULL-ptr deref or user memory access
          general protection fault: 0000 [#1] PREEMPT SMP KASAN
          CPU: 2 PID: 2012 Comm: trinity-c3 Not tainted 4.7.0-rc7+ #19
          Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Ubuntu-1.8.2-1ubuntu1 04/01/2014
          task: ffff8800b745f2c0 ti: ffff880111740000 task.ti: ffff880111740000
          RIP: 0010:[<ffffffff82bbf066>]  [<ffffffff82bbf066>] irttp_connect_request+0x36/0x710
          RSP: 0018:ffff880111747bb8  EFLAGS: 00010286
          RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000069dd8358
          RDX: 0000000000000009 RSI: 0000000000000027 RDI: 0000000000000048
          RBP: ffff880111747c00 R08: 0000000000000000 R09: 0000000000000000
          R10: 0000000069dd8358 R11: 1ffffffff0759723 R12: 0000000000000000
          R13: ffff88011a7e4780 R14: 0000000000000027 R15: 0000000000000000
          FS:  00007fc738404700(0000) GS:ffff88011af00000(0000) knlGS:0000000000000000
          CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
          CR2: 00007fc737fdfb10 CR3: 0000000118087000 CR4: 00000000000006e0
          Stack:
           0000000000000200 ffff880111747bd8 ffffffff810ee611 ffff880119f1f220
           ffff880119f1f4f8 ffff880119f1f4f0 ffff88011a7e4780 ffff880119f1f232
           ffff880119f1f220 ffff880111747d58 ffffffff82bca542 0000000000000000
          Call Trace:
           [<ffffffff82bca542>] irda_connect+0x562/0x1190
           [<ffffffff825ae582>] SYSC_connect+0x202/0x2a0
           [<ffffffff825b4489>] SyS_connect+0x9/0x10
           [<ffffffff8100334c>] do_syscall_64+0x19c/0x410
           [<ffffffff83295ca5>] entry_SYSCALL64_slow_path+0x25/0x25
          Code: 41 89 ca 48 89 e5 41 57 41 56 41 55 41 54 41 89 d7 53 48 89 fb 48 83 c7 48 48 89 fa 41 89 f6 48 c1 ea 03 48 83 ec 20 4c 8b 65 10 <0f> b6 04 02 84 c0 74 08 84 c0 0f 8e 4c 04 00 00 80 7b 48 00 74
          RIP  [<ffffffff82bbf066>] irttp_connect_request+0x36/0x710
           RSP <ffff880111747bb8>
          ---[ end trace 4cda2588bc055b30 ]---
      
      The problem is that irda_open_tsap() can fail and leave self->tsap = NULL,
      and then irttp_connect_request() almost immediately dereferences it.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarVegard Nossum <vegard.nossum@oracle.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      29d011ab
    • Wei Fang's avatar
      fs/dcache.c: avoid soft-lockup in dput() · 5c0a3ca7
      Wei Fang authored
      [ Upstream commit 47be6184 ]
      
      We triggered soft-lockup under stress test which
      open/access/write/close one file concurrently on more than
      five different CPUs:
      
      WARN: soft lockup - CPU#0 stuck for 11s! [who:30631]
      ...
      [<ffffffc0003986f8>] dput+0x100/0x298
      [<ffffffc00038c2dc>] terminate_walk+0x4c/0x60
      [<ffffffc00038f56c>] path_lookupat+0x5cc/0x7a8
      [<ffffffc00038f780>] filename_lookup+0x38/0xf0
      [<ffffffc000391180>] user_path_at_empty+0x78/0xd0
      [<ffffffc0003911f4>] user_path_at+0x1c/0x28
      [<ffffffc00037d4fc>] SyS_faccessat+0xb4/0x230
      
      ->d_lock trylock may failed many times because of concurrently
      operations, and dput() may execute a long time.
      
      Fix this by replacing cpu_relax() with cond_resched().
      dput() used to be sleepable, so make it sleepable again
      should be safe.
      
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarWei Fang <fangwei1@huawei.com>
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      5c0a3ca7
    • Linus Torvalds's avatar
      dcache: let the dentry count go down to zero without taking d_lock · ead2cea2
      Linus Torvalds authored
      [ Upstream commit 360f5479 ]
      
      We can be more aggressive about this, if we are clever and careful. This is subtle.
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      ead2cea2
    • Benjamin Coddington's avatar
      nfs: don't create zero-length requests · cf4f30b2
      Benjamin Coddington authored
      [ Upstream commit 149a4fdd ]
      
      NFS doesn't expect requests with wb_bytes set to zero and may make
      unexpected decisions about how to handle that request at the page IO layer.
      Skip request creation if we won't have any wb_bytes in the request.
      Signed-off-by: default avatarBenjamin Coddington <bcodding@redhat.com>
      Signed-off-by: default avatarAlexey Dobriyan <adobriyan@gmail.com>
      Reviewed-by: default avatarWeston Andros Adamson <dros@primarydata.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarTrond Myklebust <trond.myklebust@primarydata.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      cf4f30b2
    • Andy Shevchenko's avatar
      gpio: intel-mid: Remove potentially harmful code · f9fef43a
      Andy Shevchenko authored
      [ Upstream commit 3dbd3212 ]
      
      The commit d56d6b3d ("gpio: langwell: add Intel Merrifield support")
      doesn't look at all as a proper support for Intel Merrifield and I dare to say
      that it distorts the behaviour of the hardware.
      
      The register map is different on Intel Merrifield, i.e. only 6 out of 8
      register have the same purpose but none of them has same location in the
      address space. The current case potentially harmful to existing hardware since
      it's poking registers on wrong offsets and may set some pin to be GPIO output
      when connected hardware doesn't expect such.
      
      Besides the above GPIO and pinctrl on Intel Merrifield have been located in
      different IP blocks. The functionality has been extended as well, i.e. added
      support of level interrupts, special registers for wake capable sources and
      thus, in my opinion, requires a completele separate driver.
      
      If someone wondering the existing gpio-intel-mid.c would be converted to actual
      pinctrl (which by the fact it is now), though I wouldn't be a volunteer to do
      that.
      
      Fixes: d56d6b3d ("gpio: langwell: add Intel Merrifield support")
      Cc: stable@vger.kernel.org # v3.13+
      Signed-off-by: default avatarAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      Reviewed-by: default avatarMika Westerberg <mika.westerberg@linux.intel.com>
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      f9fef43a
    • Feng Li's avatar
      iscsi-target: Fix panic when adding second TCP connection to iSCSI session · 7b37bc27
      Feng Li authored
      [ Upstream commit 8abc718d ]
      
      In MC/S scenario, the conn->sess has been set NULL in
      iscsi_login_non_zero_tsih_s1 when the second connection comes here,
      then kernel panic.
      
      The conn->sess will be assigned in iscsi_login_non_zero_tsih_s2. So
      we should check whether it's NULL before calling.
      Signed-off-by: default avatarFeng Li <lifeng1519@gmail.com>
      Tested-by: default avatarSumit Rai <sumit.rai@calsoftinc.com>
      Cc: stable@vger.kernel.org # 3.14+
      Signed-off-by: default avatarNicholas Bellinger <nab@linux-iscsi.org>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      7b37bc27
    • Paul Moore's avatar
      audit: fix a double fetch in audit_log_single_execve_arg() · 3f4976f0
      Paul Moore authored
      [ Upstream commit 43761473 ]
      
      There is a double fetch problem in audit_log_single_execve_arg()
      where we first check the execve(2) argumnets for any "bad" characters
      which would require hex encoding and then re-fetch the arguments for
      logging in the audit record[1].  Of course this leaves a window of
      opportunity for an unsavory application to munge with the data.
      
      This patch reworks things by only fetching the argument data once[2]
      into a buffer where it is scanned and logged into the audit
      records(s).  In addition to fixing the double fetch, this patch
      improves on the original code in a few other ways: better handling
      of large arguments which require encoding, stricter record length
      checking, and some performance improvements (completely unverified,
      but we got rid of some strlen() calls, that's got to be a good
      thing).
      
      As part of the development of this patch, I've also created a basic
      regression test for the audit-testsuite, the test can be tracked on
      GitHub at the following link:
      
       * https://github.com/linux-audit/audit-testsuite/issues/25
      
      [1] If you pay careful attention, there is actually a triple fetch
      problem due to a strnlen_user() call at the top of the function.
      
      [2] This is a tiny white lie, we do make a call to strnlen_user()
      prior to fetching the argument data.  I don't like it, but due to the
      way the audit record is structured we really have no choice unless we
      copy the entire argument at once (which would require a rather
      wasteful allocation).  The good news is that with this patch the
      kernel no longer relies on this strnlen_user() value for anything
      beyond recording it in the log, we also update it with a trustworthy
      value whenever possible.
      Reported-by: default avatarPengfei Wang <wpengfeinudt@gmail.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarPaul Moore <paul@paul-moore.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      3f4976f0
    • Linus Torvalds's avatar
      Fix broken audit tests for exec arg len · a59a2f6b
      Linus Torvalds authored
      [ Upstream commit 45820c29 ]
      
      The "fix" in commit 0b08c5e5 ("audit: Fix check of return value of
      strnlen_user()") didn't fix anything, it broke things.  As reported by
      Steven Rostedt:
      
       "Yes, strnlen_user() returns 0 on fault, but if you look at what len is
        set to, than you would notice that on fault len would be -1"
      
      because we just subtracted one from the return value.  So testing
      against 0 doesn't test for a fault condition, it tests against a
      perfectly valid empty string.
      
      Also fix up the usual braindamage wrt using WARN_ON() inside a
      conditional - make it part of the conditional and remove the explicit
      unlikely() (which is already part of the WARN_ON*() logic, exactly so
      that you don't have to write unreadable code.
      Reported-and-tested-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      Cc: Jan Kara <jack@suse.cz>
      Cc: Paul Moore <pmoore@redhat.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      a59a2f6b
    • Jan Kara's avatar
      audit: Fix check of return value of strnlen_user() · c786cc5e
      Jan Kara authored
      [ Upstream commit 0b08c5e5 ]
      
      strnlen_user() returns 0 when it hits fault, not -1. Fix the test in
      audit_log_single_execve_arg(). Luckily this shouldn't ever happen unless
      there's a kernel bug so it's mostly a cosmetic fix.
      
      CC: Paul Moore <pmoore@redhat.com>
      Signed-off-by: default avatarJan Kara <jack@suse.cz>
      Signed-off-by: default avatarPaul Moore <pmoore@redhat.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      c786cc5e
    • Rabin Vincent's avatar
      cifs: fix crash due to race in hmac(md5) handling · eeeec288
      Rabin Vincent authored
      [ Upstream commit bd975d1e ]
      
      The secmech hmac(md5) structures are present in the TCP_Server_Info
      struct and can be shared among multiple CIFS sessions.  However, the
      server mutex is not currently held when these structures are allocated
      and used, which can lead to a kernel crashes, as in the scenario below:
      
      mount.cifs(8) #1				mount.cifs(8) #2
      
      Is secmech.sdeschmaccmd5 allocated?
      // false
      
      						Is secmech.sdeschmaccmd5 allocated?
      						// false
      
      secmech.hmacmd = crypto_alloc_shash..
      secmech.sdeschmaccmd5 = kzalloc..
      sdeschmaccmd5->shash.tfm = &secmec.hmacmd;
      
      						secmech.sdeschmaccmd5 = kzalloc
      						// sdeschmaccmd5->shash.tfm
      						// not yet assigned
      
      crypto_shash_update()
       deref NULL sdeschmaccmd5->shash.tfm
      
       Unable to handle kernel paging request at virtual address 00000030
       epc   : 8027ba34 crypto_shash_update+0x38/0x158
       ra    : 8020f2e8 setup_ntlmv2_rsp+0x4bc/0xa84
       Call Trace:
        crypto_shash_update+0x38/0x158
        setup_ntlmv2_rsp+0x4bc/0xa84
        build_ntlmssp_auth_blob+0xbc/0x34c
        sess_auth_rawntlmssp_authenticate+0xac/0x248
        CIFS_SessSetup+0xf0/0x178
        cifs_setup_session+0x4c/0x84
        cifs_get_smb_ses+0x2c8/0x314
        cifs_mount+0x38c/0x76c
        cifs_do_mount+0x98/0x440
        mount_fs+0x20/0xc0
        vfs_kern_mount+0x58/0x138
        do_mount+0x1e8/0xccc
        SyS_mount+0x88/0xd4
        syscall_common+0x30/0x54
      
      Fix this by locking the srv_mutex around the code which uses these
      hmac(md5) structures.  All the other secmech algos already have similar
      locking.
      
      Fixes: 95dc8dd1 ("Limit allocation of crypto mechanisms to dialect which requires")
      Signed-off-by: default avatarRabin Vincent <rabinv@axis.com>
      Acked-by: default avatarSachin Prabhu <sprabhu@redhat.com>
      CC: Stable <stable@vger.kernel.org>
      Signed-off-by: default avatarSteve French <smfrench@gmail.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      eeeec288
    • Nicholas Bellinger's avatar
      target: Fix race between iscsi-target connection shutdown + ABORT_TASK · cb0a0062
      Nicholas Bellinger authored
      [ Upstream commit 064cdd2d ]
      
      This patch fixes a race in iscsit_release_commands_from_conn() ->
      iscsit_free_cmd() -> transport_generic_free_cmd() + wait_for_tasks=1,
      where CMD_T_FABRIC_STOP could end up being set after the final
      kref_put() is called from core_tmr_abort_task() context.
      
      This results in transport_generic_free_cmd() blocking indefinately
      on se_cmd->cmd_wait_comp, because the target_release_cmd_kref()
      check for CMD_T_FABRIC_STOP returns false.
      
      To address this bug, make iscsit_release_commands_from_conn()
      do list_splice and set CMD_T_FABRIC_STOP early while holding
      iscsi_conn->cmd_lock.  Also make iscsit_aborted_task() only
      remove iscsi_cmd_t if CMD_T_FABRIC_STOP has not already been
      set.
      
      Finally in target_release_cmd_kref(), only honor fabric_stop
      if CMD_T_ABORTED has been set.
      
      Cc: Mike Christie <mchristi@redhat.com>
      Cc: Quinn Tran <quinn.tran@qlogic.com>
      Cc: Himanshu Madhani <himanshu.madhani@qlogic.com>
      Cc: Christoph Hellwig <hch@lst.de>
      Cc: Hannes Reinecke <hare@suse.de>
      Cc: stable@vger.kernel.org # 3.14+
      Tested-by: default avatarNicholas Bellinger <nab@linux-iscsi.org>
      Signed-off-by: default avatarNicholas Bellinger <nab@linux-iscsi.org>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      cb0a0062
    • Nicholas Bellinger's avatar
      target: Fix missing complete during ABORT_TASK + CMD_T_FABRIC_STOP · b4a8ca6b
      Nicholas Bellinger authored
      [ Upstream commit 5e2c956b ]
      
      During transport_generic_free_cmd() with a concurrent TMR
      ABORT_TASK and shutdown CMD_T_FABRIC_STOP bit set, the
      caller will be blocked on se_cmd->cmd_wait_stop completion
      until the final kref_put() -> target_release_cmd_kref()
      has been invoked to call complete().
      
      However, when ABORT_TASK is completed with FUNCTION_COMPLETE
      in core_tmr_abort_task(), the aborted se_cmd will have already
      been removed from se_sess->sess_cmd_list via list_del_init().
      
      This results in target_release_cmd_kref() hitting the
      legacy list_empty() == true check, invoking ->release_cmd()
      but skipping complete() to wakeup se_cmd->cmd_wait_stop
      blocked earlier in transport_generic_free_cmd() code.
      
      To address this bug, it's safe to go ahead and drop the
      original list_empty() check so that fabric_stop invokes
      the complete() as expected, since list_del_init() can
      safely be used on a empty list.
      
      Cc: Mike Christie <mchristi@redhat.com>
      Cc: Quinn Tran <quinn.tran@qlogic.com>
      Cc: Himanshu Madhani <himanshu.madhani@qlogic.com>
      Cc: Christoph Hellwig <hch@lst.de>
      Cc: Hannes Reinecke <hare@suse.de>
      Cc: stable@vger.kernel.org # 3.14+
      Tested-by: default avatarNicholas Bellinger <nab@linux-iscsi.org>
      Signed-off-by: default avatarNicholas Bellinger <nab@linux-iscsi.org>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      b4a8ca6b
    • Hector Palacios's avatar
      mtd: nand: fix bug writing 1 byte less than page size · bdcbb059
      Hector Palacios authored
      [ Upstream commit 144f4c98 ]
      
      nand_do_write_ops() determines if it is writing a partial page with the
      formula:
      	part_pagewr = (column || writelen < (mtd->writesize - 1))
      
      When 'writelen' is exactly 1 byte less than the NAND page size the formula
      equates to zero, so the code doesn't process it as a partial write,
      although it should.
      As a consequence the function remains in the while(1) loop with 'writelen'
      becoming 0xffffffff and iterating endlessly.
      
      The bug may not be easy to reproduce in Linux since user space tools
      usually force the padding or round-up the write size to a page-size
      multiple.
      This was discovered in U-Boot where the issue can be reproduced by
      writing any size that is 1 byte less than a page-size multiple.
      For example, on a NAND with 2K page (0x800):
      	=> nand erase.part <partition>
      	=> nand write $loadaddr <partition> 7ff
      
      [Editor's note: the bug was added in commit 29072b96, but moved
      around in commit 66507c7b ("mtd: nand: Add support to use nand_base
      poi databuf as bounce buffer")]
      
      Fixes: 29072b96 ("[MTD] NAND: add subpage write support")
      Signed-off-by: default avatarHector Palacios <hector.palacios@digi.com>
      Acked-by: default avatarBoris Brezillon <boris.brezillon@free-electrons.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarBrian Norris <computersforpeace@gmail.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      bdcbb059
    • Will Deacon's avatar
      arm64: debug: unmask PSTATE.D earlier · 8317c7f7
      Will Deacon authored
      [ Upstream commit 2ce39ad1 ]
      
      Clearing PSTATE.D is one of the requirements for generating a debug
      exception. The arm64 booting protocol requires that PSTATE.D is set,
      since many of the debug registers (for example, the hw_breakpoint
      registers) are UNKNOWN out of reset and could potentially generate
      spurious, fatal debug exceptions in early boot code if PSTATE.D was
      clear. Once the debug registers have been safely initialised, PSTATE.D
      is cleared, however this is currently broken for two reasons:
      
      (1) The boot CPU clears PSTATE.D in a postcore_initcall and secondary
          CPUs clear PSTATE.D in secondary_start_kernel. Since the initcall
          runs after SMP (and the scheduler) have been initialised, there is
          no guarantee that it is actually running on the boot CPU. In this
          case, the boot CPU is left with PSTATE.D set and is not capable of
          generating debug exceptions.
      
      (2) In a preemptible kernel, we may explicitly schedule on the IRQ
          return path to EL1. If an IRQ occurs with PSTATE.D set in the idle
          thread, then we may schedule the kthread_init thread, run the
          postcore_initcall to clear PSTATE.D and then context switch back
          to the idle thread before returning from the IRQ. The exception
          return path will then restore PSTATE.D from the stack, and set it
          again.
      
      This patch fixes the problem by moving the clearing of PSTATE.D earlier
      to proc.S. This has the desirable effect of clearing it in one place for
      all CPUs, long before we have to worry about the scheduler or any
      exception handling. We ensure that the previous reset of MDSCR_EL1 has
      completed before unmasking the exception, so that any spurious
      exceptions resulting from UNKNOWN debug registers are not generated.
      
      Without this patch applied, the kprobes selftests have been seen to fail
      under KVM, where we end up attempting to step the OOL instruction buffer
      with PSTATE.D set and therefore fail to complete the step.
      
      Cc: <stable@vger.kernel.org>
      Acked-by: default avatarMark Rutland <mark.rutland@arm.com>
      Reported-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      Tested-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      Reviewed-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      Tested-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      8317c7f7