kernel.git/include/sound/pcm.h, branch linux-4.19.y

ALSA: pcm: Fix potential AB/BA lock with buffer_mutex and mmap_lock

2022-05-15T17:41:58Z

commit bc55cfd5718c7c23e5524582e9fa70b4d10f2433 upstream. syzbot caught a potential deadlock between the PCM runtime->buffer_mutex and the mm->mmap_lock. It was brought by the recent fix to cover the racy read/write and other ioctls, and in that commit, I overlooked a (hopefully only) corner case that may take the revert lock, namely, the OSS mmap. The OSS mmap operation exceptionally allows to re-configure the parameters inside the OSS mmap syscall, where mm->mmap_mutex is already held. Meanwhile, the copy_from/to_user calls at read/write operations also take the mm->mmap_lock internally, hence it may lead to a AB/BA deadlock. A similar problem was already seen in the past and we fixed it with a refcount (in commit b248371628aa). The former fix covered only the call paths with OSS read/write and OSS ioctls, while we need to cover the concurrent access via both ALSA and OSS APIs now. This patch addresses the problem above by replacing the buffer_mutex lock in the read/write operations with a refcount similar as we've used for OSS. The new field, runtime->buffer_accessing, keeps the number of concurrent read/write operations. Unlike the former buffer_mutex protection, this protects only around the copy_from/to_user() calls; the other codes are basically protected by the PCM stream lock. The refcount can be a negative, meaning blocked by the ioctls. If a negative value is seen, the read/write aborts with -EBUSY. In the ioctl side, OTOH, they check this refcount, too, and set to a negative value for blocking unless it's already being accessed. Reported-by: syzbot+6e5c88838328e99c7e1c@syzkaller.appspotmail.com Fixes: dca947d4d26d ("ALSA: pcm: Fix races among concurrent read/write and buffer changes") Cc: Link: https://lore.kernel.org/r/000000000000381a0d05db622a81@google.com Link: https://lore.kernel.org/r/20220330120903.4738-1-tiwai@suse.de Signed-off-by: Takashi Iwai [OP: backport to 4.19: adjusted context] Signed-off-by: Ovidiu Panait Signed-off-by: Greg Kroah-Hartman

ALSA: pcm: Fix races among concurrent hw_params and hw_free calls

2022-05-15T17:41:58Z

commit 92ee3c60ec9fe64404dc035e7c41277d74aa26cb upstream. Currently we have neither proper check nor protection against the concurrent calls of PCM hw_params and hw_free ioctls, which may result in a UAF. Since the existing PCM stream lock can't be used for protecting the whole ioctl operations, we need a new mutex to protect those racy calls. This patch introduced a new mutex, runtime->buffer_mutex, and applies it to both hw_params and hw_free ioctl code paths. Along with it, the both functions are slightly modified (the mmap_count check is moved into the state-check block) for code simplicity. Reported-by: Hu Jiahui Cc: Reviewed-by: Jaroslav Kysela Link: https://lore.kernel.org/r/20220322170720.3529-2-tiwai@suse.de Signed-off-by: Takashi Iwai [OP: backport to 4.19: adjusted context] Signed-off-by: Ovidiu Panait Signed-off-by: Greg Kroah-Hartman

ALSA: pcm: Add __force to cast in snd_pcm_lib_read/write()

2018-07-26T06:32:13Z

The snd_pcm_lib_read() and snd_pcm_lib_write() inline functions have the explicit cast from a user pointer to a kernel pointer, but they lacks of __force prefix. This fixes sparse warnings like: ./include/sound/pcm.h:1093:47: warning: cast removes address space of expression Fixes: 68541213720d ("ALSA: pcm: Direct in-kernel read/write support") Signed-off-by: Takashi Iwai

ALSA: pcm: Nuke snd_pcm_lib_mmap_vmalloc()

2018-07-18T06:24:29Z

snd_pcm_lib_mmap_vmalloc() was supposed to be implemented with somewhat special for vmalloc handling, but in the end, this turned to just the default handler, i.e. NULL. As the situation has never changed over decades, let's rip it off. Reviewed-by: Takashi Sakamoto Signed-off-by: Takashi Iwai

ALSA: pcm: Allow drivers to set R/W wait time.

2018-07-06T13:00:25Z

Currently ALSA core blocks userspace for about 10 seconds for PCM R/W IO. This needs to be configurable for modern hardware like DSPs where no pointer update in milliseconds can indicate terminal DSP errors. Add a substream variable to set the wait time in ms. This allows userspace and drivers to recover more quickly from terminal DSP errors. Signed-off-by: Liam Girdwood Signed-off-by: Takashi Iwai

ALSA: pcm: add SNDRV_PCM_FORMAT_{S,U}20

2017-11-29T08:26:33Z

This format is similar to existing SNDRV_PCM_FORMAT_{S,U}20_3 that keep 20-bit PCM samples in 3 bytes, however i.MX6 platform SSI FIFO does not allow 3-byte accesses (including DMA) so a 4-byte (more conventional) format is needed for it. Signed-off-by: Maciej S. Szmigiero Reviewed-by: Takashi Sakamoto Signed-off-by: Takashi Iwai

ALSA: pcm: Add an ioctl to specify the supported protocol version

2017-06-27T11:55:46Z

We have an ioctl to inform the PCM protocol version the running kernel supports, but there is no way to know which protocol version the user-space can understand. This lack of information caused headaches in the past when we tried to extend the ABI. For example, because we couldn't guarantee the validity of the reserved bytes, we had to introduce a new ioctl SNDRV_PCM_IOCTL_STATUS_EXT for assigning a few new fields in the formerly reserved bits. If we could know that it's a new alsa-lib, we could assume the availability of the new fields, thus we could have reused the existing SNDRV_PCM_IOCTL_STATUS. In order to improve the ABI extensibility, this patch adds a new ioctl for user-space to inform its supporting protocol version to the kernel. By reporting the supported protocol from user-space, the kernel can judge which feature should be provided and which not. With the addition of the new ioctl, the PCM protocol version is bumped to 2.0.14, too. User-space checks the kernel protocol version via SNDRV_PCM_INFO_PVERSION, then it sets the supported version back via SNDRV_PCM_INFO_USER_PVERSION. Reviewed-by: Takashi Sakamoto Signed-off-by: Takashi Iwai

ALSA: pcm: remove SNDRV_PCM_IOCTL1_GSTATE internal command

2017-06-14T11:04:12Z

SNDRV_PCM_IOCTL1_GSTATE was firstly introduced in v0.9.0, however never be used and the purpose is missing. This commit removes the long-abandoned command, bye. Signed-off-by: Takashi Sakamoto Signed-off-by: Takashi Iwai

ALSA: pcm: remove SNDRV_PCM_IOCTL1_INFO internal command

2017-06-14T11:04:03Z

Drivers can implement 'struct snd_pcm_ops.ioctl' to handle some requests from ALSA PCM core. These requests are internal purpose in kernel land. Usually common set of operations are used for it. SNDRV_PCM_IOCTL1_INFO is one of the requests. According to code comment, it has been obsoleted in the old days. We can see old releases in ftp.alsa-project.org. The command was firstly introduced in v0.5.0 release as SND_PCM_IOCTL1_INFO, to allow drivers to fill data of 'struct snd_pcm_channel_info' type. In v0.9.0 release, this was obsoleted by the other commands for ioctl(2) such as SNDRV_PCM_IOCTL_CHANNEL_INFO. This commit removes the long-abandoned command, bye. Signed-off-by: Takashi Sakamoto Signed-off-by: Takashi Iwai

ALSA: pcm: Direct in-kernel read/write support

2017-06-02T17:38:24Z

Now all materials are ready, let's allow the direct in-kernel read/write, i.e. a kernel-space buffer is passed for read or write, instead of the normal user-space buffer. This feature is used by OSS layer and UAC1 driver, for example. The __snd_pcm_lib_xfer() takes in_kernel argument that indicates the in-kernel buffer copy. When this flag is set, another transfer code is used. It's either via copy_kernel PCM ops or the normal memcpy(), depending on the driver setup. As external API, snd_pcm_kernel_read(), *_write() and other variants are provided. That's all. This support is really simple because of the code refactoring until now. Reviewed-by: Takashi Sakamoto Signed-off-by: Takashi Iwai