kernel.git/sound/core/oss, branch linux-4.1.y

ALSA: pcm: Fix endless loop for XRUN recovery in OSS emulation

2018-05-23T01:36:34Z

[ Upstream commit e15dc99dbb9cf99f6432e8e3c0b3a8f7a3403a86 ] The commit 02a5d6925cd3 ("ALSA: pcm: Avoid potential races between OSS ioctls and read/write") split the PCM preparation code to a locked version, and it added a sanity check of runtime->oss.prepare flag along with the change. This leaded to an endless loop when the stream gets XRUN: namely, snd_pcm_oss_write3() and co call snd_pcm_oss_prepare() without setting runtime->oss.prepare flag and the loop continues until the PCM state reaches to another one. As the function is supposed to execute the preparation unconditionally, drop the invalid state check there. The bug was triggered by syzkaller. Fixes: 02a5d6925cd3 ("ALSA: pcm: Avoid potential races between OSS ioctls and read/write") Reported-by: syzbot+150189c103427d31a053@syzkaller.appspotmail.com Reported-by: syzbot+7e3f31a52646f939c052@syzkaller.appspotmail.com Reported-by: syzbot+4f2016cf5185da7759dc@syzkaller.appspotmail.com Cc: Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin

ALSA: pcm: Fix mutex unbalance in OSS emulation ioctls

2018-05-23T01:36:34Z

[ Upstream commit f6d297df4dd47ef949540e4a201230d0c5308325 ] The previous fix 40cab6e88cb0 ("ALSA: pcm: Return -EBUSY for OSS ioctls changing busy streams") introduced some mutex unbalance; the check of runtime->oss.rw_ref was inserted in a wrong place after the mutex lock. This patch fixes the inconsistency by rewriting with the helper functions to lock/unlock parameters with the stream check. Fixes: 40cab6e88cb0 ("ALSA: pcm: Return -EBUSY for OSS ioctls changing busy streams") Reported-by: Dan Carpenter Cc: Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin

ALSA: pcm: Return -EBUSY for OSS ioctls changing busy streams

2018-05-23T01:36:34Z

[ Upstream commit 40cab6e88cb0b6c56d3f30b7491a20e803f948f6 ] OSS PCM stream management isn't modal but it allows ioctls issued at any time for changing the parameters. In the previous hardening patch ("ALSA: pcm: Avoid potential races between OSS ioctls and read/write"), we covered these races and prevent the corruption by protecting the concurrent accesses via params_lock mutex. However, this means that some ioctls that try to change the stream parameter (e.g. channels or format) would be blocked until the read/write finishes, and it may take really long. Basically changing the parameter while reading/writing is an invalid operation, hence it's even more user-friendly from the API POV if it returns -EBUSY in such a situation. This patch adds such checks in the relevant ioctls with the addition of read/write access refcount. Cc: Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin

ALSA: pcm: Avoid potential races between OSS ioctls and read/write

2018-05-23T01:36:34Z

[ Upstream commit 02a5d6925cd34c3b774bdb8eefb057c40a30e870 ] Although we apply the params_lock mutex to the whole read and write operations as well as snd_pcm_oss_change_params(), we may still face some races. First off, the params_lock is taken inside the read and write loop. This is intentional for avoiding the too long locking, but it allows the in-between parameter change, which might lead to invalid pointers. We check the readiness of the stream and set up via snd_pcm_oss_make_ready() at the beginning of read and write, but it's called only once, by assuming that it remains ready in the rest. Second, many ioctls that may change the actual parameters (i.e. setting runtime->oss.params=1) aren't protected, hence they can be processed in a half-baked state. This patch is an attempt to plug these holes. The stream readiness check is moved inside the read/write inner loop, so that the stream is always set up in a proper state before further processing. Also, each ioctl that may change the parameter is wrapped with the params_lock for avoiding the races. The issues were triggered by syzkaller in a few different scenarios, particularly the one below appearing as GPF in loopback_pos_update. Reported-by: syzbot+c4227aec125487ec3efa@syzkaller.appspotmail.com Cc: Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin

ALSA: pcm: Use ERESTARTSYS instead of EINTR in OSS emulation

2018-05-23T01:36:34Z

[ Upstream commit c64ed5dd9feba193c76eb460b451225ac2a0d87b ] Fix the last standing EINTR in the whole subsystem. Use more correct ERESTARTSYS for pending signals. Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin

ALSA: oss: consolidate kmalloc/memset 0 call to kzalloc

2018-05-23T01:36:34Z

[ Upstream commit 46325371b230cc66c743925c930a17e7d0b8211e ] This is an API consolidation only. The use of kmalloc + memset to 0 is equivalent to kzalloc. Signed-off-by: Nicholas Mc Guire Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin

ALSA: pcm: Fix UAF in snd_pcm_oss_get_formats()

2018-05-23T01:33:47Z

[ Upstream commit 01c0b4265cc16bc1f43f475c5944c55c10d5768f ] snd_pcm_oss_get_formats() has an obvious use-after-free around snd_mask_test() calls, as spotted by syzbot. The passed format_mask argument is a pointer to the hw_params object that is freed before the loop. What a surprise that it has been present since the original code of decades ago... Reported-by: syzbot+4090700a4f13fccaf648@syzkaller.appspotmail.com Cc: Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin

ALSA: pcm: Allow aborting mutex lock at OSS read/write loops

2018-03-01T00:32:22Z

[ Upstream commit 900498a34a3ac9c611e9b425094c8106bdd7dc1c ] PCM OSS read/write loops keep taking the mutex lock for the whole read/write, and this might take very long when the exceptionally high amount of data is given. Also, since it invokes with mutex_lock(), the concurrent read/write becomes unbreakable. This patch tries to address these issues by replacing mutex_lock() with mutex_lock_interruptible(), and also splits / re-takes the lock at each read/write period chunk, so that it can switch the context more finely if requested. Cc: Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin

ALSA: pcm: Abort properly at pending signal in OSS read/write loops

2018-03-01T00:32:22Z

[ Upstream commit 29159a4ed7044c52e3e2cf1a9fb55cec4745c60b ] The loops for read and write in PCM OSS emulation have no proper check of pending signals, and they keep processing even after user tries to break. This results in a very long delay, often seen as RCU stall when a huge unprocessed bytes remain queued. The bug could be easily triggered by syzkaller. As a simple workaround, this patch adds the proper check of pending signals and aborts the loop appropriately. Reported-by: syzbot+993cb4cfcbbff3947c21@syzkaller.appspotmail.com Cc: Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin

ALSA: pcm: Add missing error checks in OSS emulation plugin builder

2018-03-01T00:32:22Z

[ Upstream commit 6708913750344a900f2e73bfe4a4d6dbbce4fe8d ] In the OSS emulation plugin builder where the frame size is parsed in the plugin chain, some places miss the possible errors returned from the plugin src_ or dst_frames callback. This patch papers over such places. Cc: Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin