[alsa-devel] [BUG] ALSA: seq: a possible sleep-in-atomic-context bug in snd_virmidi_dev_receive_event()
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
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 :)
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
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
participants (3)
-
Greg KH -
Jia-Ju Bai -
Takashi Iwai