Linux Sound subsystem development
 help / color / mirror / Atom feed
From: Takashi Iwai <tiwai@suse.de>
To: Cen Zhang <zzzccc427@gmail.com>
Cc: perex@perex.cz, tiwai@suse.com, phucduc.bui@gmail.com,
	cezary.rojewski@intel.com, kees+treewide@kernel.org,
	error27@gmail.com, linux-sound@vger.kernel.org,
	linux-kernel@vger.kernel.org, baijiaju1990@gmail.com,
	jjzuming@gmail.com
Subject: Re: [PATCH] ALSA: mixer: oss: Serialize initial slot construction
Date: Thu, 15 Oct 2026 21:53:01 +0200	[thread overview]
Message-ID: <871p9q7nc2.wl-tiwai@suse.de> (raw)
In-Reply-To: <pm-pmb-99c1214968ae9fa4d744-v2-df0befb9a699eb50dcec@gmail.com>

On Thu, 15 Oct 2026 19:11:38 +0200,
Cen Zhang wrote:
> 
> OSS mixer slot callbacks require an initialized private_data payload.
> However, snd_mixer_oss_notify_handler() publishes card->mixer_oss before
> snd_mixer_oss_build() constructs the default bindings, and
> snd_mixer_oss_build_input() stores get_volume before private_data.
> 
> With OSS mixer emulation enabled and a native control matching a default
> mapping, a volume read can arrive during initial binding construction.
> For example, the dummy card provides the Master Volume control before
> registration. The following ordering lets the read use the callback
> before its payload is attached:
> 
>     Card registration                    OSS volume read
>     -----------------                    ---------------
>     register the OSS mixer device
>     publish card->mixer_oss
>     store slot->get_volume
>                                          open the mixer device
>                                          lock reg_mutex
>                                          invoke slot->get_volume
>                                          load NULL private_data
>                                          read slot->present
>     store slot->private_data
> 
> The read holds reg_mutex, but the initial builder does not acquire it.
> The controls_rwsem read lock protects native controls and does not
> serialize the builder with another reader. As a result,
> snd_mixer_oss_get_volume1() can dereference a NULL payload and Oops.
> 
> Hold the existing reg_mutex throughout snd_mixer_oss_build(), as proc
> remapping already does for snd_mixer_oss_build_input(). A request can no
> longer invoke a callback between its installation and the payload store.
> This keeps the existing reg_mutex-before-controls_rwsem lock order.
> 
> KASAN report as below:
> 
>     Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN NOPTI
>     KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
>     CPU: 1 UID: 0 PID: 431 Comm: alsa-oss-trigge 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
>     RIP: 0010:snd_mixer_oss_get_volume1+0xd1/0x610 [snd_mixer_oss]
>     Code: 00 c7 03 64 00 00 00 e9 b8 01 00 00 e8 e8 82 44 c1 49 8d 75 04 48 b8 00 00 00 00 00 fc ff df 48 89 f2 48 89 34 24 48 c1 ea 03 <0f> b6 14 02 48 89 f0 83 e0 07 83 c0 03 38 d0 7c 08 84 d2 0f 85 3f
>     RSP: 0018:ffff888104c67cc8 EFLAGS: 00010257
>     RAX: dffffc0000000000 RBX: ffff888104c67d80 RCX: ffffffffc0406cb8
>     RDX: 0000000000000000 RSI: 0000000000000004 RDI: ffffffff862d93a4
>     RBP: ffff888104c67d90 R08: 0000000000000001 R09: 0000000000000001
>     R10: ffffffff89406e57 R11: ffff888104c9d700 R12: ffff888113c48038
>     R13: 0000000000000000 R14: ffff888113c48000 R15: ffff888104646820
>     FS:  00007f7904d29780(0000) GS:ffff8881fd81d000(0000) knlGS:0000000000000000
>     CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>     CR2: 00007f7904e388e0 CR3: 000000010662c002 CR4: 0000000000770ef0
>     PKRU: 55555554
>     Call Trace:
>      <TASK>
>      snd_mixer_oss_ioctl1+0x25d/0x16f0 [snd_mixer_oss]
>      ? srso_alias_return_thunk+0x5/0xfbef5
>      ? __pfx_snd_mixer_oss_get_volume1+0x10/0x10 [snd_mixer_oss]
>      ? __pfx_snd_mixer_oss_ioctl1+0x10/0x10 [snd_mixer_oss]
>      ? lock_release+0xc8/0x280
>      ? pmbd_site_is_armed+0xa1/0xd0
>      ? lockdep_hardirqs_on_prepare+0xea/0x1a0
>      ? trace_hardirqs_on+0x18/0x160
>      ? srso_alias_return_thunk+0x5/0xfbef5
>      ? _raw_spin_unlock_irqrestore+0x44/0x60
>      ? srso_alias_return_thunk+0x5/0xfbef5
>      ? pmbd_gate_site_armed+0x31/0x1c0
>      ? srso_alias_return_thunk+0x5/0xfbef5
>      ? pmbd_probe_hit_cookie+0xee/0x1c0
>      ? __pfx_pmbd_probe_hit_cookie+0x10/0x10
>      ? srso_alias_return_thunk+0x5/0xfbef5
>      ? selinux_file_ioctl+0xaa/0x280
>      snd_mixer_oss_ioctl+0x4a/0x80 [snd_mixer_oss]
>      ? __pfx_snd_mixer_oss_ioctl+0x10/0x10 [snd_mixer_oss]
>      __x64_sys_ioctl+0x163/0x1d0
>      do_syscall_64+0x115/0x6a0
>      entry_SYSCALL_64_after_hwframe+0x77/0x7f
>     RIP: 0033:0x7f7904e3891b
>     Code: 00 48 89 44 24 18 31 c0 48 8d 44 24 60 c7 04 24 10 00 00 00 48 89 44 24 08 48 8d 44 24 20 48 89 44 24 10 b8 10 00 00 00 0f 05 <89> c2 3d 00 f0 ff ff 77 1c 48 8b 44 24 18 64 48 2b 04 25 28 00 00
>     RSP: 002b:00007ffc72071e20 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
>     RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f7904e3891b
>     RDX: 00007ffc72071e84 RSI: 0000000080044d00 RDI: 0000000000000003
>     RBP: 0000000000000003 R08: 0000000000000000 R09: 0000000000000000
>     R10: 0000000000000000 R11: 0000000000000246 R12: 00007ffc72072e12
>     R13: 00007ffc72072060 R14: 00007f7904f67000 R15: 000055cd1e601d50
>      </TASK>
>     Modules linked in: snd_dummy(O) snd_mixer_oss(O)
>     ---[ end trace 0000000000000000 ]---
>     RIP: 0010:snd_mixer_oss_get_volume1+0xd1/0x610 [snd_mixer_oss]
>     Code: 00 c7 03 64 00 00 00 e9 b8 01 00 00 e8 e8 82 44 c1 49 8d 75 04 48 b8 00 00 00 00 00 fc ff df 48 89 f2 48 89 34 24 48 c1 ea 03 <0f> b6 14 02 48 89 f0 83 e0 07 83 c0 03 38 d0 7c 08 84 d2 0f 85 3f
>     RSP: 0018:ffff888104c67cc8 EFLAGS: 00010257
>     RAX: dffffc0000000000 RBX: ffff888104c67d80 RCX: ffffffffc0406cb8
>     RDX: 0000000000000000 RSI: 0000000000000004 RDI: ffffffff862d93a4
>     RBP: ffff888104c67d90 R08: 0000000000000001 R09: 0000000000000001
>     R10: ffffffff89406e57 R11: ffff888104c9d700 R12: ffff888113c48038
>     R13: 0000000000000000 R14: ffff888113c48000 R15: ffff888104646820
>     FS:  00007f7904d29780(0000) GS:ffff8881fd81d000(0000) knlGS:0000000000000000
>     CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>     CR2: 00007f7904e388e0 CR3: 000000010662c002 CR4: 0000000000770ef0
>     PKRU: 55555554
>     Kernel panic - not syncing: Fatal exception
>     Kernel Offset: disabled
>     Rebooting in 1 seconds..
> 
> Assisted-by: LLM
> Signed-off-by: Cen Zhang <zzzccc427@gmail.com>

Applied to for-next branch now.  Thanks.


Takashi

      reply	other threads:[~2026-10-15 19:53 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-15 17:11 [PATCH] ALSA: mixer: oss: Serialize initial slot construction Cen Zhang
2026-10-15 19:53 ` 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=871p9q7nc2.wl-tiwai@suse.de \
    --to=tiwai@suse.de \
    --cc=baijiaju1990@gmail.com \
    --cc=cezary.rojewski@intel.com \
    --cc=error27@gmail.com \
    --cc=jjzuming@gmail.com \
    --cc=kees+treewide@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-sound@vger.kernel.org \
    --cc=perex@perex.cz \
    --cc=phucduc.bui@gmail.com \
    --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