<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/sound, branch v3.12.65</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>ALSA: ali5451: Fix out-of-bound position reporting</title>
<updated>2016-10-17T07:46:19+00:00</updated>
<author>
<name>Takashi Iwai</name>
<email>tiwai@suse.de</email>
</author>
<published>2016-09-21T12:38:02+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=b3b34980847468b6bb0b26b3909e514a1c47d383'/>
<id>b3b34980847468b6bb0b26b3909e514a1c47d383</id>
<content type='text'>
commit db68577966abc1aeae4ec597b3dcfa0d56e92041 upstream.

The pointer callbacks of ali5451 driver may return the value at the
boundary occasionally, and it results in the kernel warning like
  snd_ali5451 0000:00:06.0: BUG: , pos = 16384, buffer size = 16384, period size = 1024

It seems that folding the position offset is enough for fixing the
warning and no ill-effect has been seen by that.

Reported-by: Enrico Mioso &lt;mrkiko.rs@gmail.com&gt;
Tested-by: Enrico Mioso &lt;mrkiko.rs@gmail.com&gt;
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit db68577966abc1aeae4ec597b3dcfa0d56e92041 upstream.

The pointer callbacks of ali5451 driver may return the value at the
boundary occasionally, and it results in the kernel warning like
  snd_ali5451 0000:00:06.0: BUG: , pos = 16384, buffer size = 16384, period size = 1024

It seems that folding the position offset is enough for fixing the
warning and no ill-effect has been seen by that.

Reported-by: Enrico Mioso &lt;mrkiko.rs@gmail.com&gt;
Tested-by: Enrico Mioso &lt;mrkiko.rs@gmail.com&gt;
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>ASoC: omap-mcpdm: Fix irq resource handling</title>
<updated>2016-10-07T08:06:55+00:00</updated>
<author>
<name>Peter Ujfalusi</name>
<email>peter.ujfalusi@ti.com</email>
</author>
<published>2016-08-23T07:27:19+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=fd4d32067be5014cff77c8f4c61c395ee7248ab9'/>
<id>fd4d32067be5014cff77c8f4c61c395ee7248ab9</id>
<content type='text'>
commit a8719670687c46ed2e904c0d05fa4cd7e4950cd1 upstream.

Fixes: ddd17531ad908 ("ASoC: omap-mcpdm: Clean up with devm_* function")

Managed irq request will not doing any good in ASoC probe level as it is
not going to free up the irq when the driver is unbound from the sound
card.

Signed-off-by: Peter Ujfalusi &lt;peter.ujfalusi@ti.com&gt;
Reported-by: Russell King &lt;linux@armlinux.org.uk&gt;
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit a8719670687c46ed2e904c0d05fa4cd7e4950cd1 upstream.

Fixes: ddd17531ad908 ("ASoC: omap-mcpdm: Clean up with devm_* function")

Managed irq request will not doing any good in ASoC probe level as it is
not going to free up the irq when the driver is unbound from the sound
card.

Signed-off-by: Peter Ujfalusi &lt;peter.ujfalusi@ti.com&gt;
Reported-by: Russell King &lt;linux@armlinux.org.uk&gt;
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>ALSA: timer: fix NULL pointer dereference on memory allocation failure</title>
<updated>2016-09-29T09:14:16+00:00</updated>
<author>
<name>Vegard Nossum</name>
<email>vegard.nossum@oracle.com</email>
</author>
<published>2016-08-28T22:33:51+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=bca643b27d59c303f431714b763404b7f531b181'/>
<id>bca643b27d59c303f431714b763404b7f531b181</id>
<content type='text'>
commit 8ddc05638ee42b18ba4fe99b5fb647fa3ad20456 upstream.

I hit this with syzkaller:

    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: 0 PID: 1327 Comm: a.out Not tainted 4.8.0-rc2+ #190
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.9.3-0-ge2fc41e-prebuilt.qemu-project.org 04/01/2014
    task: ffff88011278d600 task.stack: ffff8801120c0000
    RIP: 0010:[&lt;ffffffff82c8ba07&gt;]  [&lt;ffffffff82c8ba07&gt;] snd_hrtimer_start+0x77/0x100
    RSP: 0018:ffff8801120c7a60  EFLAGS: 00010006
    RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000007
    RDX: 0000000000000009 RSI: 1ffff10023483091 RDI: 0000000000000048
    RBP: ffff8801120c7a78 R08: ffff88011a5cf768 R09: ffff88011a5ba790
    R10: 0000000000000002 R11: ffffed00234b9ef1 R12: ffff880114843980
    R13: ffffffff84213c00 R14: ffff880114843ab0 R15: 0000000000000286
    FS:  00007f72958f3700(0000) GS:ffff88011aa00000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 0000000000603001 CR3: 00000001126ab000 CR4: 00000000000006f0
    Stack:
     ffff880114843980 ffff880111eb2dc0 ffff880114843a34 ffff8801120c7ad0
     ffffffff82c81ab1 0000000000000000 ffffffff842138e0 0000000100000000
     ffff880111eb2dd0 ffff880111eb2dc0 0000000000000001 ffff880111eb2dc0
    Call Trace:
     [&lt;ffffffff82c81ab1&gt;] snd_timer_start1+0x331/0x670
     [&lt;ffffffff82c85bfd&gt;] snd_timer_start+0x5d/0xa0
     [&lt;ffffffff82c8795e&gt;] snd_timer_user_ioctl+0x88e/0x2830
     [&lt;ffffffff8159f3a0&gt;] ? __follow_pte.isra.49+0x430/0x430
     [&lt;ffffffff82c870d0&gt;] ? snd_timer_pause+0x80/0x80
     [&lt;ffffffff815a26fa&gt;] ? do_wp_page+0x3aa/0x1c90
     [&lt;ffffffff8132762f&gt;] ? put_prev_entity+0x108f/0x21a0
     [&lt;ffffffff82c870d0&gt;] ? snd_timer_pause+0x80/0x80
     [&lt;ffffffff816b0733&gt;] do_vfs_ioctl+0x193/0x1050
     [&lt;ffffffff813510af&gt;] ? cpuacct_account_field+0x12f/0x1a0
     [&lt;ffffffff816b05a0&gt;] ? ioctl_preallocate+0x200/0x200
     [&lt;ffffffff81002f2f&gt;] ? syscall_trace_enter+0x3cf/0xdb0
     [&lt;ffffffff815045ba&gt;] ? __context_tracking_exit.part.4+0x9a/0x1e0
     [&lt;ffffffff81002b60&gt;] ? exit_to_usermode_loop+0x190/0x190
     [&lt;ffffffff82001a97&gt;] ? check_preemption_disabled+0x37/0x1e0
     [&lt;ffffffff81d93889&gt;] ? security_file_ioctl+0x89/0xb0
     [&lt;ffffffff816b167f&gt;] SyS_ioctl+0x8f/0xc0
     [&lt;ffffffff816b15f0&gt;] ? do_vfs_ioctl+0x1050/0x1050
     [&lt;ffffffff81005524&gt;] do_syscall_64+0x1c4/0x4e0
     [&lt;ffffffff83c32b2a&gt;] entry_SYSCALL64_slow_path+0x25/0x25
    Code: c7 c7 c4 b9 c8 82 48 89 d9 4c 89 ee e8 63 88 7f fe e8 7e 46 7b fe 48 8d 7b 48 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 &lt;0f&gt; b6 04 02 84 c0 74 04 84 c0 7e 65 80 7b 48 00 74 0e e8 52 46
    RIP  [&lt;ffffffff82c8ba07&gt;] snd_hrtimer_start+0x77/0x100
     RSP &lt;ffff8801120c7a60&gt;
    ---[ end trace 5955b08db7f2b029 ]---

This can happen if snd_hrtimer_open() fails to allocate memory and
returns an error, which is currently not checked by snd_timer_open():

    ioctl(SNDRV_TIMER_IOCTL_SELECT)
     - snd_timer_user_tselect()
	- snd_timer_close()
	   - snd_hrtimer_close()
	      - (struct snd_timer *) t-&gt;private_data = NULL
        - snd_timer_open()
           - snd_hrtimer_open()
              - kzalloc() fails; t-&gt;private_data is still NULL

    ioctl(SNDRV_TIMER_IOCTL_START)
     - snd_timer_user_start()
	- snd_timer_start()
	   - snd_timer_start1()
	      - snd_hrtimer_start()
		- t-&gt;private_data == NULL // boom

[js] no put_device in 3.12 yet

Signed-off-by: Vegard Nossum &lt;vegard.nossum@oracle.com&gt;
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 8ddc05638ee42b18ba4fe99b5fb647fa3ad20456 upstream.

I hit this with syzkaller:

    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: 0 PID: 1327 Comm: a.out Not tainted 4.8.0-rc2+ #190
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.9.3-0-ge2fc41e-prebuilt.qemu-project.org 04/01/2014
    task: ffff88011278d600 task.stack: ffff8801120c0000
    RIP: 0010:[&lt;ffffffff82c8ba07&gt;]  [&lt;ffffffff82c8ba07&gt;] snd_hrtimer_start+0x77/0x100
    RSP: 0018:ffff8801120c7a60  EFLAGS: 00010006
    RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000007
    RDX: 0000000000000009 RSI: 1ffff10023483091 RDI: 0000000000000048
    RBP: ffff8801120c7a78 R08: ffff88011a5cf768 R09: ffff88011a5ba790
    R10: 0000000000000002 R11: ffffed00234b9ef1 R12: ffff880114843980
    R13: ffffffff84213c00 R14: ffff880114843ab0 R15: 0000000000000286
    FS:  00007f72958f3700(0000) GS:ffff88011aa00000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 0000000000603001 CR3: 00000001126ab000 CR4: 00000000000006f0
    Stack:
     ffff880114843980 ffff880111eb2dc0 ffff880114843a34 ffff8801120c7ad0
     ffffffff82c81ab1 0000000000000000 ffffffff842138e0 0000000100000000
     ffff880111eb2dd0 ffff880111eb2dc0 0000000000000001 ffff880111eb2dc0
    Call Trace:
     [&lt;ffffffff82c81ab1&gt;] snd_timer_start1+0x331/0x670
     [&lt;ffffffff82c85bfd&gt;] snd_timer_start+0x5d/0xa0
     [&lt;ffffffff82c8795e&gt;] snd_timer_user_ioctl+0x88e/0x2830
     [&lt;ffffffff8159f3a0&gt;] ? __follow_pte.isra.49+0x430/0x430
     [&lt;ffffffff82c870d0&gt;] ? snd_timer_pause+0x80/0x80
     [&lt;ffffffff815a26fa&gt;] ? do_wp_page+0x3aa/0x1c90
     [&lt;ffffffff8132762f&gt;] ? put_prev_entity+0x108f/0x21a0
     [&lt;ffffffff82c870d0&gt;] ? snd_timer_pause+0x80/0x80
     [&lt;ffffffff816b0733&gt;] do_vfs_ioctl+0x193/0x1050
     [&lt;ffffffff813510af&gt;] ? cpuacct_account_field+0x12f/0x1a0
     [&lt;ffffffff816b05a0&gt;] ? ioctl_preallocate+0x200/0x200
     [&lt;ffffffff81002f2f&gt;] ? syscall_trace_enter+0x3cf/0xdb0
     [&lt;ffffffff815045ba&gt;] ? __context_tracking_exit.part.4+0x9a/0x1e0
     [&lt;ffffffff81002b60&gt;] ? exit_to_usermode_loop+0x190/0x190
     [&lt;ffffffff82001a97&gt;] ? check_preemption_disabled+0x37/0x1e0
     [&lt;ffffffff81d93889&gt;] ? security_file_ioctl+0x89/0xb0
     [&lt;ffffffff816b167f&gt;] SyS_ioctl+0x8f/0xc0
     [&lt;ffffffff816b15f0&gt;] ? do_vfs_ioctl+0x1050/0x1050
     [&lt;ffffffff81005524&gt;] do_syscall_64+0x1c4/0x4e0
     [&lt;ffffffff83c32b2a&gt;] entry_SYSCALL64_slow_path+0x25/0x25
    Code: c7 c7 c4 b9 c8 82 48 89 d9 4c 89 ee e8 63 88 7f fe e8 7e 46 7b fe 48 8d 7b 48 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 &lt;0f&gt; b6 04 02 84 c0 74 04 84 c0 7e 65 80 7b 48 00 74 0e e8 52 46
    RIP  [&lt;ffffffff82c8ba07&gt;] snd_hrtimer_start+0x77/0x100
     RSP &lt;ffff8801120c7a60&gt;
    ---[ end trace 5955b08db7f2b029 ]---

This can happen if snd_hrtimer_open() fails to allocate memory and
returns an error, which is currently not checked by snd_timer_open():

    ioctl(SNDRV_TIMER_IOCTL_SELECT)
     - snd_timer_user_tselect()
	- snd_timer_close()
	   - snd_hrtimer_close()
	      - (struct snd_timer *) t-&gt;private_data = NULL
        - snd_timer_open()
           - snd_hrtimer_open()
              - kzalloc() fails; t-&gt;private_data is still NULL

    ioctl(SNDRV_TIMER_IOCTL_START)
     - snd_timer_user_start()
	- snd_timer_start()
	   - snd_timer_start1()
	      - snd_hrtimer_start()
		- t-&gt;private_data == NULL // boom

[js] no put_device in 3.12 yet

Signed-off-by: Vegard Nossum &lt;vegard.nossum@oracle.com&gt;
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ALSA: timer: fix division by zero after SNDRV_TIMER_IOCTL_CONTINUE</title>
<updated>2016-09-29T09:14:16+00:00</updated>
<author>
<name>Vegard Nossum</name>
<email>vegard.nossum@oracle.com</email>
</author>
<published>2016-08-28T22:33:50+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=f3b1afe3c30fe99c982b2dec9adcad6450cd58ec'/>
<id>f3b1afe3c30fe99c982b2dec9adcad6450cd58ec</id>
<content type='text'>
commit 6b760bb2c63a9e322c0e4a0b5daf335ad93d5a33 upstream.

I got this:

    divide error: 0000 [#1] PREEMPT SMP KASAN
    CPU: 1 PID: 1327 Comm: a.out Not tainted 4.8.0-rc2+ #189
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.9.3-0-ge2fc41e-prebuilt.qemu-project.org 04/01/2014
    task: ffff8801120a9580 task.stack: ffff8801120b0000
    RIP: 0010:[&lt;ffffffff82c8bd9a&gt;]  [&lt;ffffffff82c8bd9a&gt;] snd_hrtimer_callback+0x1da/0x3f0
    RSP: 0018:ffff88011aa87da8  EFLAGS: 00010006
    RAX: 0000000000004f76 RBX: ffff880112655e88 RCX: 0000000000000000
    RDX: 0000000000000000 RSI: ffff880112655ea0 RDI: 0000000000000001
    RBP: ffff88011aa87e00 R08: ffff88013fff905c R09: ffff88013fff9048
    R10: ffff88013fff9050 R11: 00000001050a7b8c R12: ffff880114778a00
    R13: ffff880114778ab4 R14: ffff880114778b30 R15: 0000000000000000
    FS:  00007f071647c700(0000) GS:ffff88011aa80000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 0000000000603001 CR3: 0000000112021000 CR4: 00000000000006e0
    Stack:
     0000000000000000 ffff880114778ab8 ffff880112655ea0 0000000000004f76
     ffff880112655ec8 ffff880112655e80 ffff880112655e88 ffff88011aa98fc0
     00000000b97ccf2b dffffc0000000000 ffff88011aa98fc0 ffff88011aa87ef0
    Call Trace:
     &lt;IRQ&gt;
     [&lt;ffffffff813abce7&gt;] __hrtimer_run_queues+0x347/0xa00
     [&lt;ffffffff82c8bbc0&gt;] ? snd_hrtimer_close+0x130/0x130
     [&lt;ffffffff813ab9a0&gt;] ? retrigger_next_event+0x1b0/0x1b0
     [&lt;ffffffff813ae1a6&gt;] ? hrtimer_interrupt+0x136/0x4b0
     [&lt;ffffffff813ae220&gt;] hrtimer_interrupt+0x1b0/0x4b0
     [&lt;ffffffff8120f91e&gt;] local_apic_timer_interrupt+0x6e/0xf0
     [&lt;ffffffff81227ad3&gt;] ? kvm_guest_apic_eoi_write+0x13/0xc0
     [&lt;ffffffff83c35086&gt;] smp_apic_timer_interrupt+0x76/0xa0
     [&lt;ffffffff83c3416c&gt;] apic_timer_interrupt+0x8c/0xa0
     &lt;EOI&gt;
     [&lt;ffffffff83c3239c&gt;] ? _raw_spin_unlock_irqrestore+0x2c/0x60
     [&lt;ffffffff82c8185d&gt;] snd_timer_start1+0xdd/0x670
     [&lt;ffffffff82c87015&gt;] snd_timer_continue+0x45/0x80
     [&lt;ffffffff82c88100&gt;] snd_timer_user_ioctl+0x1030/0x2830
     [&lt;ffffffff8159f3a0&gt;] ? __follow_pte.isra.49+0x430/0x430
     [&lt;ffffffff82c870d0&gt;] ? snd_timer_pause+0x80/0x80
     [&lt;ffffffff815a26fa&gt;] ? do_wp_page+0x3aa/0x1c90
     [&lt;ffffffff815aa4f8&gt;] ? handle_mm_fault+0xbc8/0x27f0
     [&lt;ffffffff815a9930&gt;] ? __pmd_alloc+0x370/0x370
     [&lt;ffffffff82c870d0&gt;] ? snd_timer_pause+0x80/0x80
     [&lt;ffffffff816b0733&gt;] do_vfs_ioctl+0x193/0x1050
     [&lt;ffffffff816b05a0&gt;] ? ioctl_preallocate+0x200/0x200
     [&lt;ffffffff81002f2f&gt;] ? syscall_trace_enter+0x3cf/0xdb0
     [&lt;ffffffff815045ba&gt;] ? __context_tracking_exit.part.4+0x9a/0x1e0
     [&lt;ffffffff81002b60&gt;] ? exit_to_usermode_loop+0x190/0x190
     [&lt;ffffffff82001a97&gt;] ? check_preemption_disabled+0x37/0x1e0
     [&lt;ffffffff81d93889&gt;] ? security_file_ioctl+0x89/0xb0
     [&lt;ffffffff816b167f&gt;] SyS_ioctl+0x8f/0xc0
     [&lt;ffffffff816b15f0&gt;] ? do_vfs_ioctl+0x1050/0x1050
     [&lt;ffffffff81005524&gt;] do_syscall_64+0x1c4/0x4e0
     [&lt;ffffffff83c32b2a&gt;] entry_SYSCALL64_slow_path+0x25/0x25
    Code: e8 fc 42 7b fe 8b 0d 06 8a 50 03 49 0f af cf 48 85 c9 0f 88 7c 01 00 00 48 89 4d a8 e8 e0 42 7b fe 48 8b 45 c0 48 8b 4d a8 48 99 &lt;48&gt; f7 f9 49 01 c7 e8 cb 42 7b fe 48 8b 55 d0 48 b8 00 00 00 00
    RIP  [&lt;ffffffff82c8bd9a&gt;] snd_hrtimer_callback+0x1da/0x3f0
     RSP &lt;ffff88011aa87da8&gt;
    ---[ end trace 6aa380f756a21074 ]---

The problem happens when you call ioctl(SNDRV_TIMER_IOCTL_CONTINUE) on a
completely new/unused timer -- it will have -&gt;sticks == 0, which causes a
divide by 0 in snd_hrtimer_callback().

Signed-off-by: Vegard Nossum &lt;vegard.nossum@oracle.com&gt;
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 6b760bb2c63a9e322c0e4a0b5daf335ad93d5a33 upstream.

I got this:

    divide error: 0000 [#1] PREEMPT SMP KASAN
    CPU: 1 PID: 1327 Comm: a.out Not tainted 4.8.0-rc2+ #189
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.9.3-0-ge2fc41e-prebuilt.qemu-project.org 04/01/2014
    task: ffff8801120a9580 task.stack: ffff8801120b0000
    RIP: 0010:[&lt;ffffffff82c8bd9a&gt;]  [&lt;ffffffff82c8bd9a&gt;] snd_hrtimer_callback+0x1da/0x3f0
    RSP: 0018:ffff88011aa87da8  EFLAGS: 00010006
    RAX: 0000000000004f76 RBX: ffff880112655e88 RCX: 0000000000000000
    RDX: 0000000000000000 RSI: ffff880112655ea0 RDI: 0000000000000001
    RBP: ffff88011aa87e00 R08: ffff88013fff905c R09: ffff88013fff9048
    R10: ffff88013fff9050 R11: 00000001050a7b8c R12: ffff880114778a00
    R13: ffff880114778ab4 R14: ffff880114778b30 R15: 0000000000000000
    FS:  00007f071647c700(0000) GS:ffff88011aa80000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 0000000000603001 CR3: 0000000112021000 CR4: 00000000000006e0
    Stack:
     0000000000000000 ffff880114778ab8 ffff880112655ea0 0000000000004f76
     ffff880112655ec8 ffff880112655e80 ffff880112655e88 ffff88011aa98fc0
     00000000b97ccf2b dffffc0000000000 ffff88011aa98fc0 ffff88011aa87ef0
    Call Trace:
     &lt;IRQ&gt;
     [&lt;ffffffff813abce7&gt;] __hrtimer_run_queues+0x347/0xa00
     [&lt;ffffffff82c8bbc0&gt;] ? snd_hrtimer_close+0x130/0x130
     [&lt;ffffffff813ab9a0&gt;] ? retrigger_next_event+0x1b0/0x1b0
     [&lt;ffffffff813ae1a6&gt;] ? hrtimer_interrupt+0x136/0x4b0
     [&lt;ffffffff813ae220&gt;] hrtimer_interrupt+0x1b0/0x4b0
     [&lt;ffffffff8120f91e&gt;] local_apic_timer_interrupt+0x6e/0xf0
     [&lt;ffffffff81227ad3&gt;] ? kvm_guest_apic_eoi_write+0x13/0xc0
     [&lt;ffffffff83c35086&gt;] smp_apic_timer_interrupt+0x76/0xa0
     [&lt;ffffffff83c3416c&gt;] apic_timer_interrupt+0x8c/0xa0
     &lt;EOI&gt;
     [&lt;ffffffff83c3239c&gt;] ? _raw_spin_unlock_irqrestore+0x2c/0x60
     [&lt;ffffffff82c8185d&gt;] snd_timer_start1+0xdd/0x670
     [&lt;ffffffff82c87015&gt;] snd_timer_continue+0x45/0x80
     [&lt;ffffffff82c88100&gt;] snd_timer_user_ioctl+0x1030/0x2830
     [&lt;ffffffff8159f3a0&gt;] ? __follow_pte.isra.49+0x430/0x430
     [&lt;ffffffff82c870d0&gt;] ? snd_timer_pause+0x80/0x80
     [&lt;ffffffff815a26fa&gt;] ? do_wp_page+0x3aa/0x1c90
     [&lt;ffffffff815aa4f8&gt;] ? handle_mm_fault+0xbc8/0x27f0
     [&lt;ffffffff815a9930&gt;] ? __pmd_alloc+0x370/0x370
     [&lt;ffffffff82c870d0&gt;] ? snd_timer_pause+0x80/0x80
     [&lt;ffffffff816b0733&gt;] do_vfs_ioctl+0x193/0x1050
     [&lt;ffffffff816b05a0&gt;] ? ioctl_preallocate+0x200/0x200
     [&lt;ffffffff81002f2f&gt;] ? syscall_trace_enter+0x3cf/0xdb0
     [&lt;ffffffff815045ba&gt;] ? __context_tracking_exit.part.4+0x9a/0x1e0
     [&lt;ffffffff81002b60&gt;] ? exit_to_usermode_loop+0x190/0x190
     [&lt;ffffffff82001a97&gt;] ? check_preemption_disabled+0x37/0x1e0
     [&lt;ffffffff81d93889&gt;] ? security_file_ioctl+0x89/0xb0
     [&lt;ffffffff816b167f&gt;] SyS_ioctl+0x8f/0xc0
     [&lt;ffffffff816b15f0&gt;] ? do_vfs_ioctl+0x1050/0x1050
     [&lt;ffffffff81005524&gt;] do_syscall_64+0x1c4/0x4e0
     [&lt;ffffffff83c32b2a&gt;] entry_SYSCALL64_slow_path+0x25/0x25
    Code: e8 fc 42 7b fe 8b 0d 06 8a 50 03 49 0f af cf 48 85 c9 0f 88 7c 01 00 00 48 89 4d a8 e8 e0 42 7b fe 48 8b 45 c0 48 8b 4d a8 48 99 &lt;48&gt; f7 f9 49 01 c7 e8 cb 42 7b fe 48 8b 55 d0 48 b8 00 00 00 00
    RIP  [&lt;ffffffff82c8bd9a&gt;] snd_hrtimer_callback+0x1da/0x3f0
     RSP &lt;ffff88011aa87da8&gt;
    ---[ end trace 6aa380f756a21074 ]---

The problem happens when you call ioctl(SNDRV_TIMER_IOCTL_CONTINUE) on a
completely new/unused timer -- it will have -&gt;sticks == 0, which causes a
divide by 0 in snd_hrtimer_callback().

Signed-off-by: Vegard Nossum &lt;vegard.nossum@oracle.com&gt;
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>ALSA: timer: fix NULL pointer dereference in read()/ioctl() race</title>
<updated>2016-09-29T09:14:15+00:00</updated>
<author>
<name>Vegard Nossum</name>
<email>vegard.nossum@oracle.com</email>
</author>
<published>2016-08-28T08:13:07+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=d244fbcc5ea46592d4f409c0418e8fe0be3d81ca'/>
<id>d244fbcc5ea46592d4f409c0418e8fe0be3d81ca</id>
<content type='text'>
commit 11749e086b2766cccf6217a527ef5c5604ba069c upstream.

I got this with syzkaller:

    ==================================================================
    BUG: KASAN: null-ptr-deref on address 0000000000000020
    Read of size 32 by task syz-executor/22519
    CPU: 1 PID: 22519 Comm: syz-executor Not tainted 4.8.0-rc2+ #169
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.9.3-0-ge2fc41e-prebuilt.qemu-project.org 04/01/2
    014
     0000000000000001 ffff880111a17a00 ffffffff81f9f141 ffff880111a17a90
     ffff880111a17c50 ffff880114584a58 ffff880114584a10 ffff880111a17a80
     ffffffff8161fe3f ffff880100000000 ffff880118d74a48 ffff880118d74a68
    Call Trace:
     [&lt;ffffffff81f9f141&gt;] dump_stack+0x83/0xb2
     [&lt;ffffffff8161fe3f&gt;] kasan_report_error+0x41f/0x4c0
     [&lt;ffffffff8161ff74&gt;] kasan_report+0x34/0x40
     [&lt;ffffffff82c84b54&gt;] ? snd_timer_user_read+0x554/0x790
     [&lt;ffffffff8161e79e&gt;] check_memory_region+0x13e/0x1a0
     [&lt;ffffffff8161e9c1&gt;] kasan_check_read+0x11/0x20
     [&lt;ffffffff82c84b54&gt;] snd_timer_user_read+0x554/0x790
     [&lt;ffffffff82c84600&gt;] ? snd_timer_user_info_compat.isra.5+0x2b0/0x2b0
     [&lt;ffffffff817d0831&gt;] ? proc_fault_inject_write+0x1c1/0x250
     [&lt;ffffffff817d0670&gt;] ? next_tgid+0x2a0/0x2a0
     [&lt;ffffffff8127c278&gt;] ? do_group_exit+0x108/0x330
     [&lt;ffffffff8174653a&gt;] ? fsnotify+0x72a/0xca0
     [&lt;ffffffff81674dfe&gt;] __vfs_read+0x10e/0x550
     [&lt;ffffffff82c84600&gt;] ? snd_timer_user_info_compat.isra.5+0x2b0/0x2b0
     [&lt;ffffffff81674cf0&gt;] ? do_sendfile+0xc50/0xc50
     [&lt;ffffffff81745e10&gt;] ? __fsnotify_update_child_dentry_flags+0x60/0x60
     [&lt;ffffffff8143fec6&gt;] ? kcov_ioctl+0x56/0x190
     [&lt;ffffffff81e5ada2&gt;] ? common_file_perm+0x2e2/0x380
     [&lt;ffffffff81746b0e&gt;] ? __fsnotify_parent+0x5e/0x2b0
     [&lt;ffffffff81d93536&gt;] ? security_file_permission+0x86/0x1e0
     [&lt;ffffffff816728f5&gt;] ? rw_verify_area+0xe5/0x2b0
     [&lt;ffffffff81675355&gt;] vfs_read+0x115/0x330
     [&lt;ffffffff81676371&gt;] SyS_read+0xd1/0x1a0
     [&lt;ffffffff816762a0&gt;] ? vfs_write+0x4b0/0x4b0
     [&lt;ffffffff82001c2c&gt;] ? __this_cpu_preempt_check+0x1c/0x20
     [&lt;ffffffff8150455a&gt;] ? __context_tracking_exit.part.4+0x3a/0x1e0
     [&lt;ffffffff816762a0&gt;] ? vfs_write+0x4b0/0x4b0
     [&lt;ffffffff81005524&gt;] do_syscall_64+0x1c4/0x4e0
     [&lt;ffffffff810052fc&gt;] ? syscall_return_slowpath+0x16c/0x1d0
     [&lt;ffffffff83c3276a&gt;] entry_SYSCALL64_slow_path+0x25/0x25
    ==================================================================

There are a couple of problems that I can see:

 - ioctl(SNDRV_TIMER_IOCTL_SELECT), which potentially sets
   tu-&gt;queue/tu-&gt;tqueue to NULL on memory allocation failure, so read()
   would get a NULL pointer dereference like the above splat

 - the same ioctl() can free tu-&gt;queue/to-&gt;tqueue which means read()
   could potentially see (and dereference) the freed pointer

We can fix both by taking the ioctl_lock mutex when dereferencing
-&gt;queue/-&gt;tqueue, since that's always held over all the ioctl() code.

Just looking at the code I find it likely that there are more problems
here such as tu-&gt;qhead pointing outside the buffer if the size is
changed concurrently using SNDRV_TIMER_IOCTL_PARAMS.

[js] unlock in fail paths

Signed-off-by: Vegard Nossum &lt;vegard.nossum@oracle.com&gt;
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 11749e086b2766cccf6217a527ef5c5604ba069c upstream.

I got this with syzkaller:

    ==================================================================
    BUG: KASAN: null-ptr-deref on address 0000000000000020
    Read of size 32 by task syz-executor/22519
    CPU: 1 PID: 22519 Comm: syz-executor Not tainted 4.8.0-rc2+ #169
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.9.3-0-ge2fc41e-prebuilt.qemu-project.org 04/01/2
    014
     0000000000000001 ffff880111a17a00 ffffffff81f9f141 ffff880111a17a90
     ffff880111a17c50 ffff880114584a58 ffff880114584a10 ffff880111a17a80
     ffffffff8161fe3f ffff880100000000 ffff880118d74a48 ffff880118d74a68
    Call Trace:
     [&lt;ffffffff81f9f141&gt;] dump_stack+0x83/0xb2
     [&lt;ffffffff8161fe3f&gt;] kasan_report_error+0x41f/0x4c0
     [&lt;ffffffff8161ff74&gt;] kasan_report+0x34/0x40
     [&lt;ffffffff82c84b54&gt;] ? snd_timer_user_read+0x554/0x790
     [&lt;ffffffff8161e79e&gt;] check_memory_region+0x13e/0x1a0
     [&lt;ffffffff8161e9c1&gt;] kasan_check_read+0x11/0x20
     [&lt;ffffffff82c84b54&gt;] snd_timer_user_read+0x554/0x790
     [&lt;ffffffff82c84600&gt;] ? snd_timer_user_info_compat.isra.5+0x2b0/0x2b0
     [&lt;ffffffff817d0831&gt;] ? proc_fault_inject_write+0x1c1/0x250
     [&lt;ffffffff817d0670&gt;] ? next_tgid+0x2a0/0x2a0
     [&lt;ffffffff8127c278&gt;] ? do_group_exit+0x108/0x330
     [&lt;ffffffff8174653a&gt;] ? fsnotify+0x72a/0xca0
     [&lt;ffffffff81674dfe&gt;] __vfs_read+0x10e/0x550
     [&lt;ffffffff82c84600&gt;] ? snd_timer_user_info_compat.isra.5+0x2b0/0x2b0
     [&lt;ffffffff81674cf0&gt;] ? do_sendfile+0xc50/0xc50
     [&lt;ffffffff81745e10&gt;] ? __fsnotify_update_child_dentry_flags+0x60/0x60
     [&lt;ffffffff8143fec6&gt;] ? kcov_ioctl+0x56/0x190
     [&lt;ffffffff81e5ada2&gt;] ? common_file_perm+0x2e2/0x380
     [&lt;ffffffff81746b0e&gt;] ? __fsnotify_parent+0x5e/0x2b0
     [&lt;ffffffff81d93536&gt;] ? security_file_permission+0x86/0x1e0
     [&lt;ffffffff816728f5&gt;] ? rw_verify_area+0xe5/0x2b0
     [&lt;ffffffff81675355&gt;] vfs_read+0x115/0x330
     [&lt;ffffffff81676371&gt;] SyS_read+0xd1/0x1a0
     [&lt;ffffffff816762a0&gt;] ? vfs_write+0x4b0/0x4b0
     [&lt;ffffffff82001c2c&gt;] ? __this_cpu_preempt_check+0x1c/0x20
     [&lt;ffffffff8150455a&gt;] ? __context_tracking_exit.part.4+0x3a/0x1e0
     [&lt;ffffffff816762a0&gt;] ? vfs_write+0x4b0/0x4b0
     [&lt;ffffffff81005524&gt;] do_syscall_64+0x1c4/0x4e0
     [&lt;ffffffff810052fc&gt;] ? syscall_return_slowpath+0x16c/0x1d0
     [&lt;ffffffff83c3276a&gt;] entry_SYSCALL64_slow_path+0x25/0x25
    ==================================================================

There are a couple of problems that I can see:

 - ioctl(SNDRV_TIMER_IOCTL_SELECT), which potentially sets
   tu-&gt;queue/tu-&gt;tqueue to NULL on memory allocation failure, so read()
   would get a NULL pointer dereference like the above splat

 - the same ioctl() can free tu-&gt;queue/to-&gt;tqueue which means read()
   could potentially see (and dereference) the freed pointer

We can fix both by taking the ioctl_lock mutex when dereferencing
-&gt;queue/-&gt;tqueue, since that's always held over all the ioctl() code.

Just looking at the code I find it likely that there are more problems
here such as tu-&gt;qhead pointing outside the buffer if the size is
changed concurrently using SNDRV_TIMER_IOCTL_PARAMS.

[js] unlock in fail paths

Signed-off-by: Vegard Nossum &lt;vegard.nossum@oracle.com&gt;
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ALSA: rawmidi: Fix possible deadlock with virmidi registration</title>
<updated>2016-09-29T09:14:15+00:00</updated>
<author>
<name>Takashi Iwai</name>
<email>tiwai@suse.de</email>
</author>
<published>2016-08-30T12:45:46+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=72fe6c43d30f622810e72b436bf25ae0a342b4c9'/>
<id>72fe6c43d30f622810e72b436bf25ae0a342b4c9</id>
<content type='text'>
commit 816f318b2364262a51024096da7ca3b84e78e3b5 upstream.

When a seq-virmidi driver is initialized, it registers a rawmidi
instance with its callback to create an associated seq kernel client.
Currently it's done throughly in rawmidi's register_mutex context.
Recently it was found that this may lead to a deadlock another rawmidi
device that is being attached with the sequencer is accessed, as both
open with the same register_mutex.  This was actually triggered by
syzkaller, as Dmitry Vyukov reported:

======================================================
 [ INFO: possible circular locking dependency detected ]
 4.8.0-rc1+ #11 Not tainted
 -------------------------------------------------------
 syz-executor/7154 is trying to acquire lock:
  (register_mutex#5){+.+.+.}, at: [&lt;ffffffff84fd6d4b&gt;] snd_rawmidi_kernel_open+0x4b/0x260 sound/core/rawmidi.c:341

 but task is already holding lock:
  (&amp;grp-&gt;list_mutex){++++.+}, at: [&lt;ffffffff850138bb&gt;] check_and_subscribe_port+0x5b/0x5c0 sound/core/seq/seq_ports.c:495

 which lock already depends on the new lock.

 the existing dependency chain (in reverse order) is:

 -&gt; #1 (&amp;grp-&gt;list_mutex){++++.+}:
    [&lt;ffffffff8147a3a8&gt;] lock_acquire+0x208/0x430 kernel/locking/lockdep.c:3746
    [&lt;ffffffff863f6199&gt;] down_read+0x49/0xc0 kernel/locking/rwsem.c:22
    [&lt;     inline     &gt;] deliver_to_subscribers sound/core/seq/seq_clientmgr.c:681
    [&lt;ffffffff85005c5e&gt;] snd_seq_deliver_event+0x35e/0x890 sound/core/seq/seq_clientmgr.c:822
    [&lt;ffffffff85006e96&gt;] &gt; snd_seq_kernel_client_dispatch+0x126/0x170 sound/core/seq/seq_clientmgr.c:2418
    [&lt;ffffffff85012c52&gt;] snd_seq_system_broadcast+0xb2/0xf0 sound/core/seq/seq_system.c:101
    [&lt;ffffffff84fff70a&gt;] snd_seq_create_kernel_client+0x24a/0x330 sound/core/seq/seq_clientmgr.c:2297
    [&lt;     inline     &gt;] snd_virmidi_dev_attach_seq sound/core/seq/seq_virmidi.c:383
    [&lt;ffffffff8502d29f&gt;] snd_virmidi_dev_register+0x29f/0x750 sound/core/seq/seq_virmidi.c:450
    [&lt;ffffffff84fd208c&gt;] snd_rawmidi_dev_register+0x30c/0xd40 sound/core/rawmidi.c:1645
    [&lt;ffffffff84f816d3&gt;] __snd_device_register.part.0+0x63/0xc0 sound/core/device.c:164
    [&lt;     inline     &gt;] __snd_device_register sound/core/device.c:162
    [&lt;ffffffff84f8235d&gt;] snd_device_register_all+0xad/0x110 sound/core/device.c:212
    [&lt;ffffffff84f7546f&gt;] snd_card_register+0xef/0x6c0 sound/core/init.c:749
    [&lt;ffffffff85040b7f&gt;] snd_virmidi_probe+0x3ef/0x590 sound/drivers/virmidi.c:123
    [&lt;ffffffff833ebf7b&gt;] platform_drv_probe+0x8b/0x170 drivers/base/platform.c:564
    ......

 -&gt; #0 (register_mutex#5){+.+.+.}:
    [&lt;     inline     &gt;] check_prev_add kernel/locking/lockdep.c:1829
    [&lt;     inline     &gt;] check_prevs_add kernel/locking/lockdep.c:1939
    [&lt;     inline     &gt;] validate_chain kernel/locking/lockdep.c:2266
    [&lt;ffffffff814791f4&gt;] __lock_acquire+0x4d44/0x4d80 kernel/locking/lockdep.c:3335
    [&lt;ffffffff8147a3a8&gt;] lock_acquire+0x208/0x430 kernel/locking/lockdep.c:3746
    [&lt;     inline     &gt;] __mutex_lock_common kernel/locking/mutex.c:521
    [&lt;ffffffff863f0ef1&gt;] mutex_lock_nested+0xb1/0xa20 kernel/locking/mutex.c:621
    [&lt;ffffffff84fd6d4b&gt;] snd_rawmidi_kernel_open+0x4b/0x260 sound/core/rawmidi.c:341
    [&lt;ffffffff8502e7c7&gt;] midisynth_subscribe+0xf7/0x350 sound/core/seq/seq_midi.c:188
    [&lt;     inline     &gt;] subscribe_port sound/core/seq/seq_ports.c:427
    [&lt;ffffffff85013cc7&gt;] check_and_subscribe_port+0x467/0x5c0 sound/core/seq/seq_ports.c:510
    [&lt;ffffffff85015da9&gt;] snd_seq_port_connect+0x2c9/0x500 sound/core/seq/seq_ports.c:579
    [&lt;ffffffff850079b8&gt;] snd_seq_ioctl_subscribe_port+0x1d8/0x2b0 sound/core/seq/seq_clientmgr.c:1480
    [&lt;ffffffff84ffe9e4&gt;] snd_seq_do_ioctl+0x184/0x1e0 sound/core/seq/seq_clientmgr.c:2225
    [&lt;ffffffff84ffeae8&gt;] snd_seq_kernel_client_ctl+0xa8/0x110 sound/core/seq/seq_clientmgr.c:2440
    [&lt;ffffffff85027664&gt;] snd_seq_oss_midi_open+0x3b4/0x610 sound/core/seq/oss/seq_oss_midi.c:375
    [&lt;ffffffff85023d67&gt;] snd_seq_oss_synth_setup_midi+0x107/0x4c0 sound/core/seq/oss/seq_oss_synth.c:281
    [&lt;ffffffff8501b0a8&gt;] snd_seq_oss_open+0x748/0x8d0 sound/core/seq/oss/seq_oss_init.c:274
    [&lt;ffffffff85019d8a&gt;] odev_open+0x6a/0x90 sound/core/seq/oss/seq_oss.c:138
    [&lt;ffffffff84f7040f&gt;] soundcore_open+0x30f/0x640 sound/sound_core.c:639
    ......

 other info that might help us debug this:

 Possible unsafe locking scenario:

        CPU0                    CPU1
        ----                    ----
   lock(&amp;grp-&gt;list_mutex);
                                lock(register_mutex#5);
                                lock(&amp;grp-&gt;list_mutex);
   lock(register_mutex#5);

 *** DEADLOCK ***
======================================================

The fix is to simply move the registration parts in
snd_rawmidi_dev_register() to the outside of the register_mutex lock.
The lock is needed only to manage the linked list, and it's not
necessarily to cover the whole initialization process.

Reported-by: Dmitry Vyukov &lt;dvyukov@google.com&gt;
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 816f318b2364262a51024096da7ca3b84e78e3b5 upstream.

When a seq-virmidi driver is initialized, it registers a rawmidi
instance with its callback to create an associated seq kernel client.
Currently it's done throughly in rawmidi's register_mutex context.
Recently it was found that this may lead to a deadlock another rawmidi
device that is being attached with the sequencer is accessed, as both
open with the same register_mutex.  This was actually triggered by
syzkaller, as Dmitry Vyukov reported:

======================================================
 [ INFO: possible circular locking dependency detected ]
 4.8.0-rc1+ #11 Not tainted
 -------------------------------------------------------
 syz-executor/7154 is trying to acquire lock:
  (register_mutex#5){+.+.+.}, at: [&lt;ffffffff84fd6d4b&gt;] snd_rawmidi_kernel_open+0x4b/0x260 sound/core/rawmidi.c:341

 but task is already holding lock:
  (&amp;grp-&gt;list_mutex){++++.+}, at: [&lt;ffffffff850138bb&gt;] check_and_subscribe_port+0x5b/0x5c0 sound/core/seq/seq_ports.c:495

 which lock already depends on the new lock.

 the existing dependency chain (in reverse order) is:

 -&gt; #1 (&amp;grp-&gt;list_mutex){++++.+}:
    [&lt;ffffffff8147a3a8&gt;] lock_acquire+0x208/0x430 kernel/locking/lockdep.c:3746
    [&lt;ffffffff863f6199&gt;] down_read+0x49/0xc0 kernel/locking/rwsem.c:22
    [&lt;     inline     &gt;] deliver_to_subscribers sound/core/seq/seq_clientmgr.c:681
    [&lt;ffffffff85005c5e&gt;] snd_seq_deliver_event+0x35e/0x890 sound/core/seq/seq_clientmgr.c:822
    [&lt;ffffffff85006e96&gt;] &gt; snd_seq_kernel_client_dispatch+0x126/0x170 sound/core/seq/seq_clientmgr.c:2418
    [&lt;ffffffff85012c52&gt;] snd_seq_system_broadcast+0xb2/0xf0 sound/core/seq/seq_system.c:101
    [&lt;ffffffff84fff70a&gt;] snd_seq_create_kernel_client+0x24a/0x330 sound/core/seq/seq_clientmgr.c:2297
    [&lt;     inline     &gt;] snd_virmidi_dev_attach_seq sound/core/seq/seq_virmidi.c:383
    [&lt;ffffffff8502d29f&gt;] snd_virmidi_dev_register+0x29f/0x750 sound/core/seq/seq_virmidi.c:450
    [&lt;ffffffff84fd208c&gt;] snd_rawmidi_dev_register+0x30c/0xd40 sound/core/rawmidi.c:1645
    [&lt;ffffffff84f816d3&gt;] __snd_device_register.part.0+0x63/0xc0 sound/core/device.c:164
    [&lt;     inline     &gt;] __snd_device_register sound/core/device.c:162
    [&lt;ffffffff84f8235d&gt;] snd_device_register_all+0xad/0x110 sound/core/device.c:212
    [&lt;ffffffff84f7546f&gt;] snd_card_register+0xef/0x6c0 sound/core/init.c:749
    [&lt;ffffffff85040b7f&gt;] snd_virmidi_probe+0x3ef/0x590 sound/drivers/virmidi.c:123
    [&lt;ffffffff833ebf7b&gt;] platform_drv_probe+0x8b/0x170 drivers/base/platform.c:564
    ......

 -&gt; #0 (register_mutex#5){+.+.+.}:
    [&lt;     inline     &gt;] check_prev_add kernel/locking/lockdep.c:1829
    [&lt;     inline     &gt;] check_prevs_add kernel/locking/lockdep.c:1939
    [&lt;     inline     &gt;] validate_chain kernel/locking/lockdep.c:2266
    [&lt;ffffffff814791f4&gt;] __lock_acquire+0x4d44/0x4d80 kernel/locking/lockdep.c:3335
    [&lt;ffffffff8147a3a8&gt;] lock_acquire+0x208/0x430 kernel/locking/lockdep.c:3746
    [&lt;     inline     &gt;] __mutex_lock_common kernel/locking/mutex.c:521
    [&lt;ffffffff863f0ef1&gt;] mutex_lock_nested+0xb1/0xa20 kernel/locking/mutex.c:621
    [&lt;ffffffff84fd6d4b&gt;] snd_rawmidi_kernel_open+0x4b/0x260 sound/core/rawmidi.c:341
    [&lt;ffffffff8502e7c7&gt;] midisynth_subscribe+0xf7/0x350 sound/core/seq/seq_midi.c:188
    [&lt;     inline     &gt;] subscribe_port sound/core/seq/seq_ports.c:427
    [&lt;ffffffff85013cc7&gt;] check_and_subscribe_port+0x467/0x5c0 sound/core/seq/seq_ports.c:510
    [&lt;ffffffff85015da9&gt;] snd_seq_port_connect+0x2c9/0x500 sound/core/seq/seq_ports.c:579
    [&lt;ffffffff850079b8&gt;] snd_seq_ioctl_subscribe_port+0x1d8/0x2b0 sound/core/seq/seq_clientmgr.c:1480
    [&lt;ffffffff84ffe9e4&gt;] snd_seq_do_ioctl+0x184/0x1e0 sound/core/seq/seq_clientmgr.c:2225
    [&lt;ffffffff84ffeae8&gt;] snd_seq_kernel_client_ctl+0xa8/0x110 sound/core/seq/seq_clientmgr.c:2440
    [&lt;ffffffff85027664&gt;] snd_seq_oss_midi_open+0x3b4/0x610 sound/core/seq/oss/seq_oss_midi.c:375
    [&lt;ffffffff85023d67&gt;] snd_seq_oss_synth_setup_midi+0x107/0x4c0 sound/core/seq/oss/seq_oss_synth.c:281
    [&lt;ffffffff8501b0a8&gt;] snd_seq_oss_open+0x748/0x8d0 sound/core/seq/oss/seq_oss_init.c:274
    [&lt;ffffffff85019d8a&gt;] odev_open+0x6a/0x90 sound/core/seq/oss/seq_oss.c:138
    [&lt;ffffffff84f7040f&gt;] soundcore_open+0x30f/0x640 sound/sound_core.c:639
    ......

 other info that might help us debug this:

 Possible unsafe locking scenario:

        CPU0                    CPU1
        ----                    ----
   lock(&amp;grp-&gt;list_mutex);
                                lock(register_mutex#5);
                                lock(&amp;grp-&gt;list_mutex);
   lock(register_mutex#5);

 *** DEADLOCK ***
======================================================

The fix is to simply move the registration parts in
snd_rawmidi_dev_register() to the outside of the register_mutex lock.
The lock is needed only to manage the linked list, and it's not
necessarily to cover the whole initialization process.

Reported-by: Dmitry Vyukov &lt;dvyukov@google.com&gt;
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>ALSA: oxygen: Fix logical-not-parentheses warning</title>
<updated>2016-09-29T09:14:04+00:00</updated>
<author>
<name>Tomer Barletz</name>
<email>barletz@gmail.com</email>
</author>
<published>2015-08-02T09:08:57+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=f1e02250a6d3d79ffbfec6b7340ed5ee6c8e78f7'/>
<id>f1e02250a6d3d79ffbfec6b7340ed5ee6c8e78f7</id>
<content type='text'>
commit 8ec7cfce3762299ae289c384e281b2f4010ae231 upstream.

This fixes the following warning, that is seen with gcc 5.1:
warning: logical not is only applied to the left hand side of comparison [-Wlogical-not-parentheses].

Signed-off-by: Tomer Barletz &lt;barletz@gmail.com&gt;
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
Cc: Willy Tarreau &lt;w@1wt.eu&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 8ec7cfce3762299ae289c384e281b2f4010ae231 upstream.

This fixes the following warning, that is seen with gcc 5.1:
warning: logical not is only applied to the left hand side of comparison [-Wlogical-not-parentheses].

Signed-off-by: Tomer Barletz &lt;barletz@gmail.com&gt;
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
Cc: Willy Tarreau &lt;w@1wt.eu&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>ALSA: ctl: Stop notification after disconnection</title>
<updated>2016-08-19T07:50:51+00:00</updated>
<author>
<name>Takashi Iwai</name>
<email>tiwai@suse.de</email>
</author>
<published>2016-07-08T06:05:19+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=ce3b334f59be6943b3754d395802187bf317ac31'/>
<id>ce3b334f59be6943b3754d395802187bf317ac31</id>
<content type='text'>
commit f388cdcdd160687c6650833f286b9c89c50960ff upstream.

snd_ctl_remove() has a notification for the removal event.  It's
superfluous when done during the device got disconnected.  Although
the notification itself is mostly harmless, it may potentially be
harmful, and should be suppressed.  Actually some components PCM may
free ctl elements during the disconnect or free callbacks, thus it's
no theoretical issue.

This patch adds the check of card-&gt;shutdown flag for avoiding
unnecessary notifications after (or during) the disconnect.

Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit f388cdcdd160687c6650833f286b9c89c50960ff upstream.

snd_ctl_remove() has a notification for the removal event.  It's
superfluous when done during the device got disconnected.  Although
the notification itself is mostly harmless, it may potentially be
harmful, and should be suppressed.  Actually some components PCM may
free ctl elements during the disconnect or free callbacks, thus it's
no theoretical issue.

This patch adds the check of card-&gt;shutdown flag for avoiding
unnecessary notifications after (or during) the disconnect.

Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>ALSA: au88x0: Fix calculation in vortex_wtdma_bufshift()</title>
<updated>2016-08-19T07:50:50+00:00</updated>
<author>
<name>Takashi Iwai</name>
<email>tiwai@suse.de</email>
</author>
<published>2016-06-29T13:23:08+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=61216b5a4a8e11d64e2628697299f3d9bceae011'/>
<id>61216b5a4a8e11d64e2628697299f3d9bceae011</id>
<content type='text'>
commit 62db7152c924e4c060e42b34a69cd39658e8a0dc upstream.

vortex_wtdma_bufshift() function does calculate the page index
wrongly, first masking then shift, which always results in zero.
The proper computation is to first shift, then mask.

Reported-by: Dan Carpenter &lt;dan.carpenter@oracle.com&gt;
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 62db7152c924e4c060e42b34a69cd39658e8a0dc upstream.

vortex_wtdma_bufshift() function does calculate the page index
wrongly, first masking then shift, which always results in zero.
The proper computation is to first shift, then mask.

Reported-by: Dan Carpenter &lt;dan.carpenter@oracle.com&gt;
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>ALSA: dummy: Fix a use-after-free at closing</title>
<updated>2016-08-19T07:50:50+00:00</updated>
<author>
<name>Takashi Iwai</name>
<email>tiwai@suse.de</email>
</author>
<published>2016-06-24T13:15:26+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=9d12ce32ab7e3693a0a34e832068db0f9a01e5f0'/>
<id>9d12ce32ab7e3693a0a34e832068db0f9a01e5f0</id>
<content type='text'>
commit d5dbbe6569481bf12dcbe3e12cff72c5f78d272c upstream.

syzkaller fuzzer spotted a potential use-after-free case in snd-dummy
driver when hrtimer is used as backend:
&gt; ==================================================================
&gt; BUG: KASAN: use-after-free in rb_erase+0x1b17/0x2010 at addr ffff88005e5b6f68
&gt;  Read of size 8 by task syz-executor/8984
&gt; =============================================================================
&gt; BUG kmalloc-192 (Not tainted): kasan: bad access detected
&gt; -----------------------------------------------------------------------------
&gt;
&gt; Disabling lock debugging due to kernel taint
&gt; INFO: Allocated in 0xbbbbbbbbbbbbbbbb age=18446705582212484632
&gt; ....
&gt; [&lt;      none      &gt;] dummy_hrtimer_create+0x49/0x1a0 sound/drivers/dummy.c:464
&gt; ....
&gt; INFO: Freed in 0xfffd8e09 age=18446705496313138713 cpu=2164287125 pid=-1
&gt; [&lt;      none      &gt;] dummy_hrtimer_free+0x68/0x80 sound/drivers/dummy.c:481
&gt; ....
&gt; Call Trace:
&gt;  [&lt;ffffffff8179e59e&gt;] __asan_report_load8_noabort+0x3e/0x40 mm/kasan/report.c:333
&gt;  [&lt;     inline     &gt;] rb_set_parent include/linux/rbtree_augmented.h:111
&gt;  [&lt;     inline     &gt;] __rb_erase_augmented include/linux/rbtree_augmented.h:218
&gt;  [&lt;ffffffff82ca5787&gt;] rb_erase+0x1b17/0x2010 lib/rbtree.c:427
&gt;  [&lt;ffffffff82cb02e8&gt;] timerqueue_del+0x78/0x170 lib/timerqueue.c:86
&gt;  [&lt;ffffffff814d0c80&gt;] __remove_hrtimer+0x90/0x220 kernel/time/hrtimer.c:903
&gt;  [&lt;     inline     &gt;] remove_hrtimer kernel/time/hrtimer.c:945
&gt;  [&lt;ffffffff814d23da&gt;] hrtimer_try_to_cancel+0x22a/0x570 kernel/time/hrtimer.c:1046
&gt;  [&lt;ffffffff814d2742&gt;] hrtimer_cancel+0x22/0x40 kernel/time/hrtimer.c:1066
&gt;  [&lt;ffffffff85420531&gt;] dummy_hrtimer_stop+0x91/0xb0 sound/drivers/dummy.c:417
&gt;  [&lt;ffffffff854228bf&gt;] dummy_pcm_trigger+0x17f/0x1e0 sound/drivers/dummy.c:507
&gt;  [&lt;ffffffff85392170&gt;] snd_pcm_do_stop+0x160/0x1b0 sound/core/pcm_native.c:1106
&gt;  [&lt;ffffffff85391b26&gt;] snd_pcm_action_single+0x76/0x120 sound/core/pcm_native.c:956
&gt;  [&lt;ffffffff85391e01&gt;] snd_pcm_action+0x231/0x290 sound/core/pcm_native.c:974
&gt;  [&lt;     inline     &gt;] snd_pcm_stop sound/core/pcm_native.c:1139
&gt;  [&lt;ffffffff8539754d&gt;] snd_pcm_drop+0x12d/0x1d0 sound/core/pcm_native.c:1784
&gt;  [&lt;ffffffff8539d3be&gt;] snd_pcm_common_ioctl1+0xfae/0x2150 sound/core/pcm_native.c:2805
&gt;  [&lt;ffffffff8539ee91&gt;] snd_pcm_capture_ioctl1+0x2a1/0x5e0 sound/core/pcm_native.c:2976
&gt;  [&lt;ffffffff8539f2ec&gt;] snd_pcm_kernel_ioctl+0x11c/0x160 sound/core/pcm_native.c:3020
&gt;  [&lt;ffffffff853d9a44&gt;] snd_pcm_oss_sync+0x3a4/0xa30 sound/core/oss/pcm_oss.c:1693
&gt;  [&lt;ffffffff853da27d&gt;] snd_pcm_oss_release+0x1ad/0x280 sound/core/oss/pcm_oss.c:2483
&gt;  .....

A workaround is to call hrtimer_cancel() in dummy_hrtimer_sync() which
is called certainly before other blocking ops.

Reported-by: Dmitry Vyukov &lt;dvyukov@google.com&gt;
Tested-by: Dmitry Vyukov &lt;dvyukov@google.com&gt;
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit d5dbbe6569481bf12dcbe3e12cff72c5f78d272c upstream.

syzkaller fuzzer spotted a potential use-after-free case in snd-dummy
driver when hrtimer is used as backend:
&gt; ==================================================================
&gt; BUG: KASAN: use-after-free in rb_erase+0x1b17/0x2010 at addr ffff88005e5b6f68
&gt;  Read of size 8 by task syz-executor/8984
&gt; =============================================================================
&gt; BUG kmalloc-192 (Not tainted): kasan: bad access detected
&gt; -----------------------------------------------------------------------------
&gt;
&gt; Disabling lock debugging due to kernel taint
&gt; INFO: Allocated in 0xbbbbbbbbbbbbbbbb age=18446705582212484632
&gt; ....
&gt; [&lt;      none      &gt;] dummy_hrtimer_create+0x49/0x1a0 sound/drivers/dummy.c:464
&gt; ....
&gt; INFO: Freed in 0xfffd8e09 age=18446705496313138713 cpu=2164287125 pid=-1
&gt; [&lt;      none      &gt;] dummy_hrtimer_free+0x68/0x80 sound/drivers/dummy.c:481
&gt; ....
&gt; Call Trace:
&gt;  [&lt;ffffffff8179e59e&gt;] __asan_report_load8_noabort+0x3e/0x40 mm/kasan/report.c:333
&gt;  [&lt;     inline     &gt;] rb_set_parent include/linux/rbtree_augmented.h:111
&gt;  [&lt;     inline     &gt;] __rb_erase_augmented include/linux/rbtree_augmented.h:218
&gt;  [&lt;ffffffff82ca5787&gt;] rb_erase+0x1b17/0x2010 lib/rbtree.c:427
&gt;  [&lt;ffffffff82cb02e8&gt;] timerqueue_del+0x78/0x170 lib/timerqueue.c:86
&gt;  [&lt;ffffffff814d0c80&gt;] __remove_hrtimer+0x90/0x220 kernel/time/hrtimer.c:903
&gt;  [&lt;     inline     &gt;] remove_hrtimer kernel/time/hrtimer.c:945
&gt;  [&lt;ffffffff814d23da&gt;] hrtimer_try_to_cancel+0x22a/0x570 kernel/time/hrtimer.c:1046
&gt;  [&lt;ffffffff814d2742&gt;] hrtimer_cancel+0x22/0x40 kernel/time/hrtimer.c:1066
&gt;  [&lt;ffffffff85420531&gt;] dummy_hrtimer_stop+0x91/0xb0 sound/drivers/dummy.c:417
&gt;  [&lt;ffffffff854228bf&gt;] dummy_pcm_trigger+0x17f/0x1e0 sound/drivers/dummy.c:507
&gt;  [&lt;ffffffff85392170&gt;] snd_pcm_do_stop+0x160/0x1b0 sound/core/pcm_native.c:1106
&gt;  [&lt;ffffffff85391b26&gt;] snd_pcm_action_single+0x76/0x120 sound/core/pcm_native.c:956
&gt;  [&lt;ffffffff85391e01&gt;] snd_pcm_action+0x231/0x290 sound/core/pcm_native.c:974
&gt;  [&lt;     inline     &gt;] snd_pcm_stop sound/core/pcm_native.c:1139
&gt;  [&lt;ffffffff8539754d&gt;] snd_pcm_drop+0x12d/0x1d0 sound/core/pcm_native.c:1784
&gt;  [&lt;ffffffff8539d3be&gt;] snd_pcm_common_ioctl1+0xfae/0x2150 sound/core/pcm_native.c:2805
&gt;  [&lt;ffffffff8539ee91&gt;] snd_pcm_capture_ioctl1+0x2a1/0x5e0 sound/core/pcm_native.c:2976
&gt;  [&lt;ffffffff8539f2ec&gt;] snd_pcm_kernel_ioctl+0x11c/0x160 sound/core/pcm_native.c:3020
&gt;  [&lt;ffffffff853d9a44&gt;] snd_pcm_oss_sync+0x3a4/0xa30 sound/core/oss/pcm_oss.c:1693
&gt;  [&lt;ffffffff853da27d&gt;] snd_pcm_oss_release+0x1ad/0x280 sound/core/oss/pcm_oss.c:2483
&gt;  .....

A workaround is to call hrtimer_cancel() in dummy_hrtimer_sync() which
is called certainly before other blocking ops.

Reported-by: Dmitry Vyukov &lt;dvyukov@google.com&gt;
Tested-by: Dmitry Vyukov &lt;dvyukov@google.com&gt;
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;

</pre>
</div>
</content>
</entry>
</feed>
