From: Takashi Iwai <tiwai@suse.de>
To: Cen Zhang <zzzccc427@gmail.com>
Cc: perex@perex.cz, tiwai@suse.com, kees@kernel.org,
linux-sound@vger.kernel.org, linux-kernel@vger.kernel.org,
baijiaju1990@gmail.com, jjzuming@gmail.com
Subject: Re: [PATCH] ALSA: vmaster: Protect follower lookup and setup
Date: Fri, 16 Oct 2026 10:21:44 +0200 [thread overview]
Message-ID: <87mrse5a3r.wl-tiwai@suse.de> (raw)
In-Reply-To: <pm-pmb-6c0b7e841529ddd0b21a-v2-b53dbcd593a7a4bd9582@gmail.com>
On Fri, 16 Oct 2026 04:02:29 +0200,
Cen Zhang wrote:
>
> A control selected by snd_ctl_add_followers() must remain alive until
> _snd_ctl_add_follower() has copied it and installed its wrapper. The
> lookup returns a raw pointer without retaining the control, and neither
> the short-lived list lookup lock nor the fast lookup protects later use.
>
> If a kernel client adds followers to a live virtual master while another
> client removes or replaces a published follower, the following order is
> possible, with the card and master kept alive:
>
> Follower setup Control removal
> snd_ctl_add_followers()
> snd_ctl_find_id_mixer()
> return follower
> snd_ctl_remove()
> down_write(controls_rwsem)
> __snd_ctl_remove()
> unlink follower
> snd_ctl_free_one(follower)
> up_write(controls_rwsem)
> _snd_ctl_add_follower()
> read follower->count
>
> Removal completes after lookup returns and before setup reads the
> control. Since setup holds neither controls_rwsem nor a reference, the
> count read and subsequent control copies can access freed memory.
>
> Hold controls_rwsem for writing across the lookup and follower setup.
> This prevents removal or replacement from freeing the selected control
> until wrapper installation is complete. Write ownership also excludes
> control callbacks while setup changes the callback and private fields.
>
> KASAN report as below:
>
> BUG: KASAN: slab-use-after-free in _snd_ctl_add_follower+0x452/0x520
> Read of size 4 at addr ffff888107957d50 by task loadmodule/491
>
> CPU: 3 UID: 0 PID: 491 Comm: loadmodule Tainted: G O 7.2.0-rc6-pmb-bt-functional-v1+ #1 PREEMPT(lazy)
> Tainted: [O]=OOT_MODULE
> Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
> Call Trace:
> <TASK>
> dump_stack_lvl+0x93/0xd0
> print_report+0xce/0x630
> ? _snd_ctl_add_follower+0x452/0x520
> ? srso_alias_return_thunk+0x5/0xfbef5
> ? __virt_addr_valid+0x20d/0x410
> ? _snd_ctl_add_follower+0x452/0x520
> kasan_report+0xe0/0x110
> ? _snd_ctl_add_follower+0x452/0x520
> _snd_ctl_add_follower+0x452/0x520
> snd_ctl_add_followers+0x153/0x2b0
> ? srso_alias_return_thunk+0x5/0xfbef5
> ? __pfx_snd_ctl_add_followers+0x10/0x10
> ? __might_fault+0x135/0x190
> ? srso_alias_return_thunk+0x5/0xfbef5
> ? __might_fault+0x14e/0x190
> ? __pfx_fixture_write+0x10/0x10 [pmbd_vmaster_fixture]
> fixture_write+0x174/0x1f0 [pmbd_vmaster_fixture]
> ? __pfx_fixture_write+0x10/0x10 [pmbd_vmaster_fixture]
> ? __pfx___might_resched+0x10/0x10
> proc_reg_write+0x1fb/0x2d0
> vfs_write+0x25a/0x1010
> ? __pfx_proc_reg_write+0x10/0x10
> ? kmem_cache_free+0x242/0x580
> ? __pfx_vfs_write+0x10/0x10
> ? srso_alias_return_thunk+0x5/0xfbef5
> ? putname+0x93/0xe0
> ? srso_alias_return_thunk+0x5/0xfbef5
> ? do_sys_openat2+0x12a/0x1b0
> ? __pfx_do_sys_openat2+0x10/0x10
> ksys_write+0x111/0x200
> ? __pfx_ksys_write+0x10/0x10
> ? irqentry_exit+0xbe/0x820
> ? srso_alias_return_thunk+0x5/0xfbef5
> do_syscall_64+0x115/0x6a0
> entry_SYSCALL_64_after_hwframe+0x77/0x7f
> RIP: 0033:0x7f0b835a9687
> Code: 48 89 fa 4c 89 df e8 58 b3 00 00 8b 93 08 03 00 00 59 5e 48 83 f8 fc 74 1a 5b c3 0f 1f 84 00 00 00 00 00 48 8b 44 24 10 0f 05 <5b> c3 0f 1f 80 00 00 00 00 83 e2 39 83 fa 08 75 de e8 23 ff ff ff
> RSP: 002b:00007ffc82ea0360 EFLAGS: 00000202 ORIG_RAX: 0000000000000001
> RAX: ffffffffffffffda RBX: 00007f0b83517780 RCX: 00007f0b835a9687
> RDX: 0000000000000005 RSI: 0000564f8a21d074 RDI: 0000000000000003
> RBP: 0000000000000003 R08: 0000000000000000 R09: 0000000000000000
> R10: 0000000000000000 R11: 0000000000000202 R12: 0000000000000000
> R13: 00007ffc82ea04f0 R14: 00007f0b83755000 R15: 0000564f8a21ed78
> </TASK>
>
> Allocated by task 485:
> kasan_save_stack+0x33/0x60
> kasan_save_track+0x14/0x30
> __kasan_kmalloc+0xaa/0xb0
> __kmalloc_noprof+0x2d7/0x770
> snd_ctl_new+0x51/0x190
> snd_ctl_new1+0x13c/0x650
> 0xffffffffc04011b5
> do_one_initcall+0xf3/0x4e0
> do_init_module+0x281/0x8e0
> load_module+0x658c/0x7cc0
> init_module_from_file+0x15b/0x180
> idempotent_init_module+0x22d/0x770
> __x64_sys_finit_module+0xd2/0x160
> do_syscall_64+0x115/0x6a0
> entry_SYSCALL_64_after_hwframe+0x77/0x7f
>
> Freed by task 492:
> kasan_save_stack+0x33/0x60
> kasan_save_track+0x14/0x30
> kasan_save_free_info+0x3b/0x60
> __kasan_slab_free+0x5f/0x80
> kfree+0x307/0x580
> __snd_ctl_remove+0x2ac/0x3d0
> snd_ctl_remove+0x46/0x70
> fixture_write+0x1ae/0x1f0 [pmbd_vmaster_fixture]
> proc_reg_write+0x1fb/0x2d0
> vfs_write+0x25a/0x1010
> ksys_write+0x111/0x200
> do_syscall_64+0x115/0x6a0
> entry_SYSCALL_64_after_hwframe+0x77/0x7f
>
> The buggy address belongs to the object at ffff888107957d00
> which belongs to the cache kmalloc-192 of size 192
> The buggy address is located 80 bytes inside of
> freed 192-byte region [ffff888107957d00, ffff888107957dc0)
>
> The buggy address belongs to the physical page:
> page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x107957
> flags: 0x200000000000000(node=0|zone=2)
> page_type: f5(slab)
> raw: 0200000000000000 ffff8881000423c0 dead000000000100 dead000000000122
> raw: 0000000000000000 0000000000100010 00000000f5000000 0000000000000000
> page dumped because: kasan: bad access detected
>
> Memory state around the buggy address:
> ffff888107957c00: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> ffff888107957c80: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
> >ffff888107957d00: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> ^
> ffff888107957d80: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
> ffff888107957e00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> ==================================================================
>
> Fixes: ae07eb9bf23e ("ALSA: vmaster: Add snd_ctl_add_followers() helper")
> Assisted-by: LLM
> Signed-off-by: Cen Zhang <zzzccc427@gmail.com>
Applied to for-next branch. Thanks.
Takashi
prev parent reply other threads:[~2026-10-16 8:21 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-16 2:02 Cen Zhang
2026-10-16 8:21 ` Takashi Iwai [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87mrse5a3r.wl-tiwai@suse.de \
--to=tiwai@suse.de \
--cc=baijiaju1990@gmail.com \
--cc=jjzuming@gmail.com \
--cc=kees@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-sound@vger.kernel.org \
--cc=perex@perex.cz \
--cc=tiwai@suse.com \
--cc=zzzccc427@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®