kernel.git/sound/core/control.c, branch linux-4.15.y

ALSA: control: Fix memory corruption risk in snd_ctl_elem_read

2018-03-09T06:47:28Z

commit 5a23699a39abc5328921a81b89383d088f6ba9cc upstream. The patch "ALSA: control: code refactoring for ELEM_READ/ELEM_WRITE operations" introduced a potential for kernel memory corruption due to an incorrect if statement allowing non-readable controls to fall through and call the get function. For TLV controls a driver can omit SNDRV_CTL_ELEM_ACCESS_READ to ensure that only the TLV get function can be called. Instead the normal get() can be invoked unexpectedly and as the driver expects that this will only be called for controls <= 512 bytes, potentially try to copy >512 bytes into the 512 byte return array, so corrupting kernel memory. The problem is an attempt to refactor the snd_ctl_elem_read function to invert the logic so that it conditionally aborted if the control is unreadable instead of conditionally executing. But the if statement wasn't inverted correctly. The correct inversion of if (a && !b) is if (!a || b) Fixes: becf9e5d553c2 ("ALSA: control: code refactoring for ELEM_READ/ELEM_WRITE operations") Signed-off-by: Richard Fitzgerald Cc: Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman

ALSA: Get rid of card power_lock

2017-08-30T18:44:29Z

Currently we're taking power_lock at each card component for assuring the power-up sequence, but it doesn't help anything in the implementation at the moment: it just serializes unnecessarily the callers, but it doesn't protect about the power state change itself. It used to have some usefulness in the early days where we managed the PM manually. But now the suspend/resume core procedure is beyond our hands, and power_lock lost its meaning. This patch drops the power_lock from allover the places. There shouldn't be any issues by this change, as it's no helper regarding the power state change. Rather we'll get better performance by removing the serialization; which is the only slight concern of any behavior change, but it can't be a showstopper, after all. Signed-off-by: Takashi Iwai

ALSA: control: TLV data is unavailable at initial state of user-defined element set

2017-08-24T07:15:15Z

For user-defined element set, in its initial state, TLV data is not registered. It's firstly available when any application register it by an additional operation. However, in current implementation, it's available in its initial state. As a result, applications get -ENXIO to read it. This commit controls its readability to manage info flags properly. In an initial state, elements don't have SND_CTL_ELEM_ACCESS_TLV_READ flag. Once TLV write operation is executed, they get the flag. Signed-off-by: Takashi Sakamoto Signed-off-by: Takashi Iwai

ALSA: control: queue TLV event for a set of user-defined element

2017-08-24T07:15:14Z

In a design of user-defined element set, applications allow to change TLV data on the set. This operation doesn't only affects to a target element, but also to elements in the set. This commit generates TLV event for all of elements in the set when the TLV data is changed. Signed-off-by: Takashi Sakamoto Signed-off-by: Takashi Iwai

ALSA: control: delegate TLV eventing to each driver

2017-08-24T07:15:13Z

In a design of ALSA control core, a set of elements is represented by 'struct snd_kcontrol' to share common attributes. The set of elements shares TLV (Type-Length-Value) data, too. On the other hand, in ALSA control interface/protocol for applications, a TLV operation is committed to an element. Totally, the operation can have sub-effect to the other elements in the set. For example, TLV_WRITE operation is expected to change TLV data, which returns to applications. Applications attempt to change the TLV data per element, but in the above design, they can effect to elements in the same set. As a default, ALSA control core has no implementation except for TLV_READ operation. Thus, the above design looks to have no issue. However, in kernel APIs of ALSA control component, developers can program a handler for any request of the TLV operation. Therefore, for elements in a set which has the handler, applications can commit TLV_WRITE and TLV_COMMAND requests. For the above scenario, ALSA control core assist notification. When the handler returns positive value, the core queueing an event for a requested element. However, this includes design defects that the event is not queued for the other element in a set. Actually, developers can program the handlers to keep per-element TLV data, but it depends on each driver. As of v4.13-rc6, there's no driver in tree to utilize the notification, except for user-defined element set. This commit delegates the notification into each driver to prevent developers from the design defects. Signed-off-by: Takashi Sakamoto Signed-off-by: Takashi Iwai

Merge branch 'for-linus' into for-next

2017-08-22T13:44:45Z

Conflicts: sound/core/control.c

ALSA: core: Fix unexpected error at replacing user TLV

2017-08-22T13:43:40Z

When user tries to replace the user-defined control TLV, the kernel checks the change of its content via memcmp(). The problem is that the kernel passes the return value from memcmp() as is. memcmp() gives a non-zero negative value depending on the comparison result, and this shall be recognized as an error code. The patch covers that corner-case, return 1 properly for the changed TLV. Fixes: 8aa9b586e420 ("[ALSA] Control API - more robust TLV implementation") Cc: Signed-off-by: Takashi Iwai

ALSA: control: use counting semaphore as write lock for ELEM_WRITE operation

2017-08-20T07:39:55Z

In ALSA control interface, applications can execute two types of request for value of members on each element; ELEM_READ and ELEM_WRITE. In ALSA control core, these two requests are handled within read lock of a counting semaphore, therefore several processes can run to execute these two requests at the same time. This has an issue because ELEM_WRITE requests have an effect to change state of the target element. Concurrent access should be controlled for each of ELEM_READ/ELEM_WRITE case. This commit uses the counting semaphore as write lock for ELEM_WRITE requests, while use it as read lock for ELEM_READ requests. The state of a target element is maintained exclusively between ELEM_WRITE/ELEM_READ operations. There's a concern. If the counting semaphore is acquired for read lock in implementations of 'struct snd_kcontrol.put()' in each driver, this commit shall cause dead lock. As of v4.13-rc5, 'snd-mixer-oss.ko', 'snd-emu10k1.ko' and 'snd-soc-sst-atom-hifi2-platform.ko' includes codes for read locks, but these are not in a call graph from 'struct snd_kcontrol.put(). Therefore, this commit is safe. In current implementation, the same solution is applied for the other operations to element; e.g. ELEM_LOCK and ELEM_UNLOCK. There's another discussion about an overhead to maintain concurrent access to an element during operating the other elements on the same card instance, because the lock primitive is originally implemented to maintain a list of elements on the card instance. There's a substantial difference between per-element-list lock and per-element lock. Here, let me investigate another idea to add per-element lock to maintain the concurrent accesses with inquiry/change requests to an element. It's not so frequent for applications to operate members on elements, while adding a new lock primitive to structure increases memory footprint for all of element sets somehow. Experimentally, inquiry operation is more frequent than change operation and usage of counting semaphore for the inquiry operation brings no blocking to the other inquiry operations. Thus the overhead is not so critical for usual applications. For the above reasons, in this commit, the per-element lock is not introduced. Signed-off-by: Takashi Sakamoto Signed-off-by: Takashi Iwai

ALSA: control: code refactoring for ELEM_READ/ELEM_WRITE operations

2017-08-20T07:39:54Z

ALSA control core handles ELEM_READ/ELEM_WRITE requests within lock acquisition of a counting semaphore. The lock is acquired in helper functions in the end of call path before calling implementations of each driver. ioctl(2) with SNDRV_CTL_ELEM_READ ... ->snd_ctl_ioctl() ->snd_ctl_elem_read_user() ->snd_ctl_elem_read() ->down_read(controls_rwsem) ->snd_ctl_find_id() ->struct snd_kcontrol.get() ->up_read(controls_rwsem) ioctl(2) with SNDRV_CTL_ELEM_WRITE ... ->snd_ctl_ioctl() ->snd_ctl_elem_write_user() ->snd_ctl_elem_write() ->down_read(controls_rwsem) ->snd_ctl_find_id() ->struct snd_kcontrol.put() ->up_read(controls_rwsem) This commit moves the lock acquisition to middle of the call graph to simplify the helper functions. As a result: ioctl(2) with SNDRV_CTL_ELEM_READ ... ->snd_ctl_ioctl() ->snd_ctl_elem_read_user() ->down_read(controls_rwsem) ->snd_ctl_elem_read() ->snd_ctl_find_id() ->struct snd_kcontrol.get() ->up_read(controls_rwsem) ioctl(2) with SNDRV_CTL_ELEM_WRITE ... ->snd_ctl_ioctl() ->snd_ctl_elem_write_user() ->down_read(controls_rwsem) ->snd_ctl_elem_write() ->snd_ctl_find_id() ->struct snd_kcontrol.put() ->up_read(controls_rwsem) Signed-off-by: Takashi Sakamoto Signed-off-by: Takashi Iwai

ALSA: control: queue events within locking of controls_rwsem for ELEM_WRITE operation

2017-08-20T07:39:53Z

Any control event is queued by a call of snd_ctl_notify(). This function adds the event to each queue of opened file data corresponding to ALSA control character devices. This function acquired two types of lock; a counting semaphore for a list of the opened file data and a spinlock for card data opened by the file. Typically, this function is called after acquiring a counting semaphore for a list of elements in the card data. In current implementation of a handler for ELEM_WRITE request, the function is called after releasing the semaphore for a list of elements in the card data. This release is not necessarily needed. This commit removes the release to call the function within the critical section so that later commits are simple. Signed-off-by: Takashi Sakamoto Signed-off-by: Takashi Iwai