Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Tue, 24 Jun 2014 13:51:54 +0200
From: Marcus Meissner <>
To: OSS Security List <>
Subject: CVE Request: Linux kernel ALSA core control API vulnerabilities 

Hi folks,

Several ALSA fixes have been committed to the Linux kernel git that fix several
use-after-free and out-of-bounds memory access vulnerabilities in the Linux kernel.

These will need CVEs.

Author: Lars-Peter Clausen <>
Date:   Wed Jun 18 13:32:31 2014 +0200

    ALSA: control: Protect user controls against concurrent access
    The user-control put and get handlers as well as the tlv do not protect against
    concurrent access from multiple threads. Since the state of the control is not
    updated atomically it is possible that either two write operations or a write
    and a read operation race against each other. Both can lead to arbitrary memory
    disclosure. This patch introduces a new lock that protects user-controls from
    concurrent access. Since applications typically access controls sequentially
    than in parallel a single lock per card should be fine.
(memory information disclosure or even overwrite)
commit 82262a46627bebb0febcc26664746c25cef08563
Author: Lars-Peter Clausen <>
Date:   Wed Jun 18 13:32:32 2014 +0200

    ALSA: control: Fix replacing user controls
    There are two issues with the current implementation for replacing user
    controls. The first is that the code does not check if the control is actually a
    user control and neither does it check if the control is owned by the process
    that tries to remove it. That allows userspace applications to remove arbitrary
    controls, which can cause a user after free if a for example a driver does not
    expect a control to be removed from under its feed.
    The second issue is that on one hand when a control is replaced the
    user_ctl_count limit is not checked and on the other hand the user_ctl_count is
    increased (even though the number of user controls does not change). This allows
    userspace, once the user_ctl_count limit as been reached, to repeatedly replace
    a control until user_ctl_count overflows. Once that happens new controls can be
    added effectively bypassing the user_ctl_count limit.
    Both issues can be fixed by instead of open-coding the removal of the control
    that is to be replaced to use snd_ctl_remove_user_ctl(). This function does
    proper permission checks as well as decrements user_ctl_count after the control
    has been removed.
    Note that by using snd_ctl_remove_user_ctl() the check which returns -EBUSY at
    beginning of the function if the control already exists is removed. This is not
    a problem though since the check is quite useless, because the lock that is
    protecting the control list is released between the check and before adding the
    new control to the list, which means that it is possible that a different
    control with the same settings is added to the list after the check. Luckily
    there is another check that is done while holding the lock in snd_ctl_add(), so
    we'll rely on that to make sure that the same control is not added twice.

(user after free)
commit fd9f26e4eca5d08a27d12c0933fceef76ed9663d
Author: Lars-Peter Clausen <>
Date:   Wed Jun 18 13:32:33 2014 +0200

    ALSA: control: Don't access controls outside of protected regions
    A control that is visible on the card->controls list can be freed at any time.
    This means we must not access any of its memory while not holding the
    controls_rw_lock. Otherwise we risk a use after free access.

(use after free)
Author: Lars-Peter Clausen <>
Date:   Wed Jun 18 13:32:34 2014 +0200

    ALSA: control: Handle numid overflow
    Each control gets automatically assigned its numids when the control is created.
    The allocation is done by incrementing the numid by the amount of allocated
    numids per allocation. This means that excessive creation and destruction of
    controls (e.g. via SNDRV_CTL_IOCTL_ELEM_ADD/REMOVE) can cause the id to
    eventually overflow. Currently when this happens for the control that caused the
    overflow kctl->id.numid + kctl->count will also over flow causing it to be
    smaller than kctl->id.numid. Most of the code assumes that this is something
    that can not happen, so we need to make sure that it won't happen

(unknown breakage?)
commit 883a1d49f0d77d30012f114b2e19fc141beb3e8e
Author: Lars-Peter Clausen <>
Date:   Wed Jun 18 13:32:35 2014 +0200

    ALSA: control: Make sure that id->index does not overflow

    The ALSA control code expects that the range of assigned indices to a control is
    continuous and does not overflow. Currently there are no checks to enforce this.
    If a control with a overflowing index range is created that control becomes
    effectively inaccessible and unremovable since snd_ctl_find_id() will not be
    able to find it. This patch adds a check that makes sure that controls with a
    overflowing index range can not be created.

(denial of service/memory leak?)

Ciao, Marcus

Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.