Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Thu, 26 Jun 2014 01:52:26 -0400 (EDT)
Subject: Re: CVE Request: Linux kernel ALSA core control API vulnerabilities

Hash: SHA1

> 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.

> (aka "The first issue is a race conditions in the user-control put/get
> and tlv handlers" ... "first affected release is v2.6.18")

Use CVE-2014-4652.

> 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.

> (aka "There are a couple of places where a kcontrol is de-referenced
> after controls_rwsem has been released" ... "first affected release
> predates the git history")

Use CVE-2014-4653.

> ALSA: control: Fix 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

> (aka "The next issue is that SNDRV_CTL_IOCTL_ELEM_REPLACE does no
> permission checking on the control that is to be replaced. This allows
> a application to remove controls that were created by the kernel
> driver and also controls that are locked by other applications." ...
> "first affected release predates the git history")

Use CVE-2014-4654.

> 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.

> (aka "SNDRV_CTL_IOCTL_ELEM_REPLACE also gets the user_ctl_count
> handling wrong" ... "first affected release predates the git history")

Use CVE-2014-4655.

[ in other words, two different CVE IDs for the
  82262a46627bebb0febcc26664746c25cef08563 commit ]

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

> if (id.index > UINT_MAX - kcontrol->count)
>     goto error;

> ALSA: control: Handle numid overflow

> if (card->last_numid >= UINT_MAX - count)
>    card->last_numid = 0;

> (aka "The last two issues are overflows of id.index and id.numid" ...
> "first affected release predates the git history")

Use CVE-2014-4656.

[ in other words, a single CVE ID for both the
  883a1d49f0d77d30012f114b2e19fc141beb3e8e and
  ac902c112d90a89e59916f751c2745f4dbdbb4bd commits ]

- -- 
CVE assignment team, MITRE CVE Numbering Authority
M/S M300
202 Burlington Road, Bedford, MA 01730 USA
[ PGP key available through ]
Version: GnuPG v1.4.14 (SunOS)


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.