1. 13 Nov, 2017 1 commit
  2. 09 Nov, 2017 1 commit
  3. 07 Nov, 2017 1 commit
    • Takashi Iwai's avatar
      ALSA: seq: Fix OSS sysex delivery in OSS emulation · 132d358b
      Takashi Iwai authored
      The SYSEX event delivery in OSS sequencer emulation assumed that the
      event is encoded in the variable-length data with the straight
      buffering.  This was the normal behavior in the past, but during the
      development, the chained buffers were introduced for carrying more
      data, while the OSS code was left intact.  As a result, when a SYSEX
      event with the chained buffer data is passed to OSS sequencer port,
      it may end up with the wrong memory access, as if it were having a too
      large buffer.
      
      This patch addresses the bug, by applying the buffer data expansion by
      the generic snd_seq_dump_var_event() helper function.
      Reported-by: default avatarsyzbot <syzkaller@googlegroups.com>
      Reported-by: default avatarMark Salyzyn <salyzyn@android.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      132d358b
  4. 06 Nov, 2017 5 commits
    • Takashi Iwai's avatar
      ALSA: seq: Avoid invalid lockdep class warning · 3510c7aa
      Takashi Iwai authored
      The recent fix for adding rwsem nesting annotation was using the given
      "hop" argument as the lock subclass key.  Although the idea itself
      works, it may trigger a kernel warning like:
        BUG: looking up invalid subclass: 8
        ....
      since the lockdep has a smaller number of subclasses (8) than we
      currently allow for the hops there (10).
      
      The current definition is merely a sanity check for avoiding the too
      deep delivery paths, and the 8 hops are already enough.  So, as a
      quick fix, just follow the max hops as same as the max lockdep
      subclasses.
      
      Fixes: 1f20f9ff ("ALSA: seq: Fix nested rwsem annotation for lockdep splat")
      Reported-by: default avatarsyzbot <syzkaller@googlegroups.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      3510c7aa
    • Konstantinos Tsimpoukas's avatar
    • Takashi Iwai's avatar
      Merge branch 'topic/usb-ep-check-v2' into for-next · aed328fe
      Takashi Iwai authored
      Pull another fix of URB EP type check.
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      aed328fe
    • Takashi Iwai's avatar
      ALSA: usx2y: Fix invalid stream URBs · f9a1c372
      Takashi Iwai authored
      The us122l driver creates URBs per the fixed endpoints, and this may
      end up with URBs with inconsistent pipes when a fuzzer or a malicious
      program deals with the manipulated endpoints.  It ends up with a
      kernel warning like:
      
        usb 1-1: BOGUS urb xfer, pipe 0 != type 3
        ------------[ cut here ]------------
        WARNING: CPU: 0 PID: 24 at drivers/usb/core/urb.c:471
        usb_submit_urb+0x113e/0x1400
        Call Trace:
         usb_stream_start+0x48a/0x9f0 sound/usb/usx2y/usb_stream.c:690
         us122l_start+0x116/0x290 sound/usb/usx2y/us122l.c:365
         us122l_create_card sound/usb/usx2y/us122l.c:502
         us122l_usb_probe sound/usb/usx2y/us122l.c:588
         ....
      
      For avoiding the bad access, this patch adds a few sanity checks of
      the validity of created URBs like previous similar fixes using the new
      usb_urb_ep_type_check() helper function.
      Reported-by: default avatarAndrey Konovalov <andreyknvl@google.com>
      Tested-by: default avatarAndrey Konovalov <andreyknvl@google.com>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      f9a1c372
    • Takashi Iwai's avatar
      ALSA: timer: Limit max instances per timer · 9b7d869e
      Takashi Iwai authored
      Currently we allow unlimited number of timer instances, and it may
      bring the system hogging way too much CPU when too many timer
      instances are opened and processed concurrently.  This may end up with
      a soft-lockup report as triggered by syzkaller, especially when
      hrtimer backend is deployed.
      
      Since such insane number of instances aren't demanded by the normal
      use case of ALSA sequencer and it merely  opens a risk only for abuse,
      this patch introduces the upper limit for the number of instances per
      timer backend.  As default, it's set to 1000, but for the fine-grained
      timer like hrtimer, it's set to 100.
      
      Reported-by: syzbot
      Tested-by: default avatarJérôme Glisse <jglisse@redhat.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      9b7d869e
  5. 02 Nov, 2017 1 commit
  6. 01 Nov, 2017 2 commits
  7. 31 Oct, 2017 3 commits
  8. 30 Oct, 2017 1 commit
  9. 29 Oct, 2017 25 commits