March 2019 - Alsa-devel - mailman.alsa-project.org

[alsa-devel] KASAN: slab-out-of-bounds Read in linear_transfer
by syzbot 17 Mar '19

17 Mar '19

Hello, syzbot found the following crash on: HEAD commit: 6c83d0d5 Merge branch 'for-linus-5.1-rc1' of git://git.ker.. git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=15765b0b200000 kernel config: https://syzkaller.appspot.com/x/.config?x=7e1aaa1cfbfe1abf dashboard link: https://syzkaller.appspot.com/bug?extid=a39b5d3c50e55e24fb4d compiler: gcc (GCC) 9.0.0 20181231 (experimental) userspace arch: i386 syz repro: https://syzkaller.appspot.com/x/repro.syz?x=122294a3200000 IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+a39b5d3c50e55e24fb4d(a)syzkaller.appspotmail.com ================================================================== BUG: KASAN: slab-out-of-bounds in memcpy include/linux/string.h:352 [inline] BUG: KASAN: slab-out-of-bounds in do_convert sound/core/oss/linear.c:48 [inline] BUG: KASAN: slab-out-of-bounds in convert sound/core/oss/linear.c:81 [inline] BUG: KASAN: slab-out-of-bounds in linear_transfer sound/core/oss/linear.c:110 [inline] BUG: KASAN: slab-out-of-bounds in linear_transfer+0x6de/0x970 sound/core/oss/linear.c:88 Read of size 1 at addr ffff88809899f0b8 by task syz-executor.2/7877 CPU: 1 PID: 7877 Comm: syz-executor.2 Not tainted 5.0.0+ #24 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x172/0x1f0 lib/dump_stack.c:113 print_address_description.cold+0x7c/0x20d mm/kasan/report.c:187 kasan_report.cold+0x1b/0x40 mm/kasan/report.c:317 check_memory_region_inline mm/kasan/generic.c:185 [inline] check_memory_region+0x123/0x190 mm/kasan/generic.c:191 memcpy+0x24/0x50 mm/kasan/common.c:132 memcpy include/linux/string.h:352 [inline] do_convert sound/core/oss/linear.c:48 [inline] convert sound/core/oss/linear.c:81 [inline] linear_transfer sound/core/oss/linear.c:110 [inline] linear_transfer+0x6de/0x970 sound/core/oss/linear.c:88 snd_pcm_plug_read_transfer+0x1a1/0x2f0 sound/core/oss/pcm_plugin.c:651 snd_pcm_oss_read2+0x1f0/0x3f0 sound/core/oss/pcm_oss.c:1474 snd_pcm_oss_read1 sound/core/oss/pcm_oss.c:1531 [inline] snd_pcm_oss_read+0x53a/0x6a0 sound/core/oss/pcm_oss.c:2751 __vfs_read+0x8d/0x110 fs/read_write.c:416 vfs_read+0x194/0x3e0 fs/read_write.c:452 ksys_read+0xea/0x1f0 fs/read_write.c:578 __do_sys_read fs/read_write.c:588 [inline] __se_sys_read fs/read_write.c:586 [inline] __ia32_sys_read+0x71/0xb0 fs/read_write.c:586 do_syscall_32_irqs_on arch/x86/entry/common.c:326 [inline] do_fast_syscall_32+0x281/0xc98 arch/x86/entry/common.c:397 entry_SYSENTER_compat+0x70/0x7f arch/x86/entry/entry_64_compat.S:139 RIP: 0023:0xf7f66869 Code: 85 d2 74 02 89 0a 5b 5d c3 8b 04 24 c3 8b 14 24 c3 8b 3c 24 c3 90 90 90 90 90 90 90 90 90 90 90 90 51 52 55 89 e5 0f 34 cd 80 <5d> 5a 59 c3 90 90 90 90 eb 0d 90 90 90 90 90 90 90 90 90 90 90 90 RSP: 002b:00000000f7f620cc EFLAGS: 00000296 ORIG_RAX: 0000000000000003 RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00000000200012c0 RDX: 0000000000001000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 Allocated by task 7877: save_stack+0x45/0xd0 mm/kasan/common.c:75 set_track mm/kasan/common.c:87 [inline] __kasan_kmalloc mm/kasan/common.c:497 [inline] __kasan_kmalloc.constprop.0+0xcf/0xe0 mm/kasan/common.c:470 kasan_kmalloc+0x9/0x10 mm/kasan/common.c:511 __do_kmalloc_node mm/slab.c:3686 [inline] __kmalloc_node+0x4e/0x70 mm/slab.c:3693 kmalloc_node include/linux/slab.h:588 [inline] kvmalloc_node+0x68/0x100 mm/util.c:430 kvmalloc include/linux/mm.h:605 [inline] kvzalloc include/linux/mm.h:613 [inline] snd_pcm_plugin_alloc+0x585/0x770 sound/core/oss/pcm_plugin.c:70 snd_pcm_plug_alloc+0x148/0x330 sound/core/oss/pcm_plugin.c:129 snd_pcm_oss_change_params_locked+0x2118/0x3750 sound/core/oss/pcm_oss.c:1038 snd_pcm_oss_change_params+0x7b/0xd0 sound/core/oss/pcm_oss.c:1101 snd_pcm_oss_get_active_substream+0x136/0x190 sound/core/oss/pcm_oss.c:1118 snd_pcm_oss_get_rate sound/core/oss/pcm_oss.c:1768 [inline] snd_pcm_oss_set_rate sound/core/oss/pcm_oss.c:1760 [inline] snd_pcm_oss_ioctl+0x8f7/0x3430 sound/core/oss/pcm_oss.c:2607 snd_pcm_oss_ioctl_compat+0x24/0x30 sound/core/oss/pcm_oss.c:2734 __do_compat_sys_ioctl fs/compat_ioctl.c:1052 [inline] __se_compat_sys_ioctl fs/compat_ioctl.c:998 [inline] __ia32_compat_sys_ioctl+0x197/0x620 fs/compat_ioctl.c:998 do_syscall_32_irqs_on arch/x86/entry/common.c:326 [inline] do_fast_syscall_32+0x281/0xc98 arch/x86/entry/common.c:397 entry_SYSENTER_compat+0x70/0x7f arch/x86/entry/entry_64_compat.S:139 Freed by task 0: (stack is not available) The buggy address belongs to the object at ffff88809899e500 which belongs to the cache kmalloc-4k of size 4096 The buggy address is located 3000 bytes inside of 4096-byte region [ffff88809899e500, ffff88809899f500) The buggy address belongs to the page: page:ffffea0002626780 count:1 mapcount:0 mapping:ffff88812c3f0dc0 index:0x0 compound_mapcount: 0 flags: 0x1fffc0000010200(slab|head) raw: 01fffc0000010200 ffffea00022bc088 ffffea0002841208 ffff88812c3f0dc0 raw: 0000000000000000 ffff88809899e500 0000000100000001 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff88809899ef80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff88809899f000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > ffff88809899f080: 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc fc ^ ffff88809899f100: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff88809899f180: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ================================================================== --- This bug is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkaller(a)googlegroups.com. syzbot will keep track of this bug report. See: https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with syzbot. syzbot can test patches for this bug, for details see: https://goo.gl/tpsmEJ#testing-patches

1 2

[alsa-devel] [PATCH] ALSA: firewire-motu: use 'version' field of unit directory to identify model
by Takashi Sakamoto 17 Mar '19

17 Mar '19

Current ALSA firewire-motu driver uses the value of 'model' field of unit directory in configuration ROM for modalias for MOTU FireWire models. However, as long as I checked, Pre8 and 828mk3(Hybrid) have the same value for the field (=0x100800). unit | version | model --------------- | --------- | ---------- 828mkII | 0x000003 | 0x101800 Traveler | 0x000009 | 0x107800 Pre8 | 0x00000f | 0x100800 <- 828mk3(FW) | 0x000015 | 0x106800 AudioExpress | 0x000033 | 0x104800 828mk3(Hybrid) | 0x000035 | 0x100800 <- When updating firmware for MOTU 8pre FireWire from v1.0.0 to v1.0.3, I got change of the value from 0x100800 to 0x103800. On the other hand, the value of 'version' field is fixed to 0x00000f. As a quick glance, the higher 12 bits of the value of 'version' field represent firmware version, while the lower 12 bits is unknown. By induction, the value of 'version' field represents actual model. This commit changes modalias to match the value of 'version' field, instead of 'model' field. For degug, long name of added sound card includes hexadecimal value of 'model' field. Cc: <stable(a)vger.kernel.org> # v4.19+ Fixes: 6c5e1ac0e144 ("ALSA: firewire-motu: add support for Motu Traveler") Signed-off-by: Takashi Sakamoto <o-takashi(a)sakamocchi.jp> --- sound/firewire/motu/motu.c | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/sound/firewire/motu/motu.c b/sound/firewire/motu/motu.c index 220e61926ea4..513291ba0ab0 100644 --- a/sound/firewire/motu/motu.c +++ b/sound/firewire/motu/motu.c @@ -36,7 +36,7 @@ static void name_card(struct snd_motu *motu) fw_csr_iterator_init(&it, motu->unit->directory); while (fw_csr_iterator_next(&it, &key, &val)) { switch (key) { - case CSR_VERSION: + case CSR_MODEL: version = val; break; } @@ -46,7 +46,7 @@ static void name_card(struct snd_motu *motu) strcpy(motu->card->shortname, motu->spec->name); strcpy(motu->card->mixername, motu->spec->name); snprintf(motu->card->longname, sizeof(motu->card->longname), - "MOTU %s (version:%d), GUID %08x%08x at %s, S%d", + "MOTU %s (version:%06x), GUID %08x%08x at %s, S%d", motu->spec->name, version, fw_dev->config_rom[3], fw_dev->config_rom[4], dev_name(&motu->unit->device), 100 << fw_dev->max_speed); @@ -237,20 +237,20 @@ static const struct snd_motu_spec motu_audio_express = { #define SND_MOTU_DEV_ENTRY(model, data) \ { \ .match_flags = IEEE1394_MATCH_VENDOR_ID | \ - IEEE1394_MATCH_MODEL_ID | \ - IEEE1394_MATCH_SPECIFIER_ID, \ + IEEE1394_MATCH_SPECIFIER_ID | \ + IEEE1394_MATCH_VERSION, \ .vendor_id = OUI_MOTU, \ - .model_id = model, \ .specifier_id = OUI_MOTU, \ + .version = model, \ .driver_data = (kernel_ulong_t)data, \ } static const struct ieee1394_device_id motu_id_table[] = { - SND_MOTU_DEV_ENTRY(0x101800, &motu_828mk2), - SND_MOTU_DEV_ENTRY(0x107800, &snd_motu_spec_traveler), - SND_MOTU_DEV_ENTRY(0x106800, &motu_828mk3), /* FireWire only. */ - SND_MOTU_DEV_ENTRY(0x100800, &motu_828mk3), /* Hybrid. */ - SND_MOTU_DEV_ENTRY(0x104800, &motu_audio_express), + SND_MOTU_DEV_ENTRY(0x000003, &motu_828mk2), + SND_MOTU_DEV_ENTRY(0x000009, &snd_motu_spec_traveler), + SND_MOTU_DEV_ENTRY(0x000015, &motu_828mk3), /* FireWire only. */ + SND_MOTU_DEV_ENTRY(0x000035, &motu_828mk3), /* Hybrid. */ + SND_MOTU_DEV_ENTRY(0x000033, &motu_audio_express), { } }; MODULE_DEVICE_TABLE(ieee1394, motu_id_table); -- 2.19.1

2 1

[alsa-devel] Line 6 Helix support
by Marek Ryšavý 16 Mar '19

16 Mar '19

Dear Alsa developers, I would like to ask you about support of Line 6 Helix. I've found a working solution but probably not the best one. Is it possible to add this solution (maybe make from it a better one) to your Alsa project? On this page you can find the solution: https://line6.com/support/topic/4426-line-6-with-linux/ I can help you with debugging as owner of this device, but I wasn't even able to compile a linux with that solution. :) It would be really great and I with a lot of other people would be thankful to you, if you add support for this device. Best Regards, Marek Ryšavý

1 0

[alsa-devel] Android porting of alsa-lib
by Chih-Wei Huang 16 Mar '19

16 Mar '19

Tested OK on Android-x86 pie-x86 branch.

3 11

[alsa-devel] [PATCH] sound: sb8: add a check for request_region
by Kangjie Lu 16 Mar '19

16 Mar '19

In case request_region fails, the fix returns an error code to avoid NULL pointer dereference. Signed-off-by: Kangjie Lu <kjlu(a)umn.edu> --- sound/isa/sb/sb8.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/sound/isa/sb/sb8.c b/sound/isa/sb/sb8.c index aa2a83eb81a9..dc27a480c2d9 100644 --- a/sound/isa/sb/sb8.c +++ b/sound/isa/sb/sb8.c @@ -111,6 +111,10 @@ static int snd_sb8_probe(struct device *pdev, unsigned int dev) /* block the 0x388 port to avoid PnP conflicts */ acard->fm_res = request_region(0x388, 4, "SoundBlaster FM"); + if (!acard->fm_res) { + err = -EBUSY; + goto _err; + } if (port[dev] != SNDRV_AUTO_PORT) { if ((err = snd_sbdsp_create(card, port[dev], irq[dev], -- 2.17.1

2 1

[alsa-devel] [PATCH] sound: echoaudio: add a check for ioremap_nocache
by Kangjie Lu 16 Mar '19

16 Mar '19

In case ioremap_nocache fails, the fix releases chip and returns an error code upstream to avoid NULL pointer dereference. Signed-off-by: Kangjie Lu <kjlu(a)umn.edu> --- sound/pci/echoaudio/echoaudio.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/sound/pci/echoaudio/echoaudio.c b/sound/pci/echoaudio/echoaudio.c index ea876b0b02b9..dc0084dc8550 100644 --- a/sound/pci/echoaudio/echoaudio.c +++ b/sound/pci/echoaudio/echoaudio.c @@ -1952,6 +1952,11 @@ static int snd_echo_create(struct snd_card *card, } chip->dsp_registers = (volatile u32 __iomem *) ioremap_nocache(chip->dsp_registers_phys, sz); + if (!chip->dsp_registers) { + dev_err(chip->card->dev, "ioremap failed\n"); + snd_echo_free(chip); + return -ENOMEM; + } if (request_irq(pci->irq, snd_echo_interrupt, IRQF_SHARED, KBUILD_MODNAME, chip)) { -- 2.17.1

2 1

[alsa-devel] [asoc:for-5.2 15/17] nau8810.c:(.text.nau8810_calc_pll+0xd8): undefined reference to `__udivdi3'
by kbuild test robot 16 Mar '19

16 Mar '19

tree: https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-5.2 head: 3789debfc379ac84b90e2db32d7a6b66d28a2c7c commit: 709a9b8a1f4ff6c34c0a6e6fefb31cfb23b19bf5 [15/17] ASoC: nau8810: fix the typo of function name config: mips-allyesconfig (attached as .config) compiler: mips-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0 reproduce: wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross git checkout 709a9b8a1f4ff6c34c0a6e6fefb31cfb23b19bf5 # save the attached .config to linux build tree GCC_VERSION=7.2.0 make.cross ARCH=mips All errors (new ones prefixed by >>): sound/soc/codecs/nau8810.o: In function `nau8810_calc_pll': >> nau8810.c:(.text.nau8810_calc_pll+0xd8): undefined reference to `__udivdi3' --- 0-DAY kernel test infrastructure Open Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation

1 0

[alsa-devel] [PATCH] ASoC: topology: create tlv before soc_tplg_init_kcontrol
by Bard liao 15 Mar '19

15 Mar '19

Component driver may want to use tlv data. Create tlv before soc_tplg_init_kcontrol so component driver can use the tlv data in the control_load ops. Signed-off-by: Bard liao <yung-chuan.liao(a)linux.intel.com> --- sound/soc/soc-topology.c | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/sound/soc/soc-topology.c b/sound/soc/soc-topology.c index 25fca7055464..fbee4720b834 100644 --- a/sound/soc/soc-topology.c +++ b/sound/soc/soc-topology.c @@ -894,19 +894,20 @@ static int soc_tplg_dmixer_create(struct soc_tplg *tplg, unsigned int count, continue; } + /* create any TLV data */ + soc_tplg_create_tlv(tplg, &kc, &mc->hdr); + /* pass control to driver for optional further init */ err = soc_tplg_init_kcontrol(tplg, &kc, (struct snd_soc_tplg_ctl_hdr *) mc); if (err < 0) { dev_err(tplg->dev, "ASoC: failed to init %s\n", mc->hdr.name); + soc_tplg_free_tlv(tplg, &kc); kfree(sm); continue; } - /* create any TLV data */ - soc_tplg_create_tlv(tplg, &kc, &mc->hdr); - /* register control here */ err = soc_tplg_add_kcontrol(tplg, &kc, &sm->dobj.control.kcontrol); @@ -1324,18 +1325,19 @@ static struct snd_kcontrol_new *soc_tplg_dapm_widget_dmixer_create( continue; } + /* create any TLV data */ + soc_tplg_create_tlv(tplg, &kc[i], &mc->hdr); + /* pass control to driver for optional further init */ err = soc_tplg_init_kcontrol(tplg, &kc[i], (struct snd_soc_tplg_ctl_hdr *)mc); if (err < 0) { dev_err(tplg->dev, "ASoC: failed to init %s\n", mc->hdr.name); + soc_tplg_free_tlv(tplg, &kc[i]); kfree(sm); continue; } - - /* create any TLV data */ - soc_tplg_create_tlv(tplg, &kc[i], &mc->hdr); } return kc; -- 2.17.1

3 2

[alsa-devel] Playing a wav file for a tone in an embedded project
by Jeff Horn 15 Mar '19

15 Mar '19

Hi, I am working on an embedded project ( i.MX6 ) and having an issue using a wav file for a tone in a Qt application. I am upgrading an existing project from Qt 5.3 with alsa-lib 1.0.8 and a 3.10.17 kernel to Qt 5.11 with alsa-lib 1.1.6 and a 4.9.123 kernel. The beep code is pretty simple, it loads a wav file and saves the wav data in a buffer. Then on each click event in Qt a beep() function is called. The beep() function calls snd_pcm_prepare() -> snd_pcm_writei() -> snd_pcm_drain(). With the previous release the entire beep() function takes ~160ms with the snd_pcm_prepare() close to 0ms. However, with the latest release the beep() function takes 550ms with 400ms in snd_pcm_prepare(). I tried to trace snd_pcm_prepare() in the kernel and found that the code path lands in dapm_power_widgets() and this is where a majority of the prepare call path time is spent. I don't know why the previous release seems to almost bypass snd_pcm_prepare() and the newer code base does not. So, is there a way to load a wav file on startup, save the wav data and then on each invocation of a beep() function play the data without having to call prepare each time? Thanks in advance for any suggestions/help Cheers, Jeff

1 0

[alsa-devel] [PATCH] ASoC: nau8810: fix arm-linux-gnueabi-gcc 7.2.0 compile error
by John Hsu 15 Mar '19

15 Mar '19

The patch fixes the compile error at the branch 'asoc for-5.2' as follows: compiler: arm-linux-gnueabi-gcc (Debian 7.2.0-11) 7.2.0 ERROR: "__aeabi_uldivmod" [sound/soc/codecs/snd-soc-nau8810.ko] undefined! Signed-off-by: John Hsu <KCHSU0(a)nuvoton.com> --- sound/soc/codecs/nau8810.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/sound/soc/codecs/nau8810.c b/sound/soc/codecs/nau8810.c index 5d300b790f78..ede2030b987a 100644 --- a/sound/soc/codecs/nau8810.c +++ b/sound/soc/codecs/nau8810.c @@ -21,6 +21,7 @@ #include <linux/i2c.h> #include <linux/regmap.h> #include <linux/slab.h> +#include <linux/math64.h> #include <sound/core.h> #include <sound/pcm.h> #include <sound/pcm_params.h> @@ -497,6 +498,7 @@ static int nau8810_calc_pll(unsigned int pll_in, unsigned int fs, struct nau8810_pll *pll_param) { u64 f2, f2_max, pll_ratio; + u32 mclk_scaler; int i, scal_sel; if (pll_in > NAU_PLL_REF_MAX || pll_in < NAU_PLL_REF_MIN) @@ -505,7 +507,8 @@ static int nau8810_calc_pll(unsigned int pll_in, f2_max = 0; scal_sel = ARRAY_SIZE(nau8810_mclk_scaler); for (i = 0; i < ARRAY_SIZE(nau8810_mclk_scaler); i++) { - f2 = 256ULL * fs * 4 * nau8810_mclk_scaler[i] / 10; + mclk_scaler = 4 * nau8810_mclk_scaler[i] / 10; + f2 = 256ULL * fs * mclk_scaler; if (f2 > NAU_PLL_FREQ_MIN && f2 < NAU_PLL_FREQ_MAX && f2_max < f2) { f2_max = f2; -- 2.18.0

1 0