From: Willy Tarreau <w@1wt.eu>
To: linux-kernel@vger.kernel.org, stable@vger.kernel.org
Cc: Lars-Peter Clausen <lars@metafoo.de>,
Jaroslav Kysela <perex@perex.cz>, Takashi Iwai <tiwai@suse.de>,
Willy Tarreau <w@1wt.eu>
Subject: [ 18/25] ALSA: control: Fix replacing user controls
Date: Sat, 06 Dec 2014 18:42:06 +0100 [thread overview]
Message-ID: <20141206174149.192584646@1wt.eu> (raw)
In-Reply-To: <2a26e912d2438674771c36169c190830@local>
2.6.32-longterm review patch. If anyone has any objections, please let me know.
------------------
From: Lars-Peter Clausen <lars@metafoo.de>
(commit 82262a46627bebb0febcc26664746c25cef08563 upstream)
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.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Acked-by: Jaroslav Kysela <perex@perex.cz>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
[wt: fixes CVE-2014-4654 & CVE-2014-4655]
Signed-off-by: Willy Tarreau <w@1wt.eu>
---
sound/core/control.c | 23 +++++++++--------------
1 file changed, 9 insertions(+), 14 deletions(-)
diff --git a/sound/core/control.c b/sound/core/control.c
index e91d79a..ffa7857 100644
--- a/sound/core/control.c
+++ b/sound/core/control.c
@@ -999,21 +999,16 @@ static int snd_ctl_elem_add(struct snd_ctl_file *file,
SNDRV_CTL_ELEM_ACCESS_TLV_READWRITE));
info->id.numid = 0;
memset(&kctl, 0, sizeof(kctl));
- down_write(&card->controls_rwsem);
- _kctl = snd_ctl_find_id(card, &info->id);
- err = 0;
- if (_kctl) {
- if (replace)
- err = snd_ctl_remove(card, _kctl);
- else
- err = -EBUSY;
- } else {
- if (replace)
- err = -ENOENT;
+
+ if (replace) {
+ err = snd_ctl_remove_user_ctl(file, &info->id);
+ if (err)
+ return err;
}
- up_write(&card->controls_rwsem);
- if (err < 0)
- return err;
+
+ if (card->user_ctl_count >= MAX_USER_CONTROLS)
+ return -ENOMEM;
+
memcpy(&kctl.id, &info->id, sizeof(info->id));
kctl.count = info->owner ? info->owner : 1;
access |= SNDRV_CTL_ELEM_ACCESS_USER;
--
1.7.12.2.21.g234cd45.dirty
next prev parent reply other threads:[~2014-12-06 17:42 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <2a26e912d2438674771c36169c190830@local>
2014-12-06 17:41 ` [ 00/25] 2.6.32.65-longterm review Willy Tarreau
2014-12-08 0:58 ` Willy Tarreau
2014-12-06 17:41 ` [ 01/25] net: sendmsg: fix failed backport of "fix NULL pointer dereference" Willy Tarreau
2014-12-06 17:41 ` [ 02/25] x86, 64-bit: Move K8 B step iret fixup to fault entry asm Willy Tarreau
2014-12-06 17:41 ` [ 03/25] x86-64: Adjust frame type at paranoid_exit: Willy Tarreau
2014-12-06 17:41 ` [ 04/25] x86-64, modify_ldt: Ban 16-bit segments on 64-bit kernels Willy Tarreau
2014-12-06 17:41 ` [ 05/25] x86-32, espfix: Remove filter for espfix32 due to race Willy Tarreau
2014-12-06 17:41 ` [ 06/25] x86-64, espfix: Dont leak bits 31:16 of %esp returning to 16-bit stack Willy Tarreau
2014-12-06 17:41 ` [ 07/25] x86, espfix: Move espfix definitions into a separate header file Willy Tarreau
2014-12-06 17:41 ` [ 08/25] x86, espfix: Fix broken header guard Willy Tarreau
2014-12-06 17:41 ` [ 09/25] x86, espfix: Make espfix64 a Kconfig option, fix UML Willy Tarreau
2014-12-06 17:41 ` [ 10/25] x86, espfix: Make it possible to disable 16-bit support Willy Tarreau
2014-12-08 2:58 ` Ben Hutchings
2014-12-08 7:11 ` Willy Tarreau
2014-12-06 17:41 ` [ 11/25] x86_64/entry/xen: Do not invoke espfix64 on Xen Willy Tarreau
2014-12-06 17:42 ` [ 12/25] x86/espfix/xen: Fix allocation of pages for paravirt page tables Willy Tarreau
2014-12-06 17:42 ` [ 13/25] x86_64, traps: Stop using IST for #SS Willy Tarreau
2014-12-06 17:42 ` [ 14/25] x86_64, traps: Fix the espfix64 #DF fixup and rewrite it in C Willy Tarreau
2014-12-06 17:42 ` [ 15/25] x86_64, traps: Rework bad_iret Willy Tarreau
2014-12-06 17:42 ` [ 16/25] net/l2tp: dont fall back on UDP [get|set]sockopt Willy Tarreau
2014-12-06 17:42 ` [ 17/25] ALSA: control: Dont access controls outside of protected regions Willy Tarreau
2014-12-06 17:42 ` Willy Tarreau [this message]
2014-12-06 17:42 ` [ 19/25] USB: whiteheat: Added bounds checking for bulk command response Willy Tarreau
2014-12-06 17:42 ` [ 20/25] net: sctp: fix panic on duplicate ASCONF chunks Willy Tarreau
2014-12-06 17:42 ` [ 21/25] net: sctp: fix remote memory pressure from excessive queueing Willy Tarreau
2014-12-06 17:42 ` [ 22/25] udf: Avoid infinite loop when processing indirect ICBs Willy Tarreau
2014-12-06 17:42 ` [ 23/25] net: sctp: fix NULL pointer dereference in af->from_addr_param on malformed packet Willy Tarreau
2014-12-06 17:42 ` [ 24/25] mac80211: fix fragmentation code, particularly for encryption Willy Tarreau
2014-12-06 17:42 ` [ 25/25] ttusb-dec: buffer overflow in ioctl Willy Tarreau
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20141206174149.192584646@1wt.eu \
--to=w@1wt.eu \
--cc=lars@metafoo.de \
--cc=linux-kernel@vger.kernel.org \
--cc=perex@perex.cz \
--cc=stable@vger.kernel.org \
--cc=tiwai@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).