1. 07 11月, 2017 2 次提交
    • T
      ALSA: seq: Fix OSS sysex delivery in OSS emulation · 132d358b
      Takashi Iwai 提交于
      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: Nsyzbot <syzkaller@googlegroups.com>
      Reported-by: NMark Salyzyn <salyzyn@android.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      132d358b
    • T
      ALSA: seq: Avoid invalid lockdep class warning · 3510c7aa
      Takashi Iwai 提交于
      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: Nsyzbot <syzkaller@googlegroups.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      3510c7aa
  2. 06 11月, 2017 1 次提交
    • T
      ALSA: timer: Limit max instances per timer · 9b7d869e
      Takashi Iwai 提交于
      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: NJérôme Glisse <jglisse@redhat.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      9b7d869e
  3. 02 11月, 2017 2 次提交
  4. 01 11月, 2017 1 次提交
  5. 31 10月, 2017 2 次提交
  6. 30 10月, 2017 1 次提交
  7. 29 10月, 2017 31 次提交
新手
引导
客服 返回
顶部