1. 15 Sep, 2016 13 commits
  2. 12 Sep, 2016 17 commits
  3. 11 Sep, 2016 1 commit
  4. 07 Sep, 2016 1 commit
    • Ian Abbott's avatar
      staging: comedi: comedi_test: fix timer race conditions · 871499e3
      Ian Abbott authored
      [ commit 403fe7f3 upstream.
      
        Patch is cut down a bit from upstream patch, as upstream patch fixed
        parts that don't exist in this version.  Also, some identifiers were
        renamed, so patch description has been edited accordingly
        -- Ian Abbott
      ]
      
      Commit 73e0e4df ("staging: comedi: comedi_test: fix timer lock-up")
      fixed a lock-up in the timer routine `waveform_ai_interrupt()` caused by
      commit 24051247 ("staging: comedi: comedi_test: use
      comedi_handle_events()").  However, it introduced a race condition that
      can result in the timer routine misbehaving, such as accessing freed
      memory or dereferencing a NULL pointer.
      
      73e0... changed the timer routine to do nothing unless a
      `WAVEFORM_AI_RUNNING` flag was set, and changed `waveform_ai_cancel()`
      to clear the flag and replace a call to `del_timer_sync()` with a call
      to `del_timer()`.  `waveform_ai_cancel()` may be called from the timer
      routine itself (via `comedi_handle_events()`), or from `do_cancel()`.
      (`do_cancel()` is called as a result of a file operation (usually a
      `COMEDI_CANCEL` ioctl command, or a release), or during device removal.)
      When called from `do_cancel()`, the call to `waveform_ai_cancel()` is
      followed by a call to `do_become_nonbusy()`, which frees up stuff for
      the current asynchronous command under the assumption that it is now
      safe to do so.  The race condition occurs when the timer routine
      `waveform_ai_interrupt()` checks the `WAVEFORM_AI_RUNNING` flag just
      before it is cleared by `waveform_ai_cancel()`, and is still running
      during the call to `do_become_nonbusy()`.  In particular, it can lead to
      a NULL pointer dereference because `do_become_nonbusy()` frees
      `async->cmd.chanlist` and sets it to `NULL`, but
      `waveform_ai_interrupt()` dereferences it.
      
      Fix the race by calling `del_timer_sync()` instead of `del_timer()` in
      `waveform_ai_cancel()` when not in an interrupt context.  The only time
      `waveform_ai_cancel()` is called in an interrupt context is when it is
      called from the timer routine itself, via `comedi_handle_events()`.
      
      There is no longer any need for the `WAVEFORM_AI_RUNNING` flag, so get
      rid of it.
      
      Fixes: 73e0e4df ("staging: comedi: comedi_test: fix timer lock-up")
      Reported-by: default avatarÉric Piel <piel@delmic.com>
      Signed-off-by: default avatarIan Abbott <abbotti@mev.co.uk>
      Cc: Éric Piel <piel@delmic.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      871499e3
  5. 03 Sep, 2016 6 commits
  6. 31 Aug, 2016 2 commits
    • Vegard Nossum's avatar
      fs/seq_file: fix out-of-bounds read · f7bb9ba3
      Vegard Nossum authored
      [ Upstream commit 088bf2ff ]
      
      seq_read() is a nasty piece of work, not to mention buggy.
      
      It has (I think) an old bug which allows unprivileged userspace to read
      beyond the end of m->buf.
      
      I was getting these:
      
          BUG: KASAN: slab-out-of-bounds in seq_read+0xcd2/0x1480 at addr ffff880116889880
          Read of size 2713 by task trinity-c2/1329
          CPU: 2 PID: 1329 Comm: trinity-c2 Not tainted 4.8.0-rc1+ #96
          Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.9.3-0-ge2fc41e-prebuilt.qemu-project.org 04/01/2014
          Call Trace:
            kasan_object_err+0x1c/0x80
            kasan_report_error+0x2cb/0x7e0
            kasan_report+0x4e/0x80
            check_memory_region+0x13e/0x1a0
            kasan_check_read+0x11/0x20
            seq_read+0xcd2/0x1480
            proc_reg_read+0x10b/0x260
            do_loop_readv_writev.part.5+0x140/0x2c0
            do_readv_writev+0x589/0x860
            vfs_readv+0x7b/0xd0
            do_readv+0xd8/0x2c0
            SyS_readv+0xb/0x10
            do_syscall_64+0x1b3/0x4b0
            entry_SYSCALL64_slow_path+0x25/0x25
          Object at ffff880116889100, in cache kmalloc-4096 size: 4096
          Allocated:
          PID = 1329
            save_stack_trace+0x26/0x80
            save_stack+0x46/0xd0
            kasan_kmalloc+0xad/0xe0
            __kmalloc+0x1aa/0x4a0
            seq_buf_alloc+0x35/0x40
            seq_read+0x7d8/0x1480
            proc_reg_read+0x10b/0x260
            do_loop_readv_writev.part.5+0x140/0x2c0
            do_readv_writev+0x589/0x860
            vfs_readv+0x7b/0xd0
            do_readv+0xd8/0x2c0
            SyS_readv+0xb/0x10
            do_syscall_64+0x1b3/0x4b0
            return_from_SYSCALL_64+0x0/0x6a
          Freed:
          PID = 0
          (stack is not available)
          Memory state around the buggy address:
           ffff88011688a000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
           ffff88011688a080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
          >ffff88011688a100: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
      		       ^
           ffff88011688a180: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
           ffff88011688a200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
          ==================================================================
          Disabling lock debugging due to kernel taint
      
      This seems to be the same thing that Dave Jones was seeing here:
      
        https://lkml.org/lkml/2016/8/12/334
      
      There are multiple issues here:
      
        1) If we enter the function with a non-empty buffer, there is an attempt
           to flush it. But it was not clearing m->from after doing so, which
           means that if we try to do this flush twice in a row without any call
           to traverse() in between, we are going to be reading from the wrong
           place -- the splat above, fixed by this patch.
      
        2) If there's a short write to userspace because of page faults, the
           buffer may already contain multiple lines (i.e. pos has advanced by
           more than 1), but we don't save the progress that was made so the
           next call will output what we've already returned previously. Since
           that is a much less serious issue (and I have a headache after
           staring at seq_read() for the past 8 hours), I'll leave that for now.
      
      Link: http://lkml.kernel.org/r/1471447270-32093-1-git-send-email-vegard.nossum@oracle.comSigned-off-by: default avatarVegard Nossum <vegard.nossum@oracle.com>
      Reported-by: default avatarDave Jones <davej@codemonkey.org.uk>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      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>
      f7bb9ba3
    • Chen-Yu Tsai's avatar
      clocksource/drivers/sun4i: Clear interrupts after stopping timer in probe function · 942d5c08
      Chen-Yu Tsai authored
      [ Upstream commit b53e7d00 ]
      
      The bootloader (U-boot) sometimes uses this timer for various delays.
      It uses it as a ongoing counter, and does comparisons on the current
      counter value. The timer counter is never stopped.
      
      In some cases when the user interacts with the bootloader, or lets
      it idle for some time before loading Linux, the timer may expire,
      and an interrupt will be pending. This results in an unexpected
      interrupt when the timer interrupt is enabled by the kernel, at
      which point the event_handler isn't set yet. This results in a NULL
      pointer dereference exception, panic, and no way to reboot.
      
      Clear any pending interrupts after we stop the timer in the probe
      function to avoid this.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarChen-Yu Tsai <wens@csie.org>
      Signed-off-by: default avatarDaniel Lezcano <daniel.lezcano@linaro.org>
      Acked-by: default avatarMaxime Ripard <maxime.ripard@free-electrons.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      942d5c08