]> git.ipfire.org Git - thirdparty/kernel/stable.git/commit
ALSA: control: Hardening for potential Spectre v1
authorTakashi Iwai <tiwai@suse.de>
Tue, 24 Apr 2018 05:45:56 +0000 (07:45 +0200)
committerSasha Levin <alexander.levin@microsoft.com>
Wed, 23 May 2018 01:36:38 +0000 (21:36 -0400)
commitf3f63233615f29d80b0956003222ec962b0a7875
tree1a20a691213aab0035aa8a8ff9445c3174dc0736
parentcb16ce2d14abb5278c7058488b47c63f92fa59c2
ALSA: control: Hardening for potential Spectre v1

[ Upstream commit 088e861edffb84879cf0c0d1b02eda078c3a0ffe ]

As recently Smatch suggested, a few places in ALSA control core codes
may expand the array directly from the user-space value with
speculation:

  sound/core/control.c:1003 snd_ctl_elem_lock() warn: potential spectre issue 'kctl->vd'
  sound/core/control.c:1031 snd_ctl_elem_unlock() warn: potential spectre issue 'kctl->vd'
  sound/core/control.c:844 snd_ctl_elem_info() warn: potential spectre issue 'kctl->vd'
  sound/core/control.c:891 snd_ctl_elem_read() warn: potential spectre issue 'kctl->vd'
  sound/core/control.c:939 snd_ctl_elem_write() warn: potential spectre issue 'kctl->vd'

Although all these seem doing only the first load without further
reference, we may want to stay in a safer side, so hardening with
array_index_nospec() would still make sense.

In this patch, we put array_index_nospec() to the common
snd_ctl_get_ioff*() helpers instead of each caller.  These helpers are
also referred from some drivers, too, and basically all usages are to
calculate the array index from the user-space value, hence it's better
to cover there.

BugLink: https://marc.info/?l=linux-kernel&m=152411496503418&w=2
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
include/sound/control.h