mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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: emux: Guard the OSS argument during port initialization
Date: Wed, 14 Oct 2026 08:16:26 +0200	[thread overview]
Message-ID: <87bj8wg62t.wl-tiwai@suse.de> (raw)
In-Reply-To: <pm-pmb-f8d6ccb28f196910444f-v2-c253bf022b6e954a7bdc@gmail.com>

On Wed, 14 Oct 2026 06:02:50 +0200,
Cen Zhang wrote:
> 
> The OSS argument must be non-NULL before reset_port_mode() writes its
> event_passing field. snd_emux_open_seq_oss() assigns p->oss_arg only
> after snd_emux_create_port() attaches the writable sequencer port, so
> this field is still NULL when the callback first becomes reachable.
> 
> With sequencer OSS and an EMUX provider enabled, another sequencer
> client can learn the new address from a PORT_START announcement and
> send a direct SNDRV_SEQ_EVENT_OSS channel-mode command, with marker
> 0xfe and command byte 0x8a. The following ordering is possible:
> 
>   OSS opener                        Sequencer writer
>   snd_emux_create_port()
>     snd_seq_event_port_attach()
>       publish port, announce
>                                     receive PORT_START
>                                     snd_seq_write()
>                                       snd_emux_event_oss_input()
>                                         reset_port_mode()
>                                           write via NULL oss_arg
>   p->oss_arg = arg
> 
> The callback's write precedes the opener's assignment. The core's port
> reference keeps the private data allocated but does not wait for its
> initialization. The write therefore dereferences NULL and can panic the
> kernel, as shown by the report below.
> 
> Take a single READ_ONCE() snapshot of oss_arg and update event_passing
> only when that snapshot is non-NULL. Pair it with WRITE_ONCE() in the
> open path, so the check and write use the same pointer despite
> concurrent initialization. The open path still sets the initial mode
> after assigning the argument, and subsequent channel-mode events retain
> their existing handling.
> 
> KASAN report as below:
> 
>     Oops: general protection fault, probably for non-canonical address 0xdffffc0000000003: 0000 [#1] SMP KASAN NOPTI
>     KASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f]
>     CPU: 2 UID: 0 PID: 495 Comm: fixture 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_emux_event_oss_input+0xa76/0xdd0
>     Code: fc ff df 48 c1 ea 03 80 3c 02 00 0f 85 e1 02 00 00 48 b8 00 00 00 00 00 fc ff df 48 8b 5d 78 48 8d 7b 18 48 89 fa 48 c1 ea 03 <0f> b6 04 02 84 c0 74 08 3c 03 0f 8e 40 03 00 00 c7 43 18 00 00 00
>     RSP: 0018:ffff88810a937888 EFLAGS: 00010216
>     RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffffff84f391b2
>     RDX: 0000000000000003 RSI: 0000000000000000 RDI: 0000000000000018
>     RBP: ffff8881179fc000 R08: 0000000000000001 R09: 0000000000000001
>     R10: ffffffff89444257 R11: ffff888107dd3a00 R12: 1ffff11021526f17
>     R13: 0000000000000000 R14: 0000000000000001 R15: ffff888112cda000
>     FS:  00007fdd13c9f780(0000) GS:ffff8881fd826000(0000) knlGS:0000000000000000
>     CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>     CR2: 00007fdd13e2f943 CR3: 00000001057ba005 CR4: 0000000000770ef0
>     PKRU: 55555554
>     Call Trace:
>      <TASK>
>      ? __pfx_snd_emux_event_oss_input+0x10/0x10
>      ? snd_seq_port_use_ptr+0x40/0x170
>      ? srso_alias_return_thunk+0x5/0xfbef5
>      ? find_held_lock+0x2b/0x80
>      ? snd_seq_port_use_ptr+0x10c/0x170
>      ? srso_alias_return_thunk+0x5/0xfbef5
>      ? lock_release+0xc8/0x280
>      ? srso_alias_return_thunk+0x5/0xfbef5
>      ? __pfx_snd_emux_event_oss_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
>      ? srso_alias_return_thunk+0x5/0xfbef5
>      ? add_lock_to_list+0x9d/0x1e0
>      ? srso_alias_return_thunk+0x5/0xfbef5
>      ? check_prev_add+0x34c/0xe80
>      snd_seq_deliver_event+0x45a/0x760
>      ? __pfx_snd_seq_deliver_event+0x10/0x10
>      ? srso_alias_return_thunk+0x5/0xfbef5
>      ? srso_alias_return_thunk+0x5/0xfbef5
>      ? lock_acquire+0x17b/0x2f0
>      snd_seq_client_enqueue_event.constprop.0+0x278/0x430
>      ? __pfx_snd_seq_client_enqueue_event.constprop.0+0x10/0x10
>      ? __might_fault+0xdd/0x190
>      ? srso_alias_return_thunk+0x5/0xfbef5
>      ? __might_fault+0x14e/0x190
>      ? _raw_spin_unlock_irq+0x28/0x50
>      snd_seq_write+0x30a/0x5e0
>      ? __pfx_snd_seq_write+0x10/0x10
>      ? selinux_file_permission+0x122/0x570
>      ? srso_alias_return_thunk+0x5/0xfbef5
>      ? security_file_permission+0x26/0x80
>      vfs_write+0x25a/0x1010
>      ? __pfx_snd_seq_write+0x10/0x10
>      ? __pfx_vfs_write+0x10/0x10
>      ? srso_alias_return_thunk+0x5/0xfbef5
>      ? trace_hardirqs_on+0x18/0x160
>      ? srso_alias_return_thunk+0x5/0xfbef5
>      ? __call_rcu_common.constprop.0+0x5c1/0xbd0
>      ? srso_alias_return_thunk+0x5/0xfbef5
>      ? __fput+0x5ba/0xa60
>      ksys_write+0x1b7/0x200
>      ? __pfx_ksys_write+0x10/0x10
>      do_syscall_64+0x115/0x6a0
>      entry_SYSCALL_64_after_hwframe+0x77/0x7f
>     RIP: 0033:0x7fdd13d31687
>     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:00007fff073e9f20 EFLAGS: 00000202 ORIG_RAX: 0000000000000001
>     RAX: ffffffffffffffda RBX: 00007fdd13c9f780 RCX: 00007fdd13d31687
>     RDX: 000000000000001c RSI: 00007fff073e9fc0 RDI: 0000000000000003
>     RBP: 0000000000000003 R08: 0000000000000000 R09: 0000000000000000
>     R10: 0000000000000000 R11: 0000000000000202 R12: 0000561260c48082
>     R13: 0000561260c48011 R14: 0000561260c4809d R15: 0000000000000002
>      </TASK>
>     Modules linked in: snd_emux_validation(O)
>     ---[ end trace 0000000000000000 ]---
>     RIP: 0010:snd_emux_event_oss_input+0xa76/0xdd0
>     Code: fc ff df 48 c1 ea 03 80 3c 02 00 0f 85 e1 02 00 00 48 b8 00 00 00 00 00 fc ff df 48 8b 5d 78 48 8d 7b 18 48 89 fa 48 c1 ea 03 <0f> b6 04 02 84 c0 74 08 3c 03 0f 8e 40 03 00 00 c7 43 18 00 00 00
>     RSP: 0018:ffff88810a937888 EFLAGS: 00010216
>     RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffffff84f391b2
>     RDX: 0000000000000003 RSI: 0000000000000000 RDI: 0000000000000018
>     RBP: ffff8881179fc000 R08: 0000000000000001 R09: 0000000000000001
>     R10: ffffffff89444257 R11: ffff888107dd3a00 R12: 1ffff11021526f17
>     R13: 0000000000000000 R14: 0000000000000001 R15: ffff888112cda000
>     FS:  00007fdd13c9f780(0000) GS:ffff8881fd826000(0000) knlGS:0000000000000000
>     CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>     CR2: 00007fdd13e2f943 CR3: 00000001057ba005 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

      reply	other threads:[~2026-10-14  6:16 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-14  4:02 Cen Zhang
2026-10-14  6:16 ` 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=87bj8wg62t.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

all inboxes | Powered by JetHome®