<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/sound, branch v4.12.2</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>ALSA: hda - Fix endless loop of codec configure</title>
<updated>2017-06-28T10:10:05+00:00</updated>
<author>
<name>Takashi Iwai</name>
<email>tiwai@suse.de</email>
</author>
<published>2017-06-28T10:02:02+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=d94815f917da770d42c377786dc428f542e38f71'/>
<id>d94815f917da770d42c377786dc428f542e38f71</id>
<content type='text'>
azx_codec_configure() loops over the codecs found on the given
controller via a linked list.  The code used to work in the past, but
in the current version, this may lead to an endless loop when a codec
binding returns an error.

The culprit is that the snd_hda_codec_configure() unregisters the
device upon error, and this eventually deletes the given codec object
from the bus.  Since the list is initialized via list_del_init(), the
next object points to the same device itself.  This behavior change
was introduced at splitting the HD-audio code code, and forgotten to
adapt it here.

For fixing this bug, just use a *_safe() version of list iteration.

Fixes: d068ebc25e6e ("ALSA: hda - Move some codes up to hdac_bus struct")
Reported-by: Daniel Vetter &lt;daniel.vetter@ffwll.ch&gt;
Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
azx_codec_configure() loops over the codecs found on the given
controller via a linked list.  The code used to work in the past, but
in the current version, this may lead to an endless loop when a codec
binding returns an error.

The culprit is that the snd_hda_codec_configure() unregisters the
device upon error, and this eventually deletes the given codec object
from the bus.  Since the list is initialized via list_del_init(), the
next object points to the same device itself.  This behavior change
was introduced at splitting the HD-audio code code, and forgotten to
adapt it here.

For fixing this bug, just use a *_safe() version of list iteration.

Fixes: d068ebc25e6e ("ALSA: hda - Move some codes up to hdac_bus struct")
Reported-by: Daniel Vetter &lt;daniel.vetter@ffwll.ch&gt;
Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ALSA: hda - set input_path bitmap to zero after moving it to new place</title>
<updated>2017-06-28T05:09:19+00:00</updated>
<author>
<name>Hui Wang</name>
<email>hui.wang@canonical.com</email>
</author>
<published>2017-06-28T00:59:16+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=a8f20fd25bdce81a8e41767c39f456d346b63427'/>
<id>a8f20fd25bdce81a8e41767c39f456d346b63427</id>
<content type='text'>
Recently we met a problem, the codec has valid adcs and input pins,
and they can form valid input paths, but the driver does not build
valid controls for them like "Mic boost", "Capture Volume" and
"Capture Switch".

Through debugging, I found the driver needs to shrink the invalid
adcs and input paths for this machine, so it will move the whole
column bitmap value to the previous column, after moving it, the
driver forgets to set the original column bitmap value to zero, as a
result, the driver will invalidate the path whose index value is the
original colume bitmap value. After executing this function, all
valid input paths are invalidated by a mistake, there are no any
valid input paths, so the driver won't build controls for them.

Fixes: 3a65bcdc577a ("ALSA: hda - Fix inconsistent input_paths after ADC reduction")
Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Hui Wang &lt;hui.wang@canonical.com&gt;
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Recently we met a problem, the codec has valid adcs and input pins,
and they can form valid input paths, but the driver does not build
valid controls for them like "Mic boost", "Capture Volume" and
"Capture Switch".

Through debugging, I found the driver needs to shrink the invalid
adcs and input paths for this machine, so it will move the whole
column bitmap value to the previous column, after moving it, the
driver forgets to set the original column bitmap value to zero, as a
result, the driver will invalidate the path whose index value is the
original colume bitmap value. After executing this function, all
valid input paths are invalidated by a mistake, there are no any
valid input paths, so the driver won't build controls for them.

Fixes: 3a65bcdc577a ("ALSA: hda - Fix inconsistent input_paths after ADC reduction")
Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Hui Wang &lt;hui.wang@canonical.com&gt;
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ALSA: hda - Apply quirks to Broxton-T, too</title>
<updated>2017-06-20T05:52:49+00:00</updated>
<author>
<name>Takashi Iwai</name>
<email>tiwai@suse.de</email>
</author>
<published>2017-06-14T05:37:14+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=c7ecb9068e6772c43941ce609f08bc53f36e1dce'/>
<id>c7ecb9068e6772c43941ce609f08bc53f36e1dce</id>
<content type='text'>
Broxton-T was a forgotten child and we didn't apply the quirks for
Skylake+ properly.  Meanwhile, a quirk for reducing the DMA latency
seems specific to the early Broxton model, so we leave as is.

Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Broxton-T was a forgotten child and we didn't apply the quirks for
Skylake+ properly.  Meanwhile, a quirk for reducing the DMA latency
seems specific to the early Broxton model, so we leave as is.

Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ALSA: firewire-lib: Fix stall of process context at packet error</title>
<updated>2017-06-19T15:47:18+00:00</updated>
<author>
<name>Takashi Sakamoto</name>
<email>o-takashi@sakamocchi.jp</email>
</author>
<published>2017-06-11T07:08:21+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=4a9bfafc64f44ef83de4e00ca1b57352af6cd8c2'/>
<id>4a9bfafc64f44ef83de4e00ca1b57352af6cd8c2</id>
<content type='text'>
At Linux v3.5, packet processing can be done in process context of ALSA
PCM application as well as software IRQ context for OHCI 1394. Below is
an example of the callgraph (some calls are omitted).

ioctl(2) with e.g. HWSYNC
(sound/core/pcm_native.c)
-&gt;snd_pcm_common_ioctl1()
  -&gt;snd_pcm_hwsync()
    -&gt;snd_pcm_stream_lock_irq
    (sound/core/pcm_lib.c)
    -&gt;snd_pcm_update_hw_ptr()
      -&gt;snd_pcm_udpate_hw_ptr0()
        -&gt;struct snd_pcm_ops.pointer()
        (sound/firewire/*)
        = Each handler on drivers in ALSA firewire stack
          (sound/firewire/amdtp-stream.c)
          -&gt;amdtp_stream_pcm_pointer()
            (drivers/firewire/core-iso.c)
            -&gt;fw_iso_context_flush_completions()
              -&gt;struct fw_card_driver.flush_iso_completion()
              (drivers/firewire/ohci.c)
              = flush_iso_completions()
                -&gt;struct fw_iso_context.callback.sc
                (sound/firewire/amdtp-stream.c)
                = in_stream_callback() or out_stream_callback()
                  -&gt;...
    -&gt;snd_pcm_stream_unlock_irq

When packet queueing error occurs or detecting invalid packets in
'in_stream_callback()' or 'out_stream_callback()', 'snd_pcm_stop_xrun()'
is called on local CPU with disabled IRQ.

(sound/firewire/amdtp-stream.c)
in_stream_callback() or out_stream_callback()
-&gt;amdtp_stream_pcm_abort()
  -&gt;snd_pcm_stop_xrun()
    -&gt;snd_pcm_stream_lock_irqsave()
    -&gt;snd_pcm_stop()
    -&gt;snd_pcm_stream_unlock_irqrestore()

The process is stalled on the CPU due to attempt to acquire recursive lock.

[  562.630853] INFO: rcu_sched detected stalls on CPUs/tasks:
[  562.630861]      2-...: (1 GPs behind) idle=37d/140000000000000/0 softirq=38323/38323 fqs=7140
[  562.630862]      (detected by 3, t=15002 jiffies, g=21036, c=21035, q=5933)
[  562.630866] Task dump for CPU 2:
[  562.630867] alsa-source-OXF R  running task        0  6619      1 0x00000008
[  562.630870] Call Trace:
[  562.630876]  ? vt_console_print+0x79/0x3e0
[  562.630880]  ? msg_print_text+0x9d/0x100
[  562.630883]  ? up+0x32/0x50
[  562.630885]  ? irq_work_queue+0x8d/0xa0
[  562.630886]  ? console_unlock+0x2b6/0x4b0
[  562.630888]  ? vprintk_emit+0x312/0x4a0
[  562.630892]  ? dev_vprintk_emit+0xbf/0x230
[  562.630895]  ? do_sys_poll+0x37a/0x550
[  562.630897]  ? dev_printk_emit+0x4e/0x70
[  562.630900]  ? __dev_printk+0x3c/0x80
[  562.630903]  ? _raw_spin_lock+0x20/0x30
[  562.630909]  ? snd_pcm_stream_lock+0x31/0x50 [snd_pcm]
[  562.630914]  ? _snd_pcm_stream_lock_irqsave+0x2e/0x40 [snd_pcm]
[  562.630918]  ? snd_pcm_stop_xrun+0x16/0x70 [snd_pcm]
[  562.630922]  ? in_stream_callback+0x3e6/0x450 [snd_firewire_lib]
[  562.630925]  ? handle_ir_packet_per_buffer+0x8e/0x1a0 [firewire_ohci]
[  562.630928]  ? ohci_flush_iso_completions+0xa3/0x130 [firewire_ohci]
[  562.630932]  ? fw_iso_context_flush_completions+0x15/0x20 [firewire_core]
[  562.630935]  ? amdtp_stream_pcm_pointer+0x2d/0x40 [snd_firewire_lib]
[  562.630938]  ? pcm_capture_pointer+0x19/0x20 [snd_oxfw]
[  562.630943]  ? snd_pcm_update_hw_ptr0+0x47/0x3d0 [snd_pcm]
[  562.630945]  ? poll_select_copy_remaining+0x150/0x150
[  562.630947]  ? poll_select_copy_remaining+0x150/0x150
[  562.630952]  ? snd_pcm_update_hw_ptr+0x10/0x20 [snd_pcm]
[  562.630956]  ? snd_pcm_hwsync+0x45/0xb0 [snd_pcm]
[  562.630960]  ? snd_pcm_common_ioctl1+0x1ff/0xc90 [snd_pcm]
[  562.630962]  ? futex_wake+0x90/0x170
[  562.630966]  ? snd_pcm_capture_ioctl1+0x136/0x260 [snd_pcm]
[  562.630970]  ? snd_pcm_capture_ioctl+0x27/0x40 [snd_pcm]
[  562.630972]  ? do_vfs_ioctl+0xa3/0x610
[  562.630974]  ? vfs_read+0x11b/0x130
[  562.630976]  ? SyS_ioctl+0x79/0x90
[  562.630978]  ? entry_SYSCALL_64_fastpath+0x1e/0xad

This commit fixes the above bug. This assumes two cases:
1. Any error is detected in software IRQ context of OHCI 1394 context.
In this case, PCM substream should be aborted in packet handler. On the
other hand, it should not be done in any process context. TO distinguish
these two context, use 'in_interrupt()' macro.
2. Any error is detect in process context of ALSA PCM application.
In this case, PCM substream should not be aborted in packet handler
because PCM substream lock is acquired. The task to abort PCM substream
should be done in ALSA PCM core. For this purpose, SNDRV_PCM_POS_XRUN is
returned at 'struct snd_pcm_ops.pointer()'.

Suggested-by: Clemens Ladisch &lt;clemens@ladisch.de&gt;
Fixes: e9148dddc3c7("ALSA: firewire-lib: flush completed packets when reading PCM position")
Cc: &lt;stable@vger.kernel.org&gt; # 4.9+
Signed-off-by: Takashi Sakamoto &lt;o-takashi@sakamocchi.jp&gt;
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
At Linux v3.5, packet processing can be done in process context of ALSA
PCM application as well as software IRQ context for OHCI 1394. Below is
an example of the callgraph (some calls are omitted).

ioctl(2) with e.g. HWSYNC
(sound/core/pcm_native.c)
-&gt;snd_pcm_common_ioctl1()
  -&gt;snd_pcm_hwsync()
    -&gt;snd_pcm_stream_lock_irq
    (sound/core/pcm_lib.c)
    -&gt;snd_pcm_update_hw_ptr()
      -&gt;snd_pcm_udpate_hw_ptr0()
        -&gt;struct snd_pcm_ops.pointer()
        (sound/firewire/*)
        = Each handler on drivers in ALSA firewire stack
          (sound/firewire/amdtp-stream.c)
          -&gt;amdtp_stream_pcm_pointer()
            (drivers/firewire/core-iso.c)
            -&gt;fw_iso_context_flush_completions()
              -&gt;struct fw_card_driver.flush_iso_completion()
              (drivers/firewire/ohci.c)
              = flush_iso_completions()
                -&gt;struct fw_iso_context.callback.sc
                (sound/firewire/amdtp-stream.c)
                = in_stream_callback() or out_stream_callback()
                  -&gt;...
    -&gt;snd_pcm_stream_unlock_irq

When packet queueing error occurs or detecting invalid packets in
'in_stream_callback()' or 'out_stream_callback()', 'snd_pcm_stop_xrun()'
is called on local CPU with disabled IRQ.

(sound/firewire/amdtp-stream.c)
in_stream_callback() or out_stream_callback()
-&gt;amdtp_stream_pcm_abort()
  -&gt;snd_pcm_stop_xrun()
    -&gt;snd_pcm_stream_lock_irqsave()
    -&gt;snd_pcm_stop()
    -&gt;snd_pcm_stream_unlock_irqrestore()

The process is stalled on the CPU due to attempt to acquire recursive lock.

[  562.630853] INFO: rcu_sched detected stalls on CPUs/tasks:
[  562.630861]      2-...: (1 GPs behind) idle=37d/140000000000000/0 softirq=38323/38323 fqs=7140
[  562.630862]      (detected by 3, t=15002 jiffies, g=21036, c=21035, q=5933)
[  562.630866] Task dump for CPU 2:
[  562.630867] alsa-source-OXF R  running task        0  6619      1 0x00000008
[  562.630870] Call Trace:
[  562.630876]  ? vt_console_print+0x79/0x3e0
[  562.630880]  ? msg_print_text+0x9d/0x100
[  562.630883]  ? up+0x32/0x50
[  562.630885]  ? irq_work_queue+0x8d/0xa0
[  562.630886]  ? console_unlock+0x2b6/0x4b0
[  562.630888]  ? vprintk_emit+0x312/0x4a0
[  562.630892]  ? dev_vprintk_emit+0xbf/0x230
[  562.630895]  ? do_sys_poll+0x37a/0x550
[  562.630897]  ? dev_printk_emit+0x4e/0x70
[  562.630900]  ? __dev_printk+0x3c/0x80
[  562.630903]  ? _raw_spin_lock+0x20/0x30
[  562.630909]  ? snd_pcm_stream_lock+0x31/0x50 [snd_pcm]
[  562.630914]  ? _snd_pcm_stream_lock_irqsave+0x2e/0x40 [snd_pcm]
[  562.630918]  ? snd_pcm_stop_xrun+0x16/0x70 [snd_pcm]
[  562.630922]  ? in_stream_callback+0x3e6/0x450 [snd_firewire_lib]
[  562.630925]  ? handle_ir_packet_per_buffer+0x8e/0x1a0 [firewire_ohci]
[  562.630928]  ? ohci_flush_iso_completions+0xa3/0x130 [firewire_ohci]
[  562.630932]  ? fw_iso_context_flush_completions+0x15/0x20 [firewire_core]
[  562.630935]  ? amdtp_stream_pcm_pointer+0x2d/0x40 [snd_firewire_lib]
[  562.630938]  ? pcm_capture_pointer+0x19/0x20 [snd_oxfw]
[  562.630943]  ? snd_pcm_update_hw_ptr0+0x47/0x3d0 [snd_pcm]
[  562.630945]  ? poll_select_copy_remaining+0x150/0x150
[  562.630947]  ? poll_select_copy_remaining+0x150/0x150
[  562.630952]  ? snd_pcm_update_hw_ptr+0x10/0x20 [snd_pcm]
[  562.630956]  ? snd_pcm_hwsync+0x45/0xb0 [snd_pcm]
[  562.630960]  ? snd_pcm_common_ioctl1+0x1ff/0xc90 [snd_pcm]
[  562.630962]  ? futex_wake+0x90/0x170
[  562.630966]  ? snd_pcm_capture_ioctl1+0x136/0x260 [snd_pcm]
[  562.630970]  ? snd_pcm_capture_ioctl+0x27/0x40 [snd_pcm]
[  562.630972]  ? do_vfs_ioctl+0xa3/0x610
[  562.630974]  ? vfs_read+0x11b/0x130
[  562.630976]  ? SyS_ioctl+0x79/0x90
[  562.630978]  ? entry_SYSCALL_64_fastpath+0x1e/0xad

This commit fixes the above bug. This assumes two cases:
1. Any error is detected in software IRQ context of OHCI 1394 context.
In this case, PCM substream should be aborted in packet handler. On the
other hand, it should not be done in any process context. TO distinguish
these two context, use 'in_interrupt()' macro.
2. Any error is detect in process context of ALSA PCM application.
In this case, PCM substream should not be aborted in packet handler
because PCM substream lock is acquired. The task to abort PCM substream
should be done in ALSA PCM core. For this purpose, SNDRV_PCM_POS_XRUN is
returned at 'struct snd_pcm_ops.pointer()'.

Suggested-by: Clemens Ladisch &lt;clemens@ladisch.de&gt;
Fixes: e9148dddc3c7("ALSA: firewire-lib: flush completed packets when reading PCM position")
Cc: &lt;stable@vger.kernel.org&gt; # 4.9+
Signed-off-by: Takashi Sakamoto &lt;o-takashi@sakamocchi.jp&gt;
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ALSA: pcm: Don't treat NULL chmap as a fatal error</title>
<updated>2017-06-14T14:20:32+00:00</updated>
<author>
<name>Takashi Iwai</name>
<email>tiwai@suse.de</email>
</author>
<published>2017-06-14T14:20:32+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=2deaeaf102d692cb6f764123b1df7aa118a8e97c'/>
<id>2deaeaf102d692cb6f764123b1df7aa118a8e97c</id>
<content type='text'>
The standard PCM chmap helper callbacks treat the NULL info-&gt;chmap as
a fatal error and spews the kernel warning with stack trace when
CONFIG_SND_DEBUG is on.  This was OK, originally it was supposed to be
always static and non-NULL.  But, as the recent addition of Intel LPE
audio driver shows, the chmap content may vary dynamically, and it can
be even NULL when disconnected.  The user still sees the kernel
warning unnecessarily.

For clearing such a confusion, this patch simply removes the
snd_BUG_ON() in each place, just returns an error without warning.

Cc: &lt;stable@vger.kernel.org&gt; # v4.11+
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The standard PCM chmap helper callbacks treat the NULL info-&gt;chmap as
a fatal error and spews the kernel warning with stack trace when
CONFIG_SND_DEBUG is on.  This was OK, originally it was supposed to be
always static and non-NULL.  But, as the recent addition of Intel LPE
audio driver shows, the chmap content may vary dynamically, and it can
be even NULL when disconnected.  The user still sees the kernel
warning unnecessarily.

For clearing such a confusion, this patch simply removes the
snd_BUG_ON() in each place, just returns an error without warning.

Cc: &lt;stable@vger.kernel.org&gt; # v4.11+
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ALSA: hda - Add Coffelake PCI ID</title>
<updated>2017-06-14T07:33:52+00:00</updated>
<author>
<name>Megha Dey</name>
<email>megha.dey@intel.com</email>
</author>
<published>2017-06-14T04:21:56+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=e79b0006c45c9b0b22f3ea54ff6e256b34c1f208'/>
<id>e79b0006c45c9b0b22f3ea54ff6e256b34c1f208</id>
<content type='text'>
Coffelake is another Intel part, so need to add PCI ID for it.

Signed-off-by: Megha Dey &lt;megha.dey@intel.com&gt;
Signed-off-by: Subhransu S. Prusty &lt;subhransu.s.prusty@intel.com&gt;
Acked-by: Vinod Koul &lt;vinod.koul@intel.com&gt;
Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Coffelake is another Intel part, so need to add PCI ID for it.

Signed-off-by: Megha Dey &lt;megha.dey@intel.com&gt;
Signed-off-by: Subhransu S. Prusty &lt;subhransu.s.prusty@intel.com&gt;
Acked-by: Vinod Koul &lt;vinod.koul@intel.com&gt;
Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ALSA: timer: Fix missing queue indices reset at SNDRV_TIMER_IOCTL_SELECT</title>
<updated>2017-06-07T08:25:23+00:00</updated>
<author>
<name>Takashi Iwai</name>
<email>tiwai@suse.de</email>
</author>
<published>2017-06-02T15:26:56+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=ba3021b2c79b2fa9114f92790a99deb27a65b728'/>
<id>ba3021b2c79b2fa9114f92790a99deb27a65b728</id>
<content type='text'>
snd_timer_user_tselect() reallocates the queue buffer dynamically, but
it forgot to reset its indices.  Since the read may happen
concurrently with ioctl and snd_timer_user_tselect() allocates the
buffer via kmalloc(), this may lead to the leak of uninitialized
kernel-space data, as spotted via KMSAN:

  BUG: KMSAN: use of unitialized memory in snd_timer_user_read+0x6c4/0xa10
  CPU: 0 PID: 1037 Comm: probe Not tainted 4.11.0-rc5+ #2739
  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
  Call Trace:
   __dump_stack lib/dump_stack.c:16
   dump_stack+0x143/0x1b0 lib/dump_stack.c:52
   kmsan_report+0x12a/0x180 mm/kmsan/kmsan.c:1007
   kmsan_check_memory+0xc2/0x140 mm/kmsan/kmsan.c:1086
   copy_to_user ./arch/x86/include/asm/uaccess.h:725
   snd_timer_user_read+0x6c4/0xa10 sound/core/timer.c:2004
   do_loop_readv_writev fs/read_write.c:716
   __do_readv_writev+0x94c/0x1380 fs/read_write.c:864
   do_readv_writev fs/read_write.c:894
   vfs_readv fs/read_write.c:908
   do_readv+0x52a/0x5d0 fs/read_write.c:934
   SYSC_readv+0xb6/0xd0 fs/read_write.c:1021
   SyS_readv+0x87/0xb0 fs/read_write.c:1018

This patch adds the missing reset of queue indices.  Together with the
previous fix for the ioctl/read race, we cover the whole problem.

Reported-by: Alexander Potapenko &lt;glider@google.com&gt;
Tested-by: Alexander Potapenko &lt;glider@google.com&gt;
Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
snd_timer_user_tselect() reallocates the queue buffer dynamically, but
it forgot to reset its indices.  Since the read may happen
concurrently with ioctl and snd_timer_user_tselect() allocates the
buffer via kmalloc(), this may lead to the leak of uninitialized
kernel-space data, as spotted via KMSAN:

  BUG: KMSAN: use of unitialized memory in snd_timer_user_read+0x6c4/0xa10
  CPU: 0 PID: 1037 Comm: probe Not tainted 4.11.0-rc5+ #2739
  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
  Call Trace:
   __dump_stack lib/dump_stack.c:16
   dump_stack+0x143/0x1b0 lib/dump_stack.c:52
   kmsan_report+0x12a/0x180 mm/kmsan/kmsan.c:1007
   kmsan_check_memory+0xc2/0x140 mm/kmsan/kmsan.c:1086
   copy_to_user ./arch/x86/include/asm/uaccess.h:725
   snd_timer_user_read+0x6c4/0xa10 sound/core/timer.c:2004
   do_loop_readv_writev fs/read_write.c:716
   __do_readv_writev+0x94c/0x1380 fs/read_write.c:864
   do_readv_writev fs/read_write.c:894
   vfs_readv fs/read_write.c:908
   do_readv+0x52a/0x5d0 fs/read_write.c:934
   SYSC_readv+0xb6/0xd0 fs/read_write.c:1021
   SyS_readv+0x87/0xb0 fs/read_write.c:1018

This patch adds the missing reset of queue indices.  Together with the
previous fix for the ioctl/read race, we cover the whole problem.

Reported-by: Alexander Potapenko &lt;glider@google.com&gt;
Tested-by: Alexander Potapenko &lt;glider@google.com&gt;
Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ALSA: timer: Fix race between read and ioctl</title>
<updated>2017-06-07T08:25:20+00:00</updated>
<author>
<name>Takashi Iwai</name>
<email>tiwai@suse.de</email>
</author>
<published>2017-06-02T13:03:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=d11662f4f798b50d8c8743f433842c3e40fe3378'/>
<id>d11662f4f798b50d8c8743f433842c3e40fe3378</id>
<content type='text'>
The read from ALSA timer device, the function snd_timer_user_tread(),
may access to an uninitialized struct snd_timer_user fields when the
read is concurrently performed while the ioctl like
snd_timer_user_tselect() is invoked.  We have already fixed the races
among ioctls via a mutex, but we seem to have forgotten the race
between read vs ioctl.

This patch simply applies (more exactly extends the already applied
range of) tu-&gt;ioctl_lock in snd_timer_user_tread() for closing the
race window.

Reported-by: Alexander Potapenko &lt;glider@google.com&gt;
Tested-by: Alexander Potapenko &lt;glider@google.com&gt;
Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The read from ALSA timer device, the function snd_timer_user_tread(),
may access to an uninitialized struct snd_timer_user fields when the
read is concurrently performed while the ioctl like
snd_timer_user_tselect() is invoked.  We have already fixed the races
among ioctls via a mutex, but we seem to have forgotten the race
between read vs ioctl.

This patch simply applies (more exactly extends the already applied
range of) tu-&gt;ioctl_lock in snd_timer_user_tread() for closing the
race window.

Reported-by: Alexander Potapenko &lt;glider@google.com&gt;
Tested-by: Alexander Potapenko &lt;glider@google.com&gt;
Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge tag 'asoc-fix-v4.12-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus</title>
<updated>2017-06-06T18:03:46+00:00</updated>
<author>
<name>Takashi Iwai</name>
<email>tiwai@suse.de</email>
</author>
<published>2017-06-06T18:03:46+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=dd8038ec56c18680ddddf948247f53d427054f45'/>
<id>dd8038ec56c18680ddddf948247f53d427054f45</id>
<content type='text'>
ASoC: Fixes for v4.12

This is the usual collection of device specific fixes, all accumilated
since the merge window, plus one fix from Takashi for a nasty use after
free bug that bit some things with deferred probe and an update to the
maintainer address for the former Wolfson parts.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
ASoC: Fixes for v4.12

This is the usual collection of device specific fixes, all accumilated
since the merge window, plus one fix from Takashi for a nasty use after
free bug that bit some things with deferred probe and an update to the
maintainer address for the former Wolfson parts.
</pre>
</div>
</content>
</entry>
<entry>
<title>ALSA: hda/realtek - Reorder ALC269 ASUS quirk entries</title>
<updated>2017-06-06T10:33:17+00:00</updated>
<author>
<name>Takashi Iwai</name>
<email>tiwai@suse.de</email>
</author>
<published>2017-06-06T10:33:17+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=4eab0ea196f569ed2085a0fa3729f60eb8edaad1'/>
<id>4eab0ea196f569ed2085a0fa3729f60eb8edaad1</id>
<content type='text'>
A disorder is found in some ALC269 quirk entries for ASUS (1043:xxxx),
which should have been sorted in PCI SSID order.  Rearrange them, so
that I won't overlook the already existing entry like I did a couple
of times in the past...

Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
A disorder is found in some ALC269 quirk entries for ASUS (1043:xxxx),
which should have been sorted in PCI SSID order.  Rearrange them, so
that I won't overlook the already existing entry like I did a couple
of times in the past...

Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
</pre>
</div>
</content>
</entry>
</feed>
