* [BUG] ALSA: seq: a possible sleep-in-atomic-context bug in snd_virmidi_dev_receive_event()
@ 2019-12-17 13:24 Jia-Ju Bai
2019-12-17 13:30 ` Greg KH
2019-12-17 13:37 ` Takashi Iwai
0 siblings, 2 replies; 4+ messages in thread
From: Jia-Ju Bai @ 2019-12-17 13:24 UTC (permalink / raw)
To: perex, tiwai, rfontana, gregkh, allison, tglx; +Cc: alsa-devel, LKML
The driver may sleep while holding a read lock.
The function call path (from bottom to top) in Linux 4.19 is:
sound/core/seq/seq_memory.c, 96:
copy_from_user in snd_seq_dump_var_event
sound/core/seq/seq_virmidi.c, 97:
snd_seq_dump_var_event in snd_virmidi_dev_receive_event
sound/core/seq/seq_virmidi.c, 88:
_raw_read_lock in snd_virmidi_dev_receive_event
copy_from_user() can sleep at runtime.
I am not sure how to properly fix this possible bug, so I only report it.
This bug is found by a static analysis tool STCheck written by myself.
Best wishes,
Jia-Ju Bai
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [BUG] ALSA: seq: a possible sleep-in-atomic-context bug in snd_virmidi_dev_receive_event()
2019-12-17 13:24 [BUG] ALSA: seq: a possible sleep-in-atomic-context bug in snd_virmidi_dev_receive_event() Jia-Ju Bai
@ 2019-12-17 13:30 ` Greg KH
2019-12-17 13:37 ` Takashi Iwai
1 sibling, 0 replies; 4+ messages in thread
From: Greg KH @ 2019-12-17 13:30 UTC (permalink / raw)
To: Jia-Ju Bai; +Cc: perex, tiwai, rfontana, allison, tglx, alsa-devel, LKML
On Tue, Dec 17, 2019 at 09:24:21PM +0800, Jia-Ju Bai wrote:
> The driver may sleep while holding a read lock.
> The function call path (from bottom to top) in Linux 4.19 is:
>
> sound/core/seq/seq_memory.c, 96:
> copy_from_user in snd_seq_dump_var_event
> sound/core/seq/seq_virmidi.c, 97:
> snd_seq_dump_var_event in snd_virmidi_dev_receive_event
> sound/core/seq/seq_virmidi.c, 88:
> _raw_read_lock in snd_virmidi_dev_receive_event
>
> copy_from_user() can sleep at runtime.
>
> I am not sure how to properly fix this possible bug, so I only report it.
>
> This bug is found by a static analysis tool STCheck written by myself.
Patches for this is usually best :)
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [BUG] ALSA: seq: a possible sleep-in-atomic-context bug in snd_virmidi_dev_receive_event()
2019-12-17 13:24 [BUG] ALSA: seq: a possible sleep-in-atomic-context bug in snd_virmidi_dev_receive_event() Jia-Ju Bai
2019-12-17 13:30 ` Greg KH
@ 2019-12-17 13:37 ` Takashi Iwai
2019-12-17 13:39 ` Jia-Ju Bai
1 sibling, 1 reply; 4+ messages in thread
From: Takashi Iwai @ 2019-12-17 13:37 UTC (permalink / raw)
To: Jia-Ju Bai
Cc: perex, tiwai, rfontana, gregkh, allison, tglx, alsa-devel, LKML
On Tue, 17 Dec 2019 14:24:21 +0100,
Jia-Ju Bai wrote:
>
> The driver may sleep while holding a read lock.
> The function call path (from bottom to top) in Linux 4.19 is:
>
> sound/core/seq/seq_memory.c, 96:
> copy_from_user in snd_seq_dump_var_event
> sound/core/seq/seq_virmidi.c, 97:
> snd_seq_dump_var_event in snd_virmidi_dev_receive_event
> sound/core/seq/seq_virmidi.c, 88:
> _raw_read_lock in snd_virmidi_dev_receive_event
This can't happen. snd_virmidi_dev_receive_event() takes
conditionally either read_lock or rw_sem depending on the atomic
argument. And the data including user-space pointer is handled always
with atomic=1, hence down_read() is used instead of read_lock() here.
thanks,
Takashi
> copy_from_user() can sleep at runtime.
>
> I am not sure how to properly fix this possible bug, so I only report it.
>
> This bug is found by a static analysis tool STCheck written by myself.
>
>
> Best wishes,
> Jia-Ju Bai
>
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [BUG] ALSA: seq: a possible sleep-in-atomic-context bug in snd_virmidi_dev_receive_event()
2019-12-17 13:37 ` Takashi Iwai
@ 2019-12-17 13:39 ` Jia-Ju Bai
0 siblings, 0 replies; 4+ messages in thread
From: Jia-Ju Bai @ 2019-12-17 13:39 UTC (permalink / raw)
To: Takashi Iwai
Cc: perex, tiwai, rfontana, gregkh, allison, tglx, alsa-devel, LKML
On 2019/12/17 21:37, Takashi Iwai wrote:
> On Tue, 17 Dec 2019 14:24:21 +0100,
> Jia-Ju Bai wrote:
>> The driver may sleep while holding a read lock.
>> The function call path (from bottom to top) in Linux 4.19 is:
>>
>> sound/core/seq/seq_memory.c, 96:
>> copy_from_user in snd_seq_dump_var_event
>> sound/core/seq/seq_virmidi.c, 97:
>> snd_seq_dump_var_event in snd_virmidi_dev_receive_event
>> sound/core/seq/seq_virmidi.c, 88:
>> _raw_read_lock in snd_virmidi_dev_receive_event
> This can't happen. snd_virmidi_dev_receive_event() takes
> conditionally either read_lock or rw_sem depending on the atomic
> argument. And the data including user-space pointer is handled always
> with atomic=1, hence down_read() is used instead of read_lock() here.
>
Okay, thanks for the explanation.
Best wishes,
Jia-Ju Bai
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2019-12-17 13:39 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-12-17 13:24 [BUG] ALSA: seq: a possible sleep-in-atomic-context bug in snd_virmidi_dev_receive_event() Jia-Ju Bai
2019-12-17 13:30 ` Greg KH
2019-12-17 13:37 ` Takashi Iwai
2019-12-17 13:39 ` Jia-Ju Bai
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®