From: Takashi Iwai <tiwai@suse.de>
To: Cen Zhang <zzzccc427@gmail.com>
Cc: perex@perex.cz, tiwai@suse.com, linux-sound@vger.kernel.org,
linux-kernel@vger.kernel.org, baijiaju1990@gmail.com,
jjzuming@gmail.com
Subject: Re: [PATCH] ALSA: seq: oss: Ignore sync echoes without a write queue
Date: Fri, 16 Oct 2026 10:22:12 +0200 [thread overview]
Message-ID: <87ld7y5a2z.wl-tiwai@suse.de> (raw)
In-Reply-To: <pm-pmb-3634251be738461947da-v2-64371e8c8d6cbf6956a3@gmail.com>
On Fri, 16 Oct 2026 04:17:58 +0200,
Cen Zhang wrote:
>
> The sync-echo callback needs a write queue before it can wake up a
> synchronizing writer. However, snd_seq_oss_open() publishes the session's
> port with snd_seq_oss_event_input() as its callback before allocating
> and assigning dp->writeq.
>
> A kernel caller using snd_seq_kernel_client_dispatch() with the OSS
> client ID can deliver an ECHO containing SEQ_SYNCTIMER to this port
> before the write queue is assigned. The helper stamps the supplied
> client ID into the event, so the callback's source-client check accepts
> it. Regular userspace events carry their own client ID and are rejected.
>
> The failing ordering is:
>
> OSS open Kernel direct dispatch
> -------- ----------------------
> Zero-allocate dp
> Set dp->cseq
> Publish callback port
> Dispatch ECHO as the OSS client
> Look up and pin that port
> Enter snd_seq_oss_event_input()
> Pass NULL to writeq_wakeup()
> Allocate and assign dp->writeq
>
> Dispatch reaches the callback after port publication and before the
> queue assignment. OSS register_mutex serializes open and release, but
> direct dispatch does not take it. The port use reference keeps dp alive
> through the callback; it does not wait for constructor initialization.
> The wakeup helper therefore attempts to acquire sync_lock through a
> NULL queue pointer, causing a fault.
>
> Sample dp->writeq once in the SEQ_SYNCTIMER branch and ignore the echo
> when the queue is absent, matching the adjacent read-queue check. Pass
> the checked pointer to the wakeup helper so a NULL sample cannot reach
> the lock access. The existing port reference protects the queue's
> lifetime through this call, since port deletion drains callbacks before
> free_devinfo() frees the queue.
>
> KASAN report as below:
>
> Oops: general protection fault, probably for non-canonical address 0xdffffc000000000d: 0000 [#1] SMP KASAN NOPTI
> KASAN: null-ptr-deref in range [0x0000000000000068-0x000000000000006f]
> CPU: 2 UID: 0 PID: 69 Comm: kworker/2:1 Tainted: G W 7.2.0-rc6-pmb-bt-functional-v1+ #1 PREEMPT(lazy)
> Tainted: [W]=WARN
> 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
> Workqueue: events pmbd_dispatch_early_sync_echo
> RIP: 0010:do_raw_spin_lock+0x71/0x270
> Code: d0 60 81 49 8d 14 04 c7 02 f1 f1 f1 f1 c7 42 04 04 f3 f3 f3 65 48 8b 15 05 df 88 09 48 89 54 24 60 31 d2 48 89 fa 48 c1 ea 03 <0f> b6 14 02 48 89 f8 83 e0 07 83 c0 03 38 d0 7c 08 84 d2 0f 85 b9
> RSP: 0018:ffff88810450f878 EFLAGS: 00010013
> RAX: dffffc0000000000 RBX: 0000000000000068 RCX: 0000000000000000
> RDX: 000000000000000d RSI: 0000000000000000 RDI: 000000000000006c
> RBP: 0000000000000293 R08: 0000000000000001 R09: 0000000000000000
> R10: ffffffff8940fe57 R11: 0000000000000000 R12: 1ffff110208a1f10
> R13: 0000000000000068 R14: 0000000000000001 R15: ffff88810450fbee
> FS: 0000000000000000(0000) GS:ffff8881fd885000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 00000000006d2890 CR3: 0000000106cbf002 CR4: 0000000000770ef0
> PKRU: 55555554
> Call Trace:
> <TASK>
> ? pmbd_probe_hit_cookie+0xee/0x1c0
> ? __pfx_do_raw_spin_lock+0x10/0x10
> ? lock_acquire+0x2b8/0x2f0
> ? __pfx_pmbd_probe_hit_cookie+0x10/0x10
> _raw_spin_lock_irqsave+0x44/0x60
> ? snd_seq_oss_writeq_wakeup+0x30/0xf0
> snd_seq_oss_writeq_wakeup+0x30/0xf0
> snd_seq_oss_event_input+0x1e4/0x2a0
> ? do_raw_read_unlock+0x49/0xe0
> ? __pfx_snd_seq_oss_event_input+0x10/0x10
> __snd_seq_deliver_single_event+0x105/0x1a0
> ? snd_seq_port_use_ptr+0x111/0x170
> snd_seq_deliver_single_event+0x2fc/0x770
> ? __pfx_snd_seq_deliver_single_event+0x10/0x10
> ? __pfx_pmbd_hold_maybe+0x10/0x10
> snd_seq_deliver_event+0x45a/0x760
> ? __pfx_do_raw_spin_lock+0x10/0x10
> ? lock_acquire+0x2b8/0x2f0
> ? srso_alias_return_thunk+0x5/0xfbef5
> ? __pfx_snd_seq_deliver_event+0x10/0x10
> ? _raw_spin_unlock_irqrestore+0x44/0x60
> ? srso_alias_return_thunk+0x5/0xfbef5
> ? trace_hardirqs_on+0x18/0x160
> ? srso_alias_return_thunk+0x5/0xfbef5
> ? _raw_spin_unlock_irqrestore+0x44/0x60
> ? srso_alias_return_thunk+0x5/0xfbef5
> snd_seq_kernel_client_dispatch+0x19c/0x1e0
> pmbd_dispatch_early_sync_echo+0x121/0x1c0
> ? __pfx_pmbd_dispatch_early_sync_echo+0x10/0x10
> ? srso_alias_return_thunk+0x5/0xfbef5
> ? finish_task_switch.isra.0+0x1dc/0x980
> process_one_work+0x908/0x19c0
> ? __pfx_process_one_work+0x10/0x10
> ? srso_alias_return_thunk+0x5/0xfbef5
> worker_thread+0x65c/0xe40
> ? srso_alias_return_thunk+0x5/0xfbef5
> ? __kthread_parkme+0x175/0x220
> ? srso_alias_return_thunk+0x5/0xfbef5
> ? __pfx_worker_thread+0x10/0x10
> kthread+0x34f/0x460
> ? srso_alias_return_thunk+0x5/0xfbef5
> ? __pfx_kthread+0x10/0x10
> ret_from_fork+0x659/0x940
> ? __pfx_ret_from_fork+0x10/0x10
> ? srso_alias_return_thunk+0x5/0xfbef5
> ? __switch_to+0x74f/0xf80
> ? __pfx_kthread+0x10/0x10
> ret_from_fork_asm+0x1a/0x30
> </TASK>
> Modules linked in:
> ---[ end trace 0000000000000000 ]---
> RIP: 0010:do_raw_spin_lock+0x71/0x270
> Code: d0 60 81 49 8d 14 04 c7 02 f1 f1 f1 f1 c7 42 04 04 f3 f3 f3 65 48 8b 15 05 df 88 09 48 89 54 24 60 31 d2 48 89 fa 48 c1 ea 03 <0f> b6 14 02 48 89 f8 83 e0 07 83 c0 03 38 d0 7c 08 84 d2 0f 85 b9
> RSP: 0018:ffff88810450f878 EFLAGS: 00010013
> RAX: dffffc0000000000 RBX: 0000000000000068 RCX: 0000000000000000
> RDX: 000000000000000d RSI: 0000000000000000 RDI: 000000000000006c
> RBP: 0000000000000293 R08: 0000000000000001 R09: 0000000000000000
> R10: ffffffff8940fe57 R11: 0000000000000000 R12: 1ffff110208a1f10
> R13: 0000000000000068 R14: 0000000000000001 R15: ffff88810450fbee
> FS: 0000000000000000(0000) GS:ffff8881fd885000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 00000000006d2890 CR3: 0000000106cbf002 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. Thanks.
Takashi
prev parent reply other threads:[~2026-10-16 8:22 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-16 2:17 [PATCH] ALSA: seq: oss: Ignore sync echoes without a write queue Cen Zhang
2026-10-16 8:22 ` 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=87ld7y5a2z.wl-tiwai@suse.de \
--to=tiwai@suse.de \
--cc=baijiaju1990@gmail.com \
--cc=jjzuming@gmail.com \
--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