ALSA: isa/wavefront: Fix potential Spectre v1 vulnerabilities
diff mbox series

Message ID 20181219233143.GA14518@embeddedor
State New
Headers show
Series
  • ALSA: isa/wavefront: Fix potential Spectre v1 vulnerabilities
Related show

Commit Message

Gustavo A. R. Silva Dec. 19, 2018, 11:31 p.m. UTC
header->number is indirectly controlled by user-space, hence leading
to a potential exploitation of the Spectre variant 1 vulnerability.

This issue was detected with the help of Smatch:

sound/isa/wavefront/wavefront_synth.c:792 wavefront_send_patch() warn: potential spectre issue 'dev->patch_status' [w] (local cap)
sound/isa/wavefront/wavefront_synth.c:819 wavefront_send_program() warn: potential spectre issue 'dev->prog_status' [w] (local cap)
sound/isa/wavefront/wavefront_synth.c:1197 wavefront_send_alias() warn: potential spectre issue 'dev->sample_status' [w]
sound/isa/wavefront/wavefront_synth.c:1248 wavefront_send_multisample() warn: potential spectre issue 'dev->sample_status' [w]
sound/isa/wavefront/wavefront_synth.c:1548 wavefront_synth_control() warn: potential spectre issue 'dev->sample_status' [r] (local cap)

Fix this by sanitizing header->number before using it to index
dev->patch_status, dev->prog_status and dev->sample_status.

Notice that given that speculation windows are large, the policy is
to kill the speculation on the first load and not worry if it can be
completed with a dependent load/store [1].

[1] https://marc.info/?l=linux-kernel&m=152449131114778&w=2

Cc: stable@vger.kernel.org
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
---
 sound/isa/wavefront/wavefront_synth.c | 18 +++++++++++++++---
 1 file changed, 15 insertions(+), 3 deletions(-)

Comments

Takashi Iwai Dec. 20, 2018, 8:11 a.m. UTC | #1
On Thu, 20 Dec 2018 00:31:43 +0100,
 Gustavo A. R. Silva  wrote:
> 
> header->number is indirectly controlled by user-space, hence leading
> to a potential exploitation of the Spectre variant 1 vulnerability.
> 
> This issue was detected with the help of Smatch:
> 
> sound/isa/wavefront/wavefront_synth.c:792 wavefront_send_patch() warn: potential spectre issue 'dev->patch_status' [w] (local cap)
> sound/isa/wavefront/wavefront_synth.c:819 wavefront_send_program() warn: potential spectre issue 'dev->prog_status' [w] (local cap)
> sound/isa/wavefront/wavefront_synth.c:1197 wavefront_send_alias() warn: potential spectre issue 'dev->sample_status' [w]
> sound/isa/wavefront/wavefront_synth.c:1248 wavefront_send_multisample() warn: potential spectre issue 'dev->sample_status' [w]
> sound/isa/wavefront/wavefront_synth.c:1548 wavefront_synth_control() warn: potential spectre issue 'dev->sample_status' [r] (local cap)
> 
> Fix this by sanitizing header->number before using it to index
> dev->patch_status, dev->prog_status and dev->sample_status.
> 
> Notice that given that speculation windows are large, the policy is
> to kill the speculation on the first load and not worry if it can be
> completed with a dependent load/store [1].
> 
> [1] https://marc.info/?l=linux-kernel&m=152449131114778&w=2
> 
> Cc: stable@vger.kernel.org
> Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>

Is there any platform with ISA slot that suffers from Spectre?


thanks,

Takashi
Gustavo A. R. Silva Dec. 20, 2018, 5:13 p.m. UTC | #2
On 12/20/18 2:11 AM, Takashi Iwai wrote:
> On Thu, 20 Dec 2018 00:31:43 +0100,
>   Gustavo A. R. Silva  wrote:
>>
>> header->number is indirectly controlled by user-space, hence leading
>> to a potential exploitation of the Spectre variant 1 vulnerability.
>>
>> This issue was detected with the help of Smatch:
>>
>> sound/isa/wavefront/wavefront_synth.c:792 wavefront_send_patch() warn: potential spectre issue 'dev->patch_status' [w] (local cap)
>> sound/isa/wavefront/wavefront_synth.c:819 wavefront_send_program() warn: potential spectre issue 'dev->prog_status' [w] (local cap)
>> sound/isa/wavefront/wavefront_synth.c:1197 wavefront_send_alias() warn: potential spectre issue 'dev->sample_status' [w]
>> sound/isa/wavefront/wavefront_synth.c:1248 wavefront_send_multisample() warn: potential spectre issue 'dev->sample_status' [w]
>> sound/isa/wavefront/wavefront_synth.c:1548 wavefront_synth_control() warn: potential spectre issue 'dev->sample_status' [r] (local cap)
>>
>> Fix this by sanitizing header->number before using it to index
>> dev->patch_status, dev->prog_status and dev->sample_status.
>>
>> Notice that given that speculation windows are large, the policy is
>> to kill the speculation on the first load and not worry if it can be
>> completed with a dependent load/store [1].
>>
>> [1] https://marc.info/?l=linux-kernel&m=152449131114778&w=2
>>
>> Cc: stable@vger.kernel.org
>> Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
> 
> Is there any platform with ISA slot that suffers from Spectre?
> 
> 

Do you mean 'any other'?

If so, yeah, I just spotted some Spectre vulns in sound/isa/sb/emu8000.c

I'll send a patch for that.

Thanks
--
Gustavo
Takashi Iwai Dec. 20, 2018, 5:35 p.m. UTC | #3
On Thu, 20 Dec 2018 18:13:31 +0100,
Gustavo A. R. Silva wrote:
> 
> On 12/20/18 2:11 AM, Takashi Iwai wrote:
> > On Thu, 20 Dec 2018 00:31:43 +0100,
> >   Gustavo A. R. Silva  wrote:
> >>
> >> header->number is indirectly controlled by user-space, hence leading
> >> to a potential exploitation of the Spectre variant 1 vulnerability.
> >>
> >> This issue was detected with the help of Smatch:
> >>
> >> sound/isa/wavefront/wavefront_synth.c:792 wavefront_send_patch() warn: potential spectre issue 'dev->patch_status' [w] (local cap)
> >> sound/isa/wavefront/wavefront_synth.c:819 wavefront_send_program() warn: potential spectre issue 'dev->prog_status' [w] (local cap)
> >> sound/isa/wavefront/wavefront_synth.c:1197 wavefront_send_alias() warn: potential spectre issue 'dev->sample_status' [w]
> >> sound/isa/wavefront/wavefront_synth.c:1248 wavefront_send_multisample() warn: potential spectre issue 'dev->sample_status' [w]
> >> sound/isa/wavefront/wavefront_synth.c:1548 wavefront_synth_control() warn: potential spectre issue 'dev->sample_status' [r] (local cap)
> >>
> >> Fix this by sanitizing header->number before using it to index
> >> dev->patch_status, dev->prog_status and dev->sample_status.
> >>
> >> Notice that given that speculation windows are large, the policy is
> >> to kill the speculation on the first load and not worry if it can be
> >> completed with a dependent load/store [1].
> >>
> >> [1] https://marc.info/?l=linux-kernel&m=152449131114778&w=2
> >>
> >> Cc: stable@vger.kernel.org
> >> Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
> >
> > Is there any platform with ISA slot that suffers from Spectre?
> >
> >
> 
> Do you mean 'any other'?

Well, no, my question is whether it makes sense to patch the code path
for such ISA drivers.  Spectre seems applicable since the model around
2006 or so, and ISA slot has been already dead for very long time.
And yet with this minor board...  I bet no one hits this in the
world.


thanks,

Takashi
Gustavo A. R. Silva Dec. 20, 2018, 5:51 p.m. UTC | #4
On 12/20/18 11:35 AM, Takashi Iwai wrote:

> 
> Well, no, my question is whether it makes sense to patch the code path
> for such ISA drivers.  Spectre seems applicable since the model around
> 2006 or so, and ISA slot has been already dead for very long time.
> And yet with this minor board...  I bet no one hits this in the
> world.
> 

Oh, I see.  I'm not stopping to analyze all the context around a driver 
other than the code itself.  So, thanks for pointing this out. I won't 
touch those drivers from now on.

Thanks
--
Gustavo

Patch
diff mbox series

diff --git a/sound/isa/wavefront/wavefront_synth.c b/sound/isa/wavefront/wavefront_synth.c
index 0b1e4b34b299..80196a533a36 100644
--- a/sound/isa/wavefront/wavefront_synth.c
+++ b/sound/isa/wavefront/wavefront_synth.c
@@ -31,6 +31,7 @@ 
 #include <linux/moduleparam.h>
 #include <linux/slab.h>
 #include <linux/module.h>
+#include <linux/nospec.h>
 #include <sound/core.h>
 #include <sound/snd_wavefront.h>
 #include <sound/initval.h>
@@ -788,7 +789,8 @@  wavefront_send_patch (snd_wavefront_t *dev, wavefront_patch_info *header)
 
 	if (header->number >= ARRAY_SIZE(dev->patch_status))
 		return -EINVAL;
-
+	header->number = array_index_nospec(header->number,
+					    ARRAY_SIZE(dev->patch_status));
 	dev->patch_status[header->number] |= WF_SLOT_FILLED;
 
 	bptr = buf;
@@ -815,7 +817,8 @@  wavefront_send_program (snd_wavefront_t *dev, wavefront_patch_info *header)
 
 	if (header->number >= ARRAY_SIZE(dev->prog_status))
 		return -EINVAL;
-
+	header->number = array_index_nospec(header->number,
+					    ARRAY_SIZE(dev->prog_status));
 	dev->prog_status[header->number] = WF_SLOT_USED;
 
 	/* XXX need to zero existing SLOT_USED bit for program_status[i]
@@ -1194,6 +1197,10 @@  wavefront_send_alias (snd_wavefront_t *dev, wavefront_patch_info *header)
 		return -EIO;
 	}
 
+	if (header->number >= ARRAY_SIZE(dev->sample_status))
+		return -EINVAL;
+	header->number = array_index_nospec(header->number,
+					    ARRAY_SIZE(dev->sample_status));
 	dev->sample_status[header->number] = (WF_SLOT_FILLED|WF_ST_ALIAS);
 
 	return (0);
@@ -1245,6 +1252,10 @@  wavefront_send_multisample (snd_wavefront_t *dev, wavefront_patch_info *header)
 		return -EIO;
 	}
 
+	if (header->number >= ARRAY_SIZE(dev->sample_status))
+		return -EINVAL;
+	header->number = array_index_nospec(header->number,
+					    ARRAY_SIZE(dev->sample_status));
 	dev->sample_status[header->number] = (WF_SLOT_FILLED|WF_ST_MULTISAMPLE);
 
 	kfree(msample_hdr);
@@ -1539,12 +1550,13 @@  wavefront_synth_control (snd_wavefront_card_t *acard,
 
 	case WFC_IDENTIFY_SLOT_TYPE:
 		i = wc->wbuf[0] | (wc->wbuf[1] << 7);
-		if (i <0 || i >= WF_MAX_SAMPLE) {
+		if (i < 0 || i >= WF_MAX_SAMPLE) {
 			snd_printk ("invalid slot ID %d\n",
 				i);
 			wc->status = EINVAL;
 			return -EINVAL;
 		}
+		i = array_index_nospec(i, WF_MAX_SAMPLE);
 		wc->rbuf[0] = dev->sample_status[i];
 		wc->status = 0;
 		return 0;