linux-toradex.git/sound, branch v3.2.47

ALSA: usb-audio - Fix invalid volume resolution on Logitech HD webcam c270

2013-06-19T01:16:55+00:00

commit 11e7064f35bb87da8f427d1aa4bbd8b7473a3993 upstream.

USB audio driver spews an error message when probing Logitech HD
webcam c270:
  ALSA mixer.c:1300 usb_audio: Warning! Unlikely big volume range (=6144), cval->res is probably wrong.
  ALSA mixer.c:1304 usb_audio: [5] FU [Mic Capture Volume] ch = 1, val = 1536/7680/1

Obviously the device needs a fixed volume resolution (cval->res = 384)
like other Logitech devices.

Bugzilla: https://bugzilla.novell.com/show_bug.cgi?id=821735

Reported-and-tested-by: Cristian Rodríguez 
Signed-off-by: Takashi Iwai 
Signed-off-by: Ben Hutchings

ALSA: usb-audio - Apply Logitech QuickCam Pro 9000 quirk only to audio iface

2013-06-19T01:16:54+00:00

commit 8eafc0a161123d90617c9ca2eddfe87b382b1b89 upstream.

... instead of applying to all interfaces.

Reference: http://forums.gentoo.org/viewtopic-p-6886404.html

Signed-off-by: Takashi Iwai 
Signed-off-by: Ben Hutchings

ALSA: usb-audio: avoid integer overflow in create_fixed_stream_quirk()

2013-06-19T01:16:42+00:00

commit 8866f405efd4171f9d9c91901d2dd02f01bacb60 upstream.

A malicious USB device could feed in a large nr_rates value.  This would
cause the subsequent call to kmemdup() to allocate a smaller buffer than
expected, leading to out-of-bounds access.

This patch validates the nr_rates value and reuses the limit introduced
in commit 4fa0e81b ("ALSA: usb-audio: fix possible hang and overflow
in parse_uac2_sample_rate_range()").

Signed-off-by: Xi Wang 
Signed-off-by: Takashi Iwai 
Signed-off-by: Ben Hutchings

ALSA: usb-audio: fix possible hang and overflow in parse_uac2_sample_rate_range()

2013-06-19T01:16:41+00:00

commit 4fa0e81b83503900be277e6273a79651b375e288 upstream.

A malicious USB device may feed in carefully crafted min/max/res values,
so that the inner loop in parse_uac2_sample_rate_range() could run for
a long time or even never terminate, e.g., given max = INT_MAX.

Also nr_rates could be a large integer, which causes an integer overflow
in the subsequent call to kmalloc() in parse_audio_format_rates_v2().
Thus, kmalloc() would allocate a smaller buffer than expected, leading
to a memory corruption.

To exploit the two vulnerabilities, an attacker needs physical access
to the machine to plug in a malicious USB device.

This patch makes two changes.

1) The type of "rate" is changed to unsigned int, so that the loop could
   stop once "rate" is larger than INT_MAX.

2) Limit nr_rates to 1024.

Suggested-by: Takashi Iwai 
Signed-off-by: Xi Wang 
Signed-off-by: Takashi Iwai 
Signed-off-by: Ben Hutchings

ALSA: HDA: Fix Oops caused by dereference NULL pointer

2013-05-30T13:34:52+00:00

commit 2195b063f6609e4c6268f291683902f25eaf9aa6 upstream.

The interrupt handler azx_interrupt will call azx_update_rirb,
which may call snd_hda_queue_unsol_event, snd_hda_queue_unsol_event
will dereference chip->bus pointer.

The problem is we alloc chip->bus in azx_codec_create
which will be called after we enable IRQ and enable unsolicited
event in azx_probe.

This will cause Oops due dereference NULL pointer. I meet it, good luck:)

[Rearranged the NULL check before the tracepoint and added another
 NULL check of bus->workq -- tiwai]

Signed-off-by: Wang YanQing 
Signed-off-by: Takashi Iwai 
Signed-off-by: Ben Hutchings

ASoC: wm8994: missing break in wm8994_aif3_hw_params()

2013-05-30T13:34:50+00:00

commit 4495e46fe18f198366961bb2b324a694ef8a9b44 upstream.

The missing break here means that we always return early and the
function is a no-op.

Signed-off-by: Dan Carpenter 
Signed-off-by: Mark Brown 
Signed-off-by: Ben Hutchings

vm: convert snd_pcm_lib_mmap_iomem() to vm_iomap_memory() helper

2013-05-13T14:02:33+00:00

commit 0fe09a45c4848b5b5607b968d959fdc1821c161d upstream.

This is my example conversion of a few existing mmap users.  The pcm
mmap case is one of the more straightforward ones.

Acked-by: Takashi Iwai 
Signed-off-by: Linus Torvalds 
Signed-off-by: Ben Hutchings

ALSA: usb-audio: Fix autopm error during probing

2013-05-13T14:02:26+00:00

commit 60af3d037eb8c670dcce31401501d1271e7c5d95 upstream.

We've got strange errors in get_ctl_value() in mixer.c during
probing, e.g. on Hercules RMX2 DJ Controller:

  ALSA mixer.c:352 cannot get ctl value: req = 0x83, wValue = 0x201, wIndex = 0xa00, type = 4
  ALSA mixer.c:352 cannot get ctl value: req = 0x83, wValue = 0x200, wIndex = 0xa00, type = 4
  ....

It turned out that the culprit is autopm: snd_usb_autoresume() returns
-ENODEV when called during card->probing = 1.

Since the call itself during card->probing = 1 is valid, let's fix the
return value of snd_usb_autoresume() as success.

Reported-and-tested-by: Daniel Schürmann 
Signed-off-by: Takashi Iwai 
Signed-off-by: Ben Hutchings

ALSA: snd-usb: try harder to find USB_DT_CS_ENDPOINT

2013-05-13T14:02:25+00:00

commit ebfc594c02148b6a85c2f178cf167a44a3c3ce10 upstream.

The USB_DT_CS_ENDPOINT class-specific endpoint descriptor is usually
stuffed directly after the standard USB endpoint descriptor, and this is
where the driver currently expects it to be.

There are, however, devices in the wild that have it the other way
around in their descriptor sets, so the USB_DT_CS_ENDPOINT comes
*before* the standard enpoint. Devices known to implement it that way
are "Sennheiser BTD-500" and Plantronics USB headsets.

When the driver can't find the USB_DT_CS_ENDPOINT, it won't be able to
change sample rates, as the bitmask for the validity of this command is
storen in bmAttributes of that descriptor.

Fix this by searching the entire interface instead of just the extra
bytes of the first endpoint, in case the latter fails.

Signed-off-by: Daniel Mack 
Reported-and-tested-by: Torstein Hegge 
Reported-and-tested-by: Yves G 
Signed-off-by: Takashi Iwai 
Signed-off-by: Ben Hutchings

ASoC: max98088: Fix logging of hardware revision.

2013-05-13T14:02:20+00:00

commit 98682063549bedd6e2d2b6b7222f150c6fbce68c upstream.

The hardware revision of the codec is based at 0x40.  Subtract that
before convering to ASCII.  The same as it is done for 98095.

Signed-off-by: Dylan Reid 
Signed-off-by: Mark Brown 
Signed-off-by: Ben Hutchings