Re: sound: unable to handle kernel paging request snd_seq_prioq_cell_out
On Mon, Feb 6, 2017 at 3:24 PM, Takashi Iwai wrote: > On Tue, 31 Jan 2017 11:04:46 +0100, > Dmitry Vyukov wrote: >> >> Hello, >> >> The following program triggers wild memory access in snd_seq_prioq_cell_out: >> https://gist.githubusercontent.com/dvyukov/e0bfb47caf577217b3b0550866cba00b/raw/111473e99109fc96a1d3e252c3b8f982e8eaa265/gistfile1.txt >> >> BUG: unable to handle kernel paging request at c9000392ddb8 >> IP: snd_seq_prioq_cell_out+0x11d/0x260 sound/core/seq/seq_prioq.c:231 >> PGD 6cc6f067 >> PUD 6cc70067 >> PMD 5f94c067 >> PTE 0 >> Oops: [#1] SMP KASAN >> Modules linked in: >> CPU: 2 PID: 375 Comm: syz-executor Not tainted 4.10.0-rc5+ #201 >> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 >> task: 880066f92500 task.stack: 88005f74 >> RIP: 0010:snd_seq_prioq_cell_out+0x11d/0x260 sound/core/seq/seq_prioq.c:231 >> RSP: 0018:88005f7470b8 EFLAGS: 00010046 >> RAX: dc00 RBX: 11000bee8e18 RCX: c9c22000 >> RDX: 192000725bb7 RSI: 8348787e RDI: c9000392ddb8 >> RBP: 88005f747208 R08: 0001 R09: 0001 >> R10: dc00 R11: 0004 R12: 8800673cbe80 >> R13: 88005f7471e0 R14: c9000392dd90 R15: 8800673cbe98 >> FS: 7f5262fee700() GS:88006d10() knlGS: >> CS: 0010 DS: ES: CR0: 80050033 >> CR2: c9000392ddb8 CR3: 66209000 CR4: 001406e0 >> Call Trace: >> snd_seq_prioq_delete+0x8b/0xf0 sound/core/seq/seq_prioq.c:90 >> queue_delete+0x77/0xb0 sound/core/seq/seq_queue.c:152 >> snd_seq_queue_client_leave+0x34/0x130 sound/core/seq/seq_queue.c:595 >> seq_free_client1.part.5+0x10a/0x410 sound/core/seq/seq_clientmgr.c:258 >> seq_free_client1 sound/core/seq/seq_clientmgr.c:255 [inline] >> seq_free_client+0x6f/0x170 sound/core/seq/seq_clientmgr.c:284 >> snd_seq_release+0x51/0xe0 sound/core/seq/seq_clientmgr.c:366 >> __fput+0x332/0x7f0 fs/file_table.c:208 >> fput+0x15/0x20 fs/file_table.c:244 >> task_work_run+0x18a/0x260 kernel/task_work.c:116 >> get_signal+0x148f/0x1820 kernel/signal.c:2143 >> do_signal+0xd2/0x2190 arch/x86/kernel/signal.c:807 >> exit_to_usermode_loop+0x200/0x2a0 arch/x86/entry/common.c:156 >> prepare_exit_to_usermode arch/x86/entry/common.c:190 [inline] >> syscall_return_slowpath+0x4d3/0x570 arch/x86/entry/common.c:259 >> entry_SYSCALL_64_fastpath+0xc0/0xc2 >> RIP: 0033:0x4457d9 >> RSP: 002b:7f5262fedb58 EFLAGS: 0286 ORIG_RAX: 0010 >> RAX: RBX: 007080a8 RCX: 004457d9 >> RDX: 20001000 RSI: 4058534c RDI: 0005 >> RBP: 2250 R08: R09: >> R10: R11: 0286 R12: 006e0310 >> R13: 0005 R14: 4058534c R15: 20001000 >> Code: f6 0f 84 90 00 00 00 e8 02 1e 2a fe 49 8d 7e 28 48 b8 00 00 00 >> 00 00 fc ff df 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 1f 01 00 00 <49> >> 8b 46 28 49 8d 7c 24 08 48 89 fa 49 89 04 24 48 c1 ea 03 48 >> RIP: snd_seq_prioq_cell_out+0x11d/0x260 sound/core/seq/seq_prioq.c:231 >> RSP: 88005f7470b8 >> CR2: c9000392ddb8 >> ---[ end trace cbaec69c4a9fdbfc ]--- >> >> On commit fd694aaa46c7ed811b72eb47d5eb11ce7ab3f7f1 (Jan 26). > > This is due to a forced resource release after the loop timeout. > You must have seen a message like > ALSA: snd_seq_pool_done timeout: 1 cells remain > before the Oops. Yes, there are such messages. Applied locally for testing. Thanks! > Below is a simple fix. I'm going to queue it to for-linus branch. > > > thanks, > > Takashi > > -- 8< -- > From: Takashi Iwai > Subject: [PATCH] ALSA: seq: Don't handle loop timeout at snd_seq_pool_done() > > snd_seq_pool_done() syncs with closing of all opened threads, but it > aborts the wait loop with a timeout, and proceeds to the release > resource even if not all threads have been closed. The timeout was 5 > seconds, and if you run a crazy stuff, it can exceed easily, and may > result in the access of the invalid memory address -- this is what > syzkaller detected in a bug report. > > As a fix, let the code graduate from naiveness, simply remove the loop > timeout. > > BugLink: > http://lkml.kernel.org/r/cact4y+ydhdv2h5llzdtjdvf-qiyhuhhtraw4rbb4guhtcqb...@mail.gmail.com > Reported-by: Dmitry Vyukov > Cc: > Signed-off-by: Takashi Iwai > --- > sound/core/seq/seq_memory.c | 9 + > 1 file changed, 1 insertion(+), 8 deletions(-) > > diff --git a/sound/core/seq/seq_memory.c b/sound/core/seq/seq_memory.c > index c850345c43b5..dfa5156f3585 100644 > --- a/sound/core/seq/seq_memory.c > +++ b/sound/core/seq/seq_memory.c > @@ -419,7 +419,6 @@ int snd_seq_pool_done(struct snd_seq_pool *pool) > { > unsigned long flags; > struct snd_seq_event_cell *ptr; > - int max_count = 5 * HZ; > > if (snd_BUG_ON(!pool)) > return -EINVAL; > @@ -432,14 +431,8 @@ int snd
Re: sound: unable to handle kernel paging request snd_seq_prioq_cell_out
On Tue, 31 Jan 2017 11:04:46 +0100, Dmitry Vyukov wrote: > > Hello, > > The following program triggers wild memory access in snd_seq_prioq_cell_out: > https://gist.githubusercontent.com/dvyukov/e0bfb47caf577217b3b0550866cba00b/raw/111473e99109fc96a1d3e252c3b8f982e8eaa265/gistfile1.txt > > BUG: unable to handle kernel paging request at c9000392ddb8 > IP: snd_seq_prioq_cell_out+0x11d/0x260 sound/core/seq/seq_prioq.c:231 > PGD 6cc6f067 > PUD 6cc70067 > PMD 5f94c067 > PTE 0 > Oops: [#1] SMP KASAN > Modules linked in: > CPU: 2 PID: 375 Comm: syz-executor Not tainted 4.10.0-rc5+ #201 > Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 > task: 880066f92500 task.stack: 88005f74 > RIP: 0010:snd_seq_prioq_cell_out+0x11d/0x260 sound/core/seq/seq_prioq.c:231 > RSP: 0018:88005f7470b8 EFLAGS: 00010046 > RAX: dc00 RBX: 11000bee8e18 RCX: c9c22000 > RDX: 192000725bb7 RSI: 8348787e RDI: c9000392ddb8 > RBP: 88005f747208 R08: 0001 R09: 0001 > R10: dc00 R11: 0004 R12: 8800673cbe80 > R13: 88005f7471e0 R14: c9000392dd90 R15: 8800673cbe98 > FS: 7f5262fee700() GS:88006d10() knlGS: > CS: 0010 DS: ES: CR0: 80050033 > CR2: c9000392ddb8 CR3: 66209000 CR4: 001406e0 > Call Trace: > snd_seq_prioq_delete+0x8b/0xf0 sound/core/seq/seq_prioq.c:90 > queue_delete+0x77/0xb0 sound/core/seq/seq_queue.c:152 > snd_seq_queue_client_leave+0x34/0x130 sound/core/seq/seq_queue.c:595 > seq_free_client1.part.5+0x10a/0x410 sound/core/seq/seq_clientmgr.c:258 > seq_free_client1 sound/core/seq/seq_clientmgr.c:255 [inline] > seq_free_client+0x6f/0x170 sound/core/seq/seq_clientmgr.c:284 > snd_seq_release+0x51/0xe0 sound/core/seq/seq_clientmgr.c:366 > __fput+0x332/0x7f0 fs/file_table.c:208 > fput+0x15/0x20 fs/file_table.c:244 > task_work_run+0x18a/0x260 kernel/task_work.c:116 > get_signal+0x148f/0x1820 kernel/signal.c:2143 > do_signal+0xd2/0x2190 arch/x86/kernel/signal.c:807 > exit_to_usermode_loop+0x200/0x2a0 arch/x86/entry/common.c:156 > prepare_exit_to_usermode arch/x86/entry/common.c:190 [inline] > syscall_return_slowpath+0x4d3/0x570 arch/x86/entry/common.c:259 > entry_SYSCALL_64_fastpath+0xc0/0xc2 > RIP: 0033:0x4457d9 > RSP: 002b:7f5262fedb58 EFLAGS: 0286 ORIG_RAX: 0010 > RAX: RBX: 007080a8 RCX: 004457d9 > RDX: 20001000 RSI: 4058534c RDI: 0005 > RBP: 2250 R08: R09: > R10: R11: 0286 R12: 006e0310 > R13: 0005 R14: 4058534c R15: 20001000 > Code: f6 0f 84 90 00 00 00 e8 02 1e 2a fe 49 8d 7e 28 48 b8 00 00 00 > 00 00 fc ff df 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 1f 01 00 00 <49> > 8b 46 28 49 8d 7c 24 08 48 89 fa 49 89 04 24 48 c1 ea 03 48 > RIP: snd_seq_prioq_cell_out+0x11d/0x260 sound/core/seq/seq_prioq.c:231 > RSP: 88005f7470b8 > CR2: c9000392ddb8 > ---[ end trace cbaec69c4a9fdbfc ]--- > > On commit fd694aaa46c7ed811b72eb47d5eb11ce7ab3f7f1 (Jan 26). This is due to a forced resource release after the loop timeout. You must have seen a message like ALSA: snd_seq_pool_done timeout: 1 cells remain before the Oops. Below is a simple fix. I'm going to queue it to for-linus branch. thanks, Takashi -- 8< -- From: Takashi Iwai Subject: [PATCH] ALSA: seq: Don't handle loop timeout at snd_seq_pool_done() snd_seq_pool_done() syncs with closing of all opened threads, but it aborts the wait loop with a timeout, and proceeds to the release resource even if not all threads have been closed. The timeout was 5 seconds, and if you run a crazy stuff, it can exceed easily, and may result in the access of the invalid memory address -- this is what syzkaller detected in a bug report. As a fix, let the code graduate from naiveness, simply remove the loop timeout. BugLink: http://lkml.kernel.org/r/cact4y+ydhdv2h5llzdtjdvf-qiyhuhhtraw4rbb4guhtcqb...@mail.gmail.com Reported-by: Dmitry Vyukov Cc: Signed-off-by: Takashi Iwai --- sound/core/seq/seq_memory.c | 9 + 1 file changed, 1 insertion(+), 8 deletions(-) diff --git a/sound/core/seq/seq_memory.c b/sound/core/seq/seq_memory.c index c850345c43b5..dfa5156f3585 100644 --- a/sound/core/seq/seq_memory.c +++ b/sound/core/seq/seq_memory.c @@ -419,7 +419,6 @@ int snd_seq_pool_done(struct snd_seq_pool *pool) { unsigned long flags; struct snd_seq_event_cell *ptr; - int max_count = 5 * HZ; if (snd_BUG_ON(!pool)) return -EINVAL; @@ -432,14 +431,8 @@ int snd_seq_pool_done(struct snd_seq_pool *pool) if (waitqueue_active(&pool->output_sleep)) wake_up(&pool->output_sleep); - while (atomic_read(&pool->counter) > 0) { - if (max_count == 0) { - pr_warn("ALSA
sound: unable to handle kernel paging request snd_seq_prioq_cell_out
Hello, The following program triggers wild memory access in snd_seq_prioq_cell_out: https://gist.githubusercontent.com/dvyukov/e0bfb47caf577217b3b0550866cba00b/raw/111473e99109fc96a1d3e252c3b8f982e8eaa265/gistfile1.txt BUG: unable to handle kernel paging request at c9000392ddb8 IP: snd_seq_prioq_cell_out+0x11d/0x260 sound/core/seq/seq_prioq.c:231 PGD 6cc6f067 PUD 6cc70067 PMD 5f94c067 PTE 0 Oops: [#1] SMP KASAN Modules linked in: CPU: 2 PID: 375 Comm: syz-executor Not tainted 4.10.0-rc5+ #201 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 task: 880066f92500 task.stack: 88005f74 RIP: 0010:snd_seq_prioq_cell_out+0x11d/0x260 sound/core/seq/seq_prioq.c:231 RSP: 0018:88005f7470b8 EFLAGS: 00010046 RAX: dc00 RBX: 11000bee8e18 RCX: c9c22000 RDX: 192000725bb7 RSI: 8348787e RDI: c9000392ddb8 RBP: 88005f747208 R08: 0001 R09: 0001 R10: dc00 R11: 0004 R12: 8800673cbe80 R13: 88005f7471e0 R14: c9000392dd90 R15: 8800673cbe98 FS: 7f5262fee700() GS:88006d10() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: c9000392ddb8 CR3: 66209000 CR4: 001406e0 Call Trace: snd_seq_prioq_delete+0x8b/0xf0 sound/core/seq/seq_prioq.c:90 queue_delete+0x77/0xb0 sound/core/seq/seq_queue.c:152 snd_seq_queue_client_leave+0x34/0x130 sound/core/seq/seq_queue.c:595 seq_free_client1.part.5+0x10a/0x410 sound/core/seq/seq_clientmgr.c:258 seq_free_client1 sound/core/seq/seq_clientmgr.c:255 [inline] seq_free_client+0x6f/0x170 sound/core/seq/seq_clientmgr.c:284 snd_seq_release+0x51/0xe0 sound/core/seq/seq_clientmgr.c:366 __fput+0x332/0x7f0 fs/file_table.c:208 fput+0x15/0x20 fs/file_table.c:244 task_work_run+0x18a/0x260 kernel/task_work.c:116 get_signal+0x148f/0x1820 kernel/signal.c:2143 do_signal+0xd2/0x2190 arch/x86/kernel/signal.c:807 exit_to_usermode_loop+0x200/0x2a0 arch/x86/entry/common.c:156 prepare_exit_to_usermode arch/x86/entry/common.c:190 [inline] syscall_return_slowpath+0x4d3/0x570 arch/x86/entry/common.c:259 entry_SYSCALL_64_fastpath+0xc0/0xc2 RIP: 0033:0x4457d9 RSP: 002b:7f5262fedb58 EFLAGS: 0286 ORIG_RAX: 0010 RAX: RBX: 007080a8 RCX: 004457d9 RDX: 20001000 RSI: 4058534c RDI: 0005 RBP: 2250 R08: R09: R10: R11: 0286 R12: 006e0310 R13: 0005 R14: 4058534c R15: 20001000 Code: f6 0f 84 90 00 00 00 e8 02 1e 2a fe 49 8d 7e 28 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 1f 01 00 00 <49> 8b 46 28 49 8d 7c 24 08 48 89 fa 49 89 04 24 48 c1 ea 03 48 RIP: snd_seq_prioq_cell_out+0x11d/0x260 sound/core/seq/seq_prioq.c:231 RSP: 88005f7470b8 CR2: c9000392ddb8 ---[ end trace cbaec69c4a9fdbfc ]--- On commit fd694aaa46c7ed811b72eb47d5eb11ce7ab3f7f1 (Jan 26).