usbip: vhci_sysfs: fix potential Spectre v1

pdev_nr and rhport can be 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:
drivers/usb/usbip/vhci_sysfs.c:238 detach_store() warn: potential spectre issue 'vhcis' drivers/usb/usbip/vhci_sysfs.c:328 attach_store() warn: potential spectre issue 'vhcis' drivers/usb/usbip/vhci_sysfs.c:338 attach_store() warn: potential spectre issue 'vhci->vhci_hcd_ss->vdev' drivers/usb/usbip/vhci_sysfs.c:340 attach_store() warn: potential spectre issue 'vhci->vhci_hcd_hs->vdev'

Fix this by sanitizing pdev_nr and rhport before using them to index vhcis and vhci->vhci_hcd_ss->vdev respectively.

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 [email protected]

Signed-off-by Gustavo A. R. Silva <[email protected]>

---
 drivers/usb/usbip/vhci_sysfs.c | 6 ++++++
 1 file changed, 6 insertions(+)

drivers/usb/usbip/vhci_sysfs.c +2 -0

index 4880838..9045888 100644
@@ -10,6 +10,8 @@
 #include <linux/platform_device.h>
 #include <linux/slab.h>
 
+#include <linux/nospec.h>
+
 #include "usbip_common.h"
 #include "vhci.h"
 

Quoted 12 lines · Gustavo A. R. Silva

pdev_nr and rhport can be 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:
drivers/usb/usbip/vhci_sysfs.c:238 detach_store() warn: potential spectre issue 'vhcis' drivers/usb/usbip/vhci_sysfs.c:328 attach_store() warn: potential spectre issue 'vhcis' drivers/usb/usbip/vhci_sysfs.c:338 attach_store() warn: potential spectre issue 'vhci->vhci_hcd_ss->vdev' drivers/usb/usbip/vhci_sysfs.c:340 attach_store() warn: potential spectre issue 'vhci->vhci_hcd_hs->vdev'

Nit, no need to line-wrap long error messages from tools :)

Quoted 32 lines

Fix this by sanitizing pdev_nr and rhport before using them to index vhcis and vhci->vhci_hcd_ss->vdev respectively.

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 [email protected]

Signed-off-by Gustavo A. R. Silva <[email protected]>

---
  drivers/usb/usbip/vhci_sysfs.c | 6 ++++++
  1 file changed, 6 insertions(+)

drivers/usb/usbip/vhci_sysfs.c +2 -0

index 4880838..9045888 100644
@@ -10,6 +10,8 @@
  #include <linux/platform_device.h>
  #include <linux/slab.h>
 
+#include <linux/nospec.h>
+
  #include "usbip_common.h"
  #include "vhci.h"
 

@@ -235,6 +237,8 @@ static ssize_t detach_store(struct device *dev, struct device_attribute *attr,
  	if (!valid_port(pdev_nr, rhport))
  		return -EINVAL;
 

drivers/usb/usbip/vhci_sysfs.c static ssize_t detach_store(struct device *dev, struct device_attribute *attr, · line 241

Quoted 2 lines

drivers/usb/usbip/vhci_sysfs.c +2 -0

+	pdev_nr = array_index_nospec(pdev_nr, vhci_num_controllers);
+	rhport = array_index_nospec(rhport, VHCI_HC_PORTS);

Shouldn't we just do this in one place, in the valid_port() function?

That way it keeps the range checking logic in one place (now it is in 3 places in the function), which should make maintenance much simpler.

Hi Greg,

Quoted 14 lines · Greg Kroah-Hartman

Quoted 12 lines · Gustavo A. R. Silva

pdev_nr and rhport can be 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:
drivers/usb/usbip/vhci_sysfs.c:238 detach_store() warn: potential spectre issue 'vhcis' drivers/usb/usbip/vhci_sysfs.c:328 attach_store() warn: potential spectre issue 'vhcis' drivers/usb/usbip/vhci_sysfs.c:338 attach_store() warn: potential spectre issue 'vhci->vhci_hcd_ss->vdev' drivers/usb/usbip/vhci_sysfs.c:340 attach_store() warn: potential spectre issue 'vhci->vhci_hcd_hs->vdev'

Quoted 2 lines

Nit, no need to line-wrap long error messages from tools :)

Got it.

Quoted 34 lines

Quoted 27 lines

Fix this by sanitizing pdev_nr and rhport before using them to index vhcis and vhci->vhci_hcd_ss->vdev respectively.

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 [email protected]

Signed-off-by Gustavo A. R. Silva <[email protected]>

---
  drivers/usb/usbip/vhci_sysfs.c | 6 ++++++
  1 file changed, 6 insertions(+)

drivers/usb/usbip/vhci_sysfs.c +2 -0

index 4880838..9045888 100644
@@ -10,6 +10,8 @@
  #include <linux/platform_device.h>
  #include <linux/slab.h>
+#include <linux/nospec.h>
+
  #include "usbip_common.h"
  #include "vhci.h"

drivers/usb/usbip/vhci_sysfs.c static ssize_t detach_store(struct device *dev, struct device_attribute *attr, · line 240

Quoted 4 lines

drivers/usb/usbip/vhci_sysfs.c +2 -0

@@ -235,6 +237,8 @@ static ssize_t detach_store(struct device *dev, struct device_attribute *attr,
  	if (!valid_port(pdev_nr, rhport))
  		return -EINVAL;
+	pdev_nr = array_index_nospec(pdev_nr, vhci_num_controllers);
+	rhport = array_index_nospec(rhport, VHCI_HC_PORTS);

Shouldn't we just do this in one place, in the valid_port() function?

Quoted 3 lines

That way it keeps the range checking logic in one place (now it is in 3 places in the function), which should make maintenance much simpler.

Yep, I thought about that, the thing is: what happens if the hardware is "trained" to predict that valid_port always evaluates to false, and then malicious values are stored in pdev_nr and nhport?

It seems to me that under this scenario we need to serialize instructions in this place.

What do you think?

Quoted 10 lines

Quoted 5 lines

Shouldn't we just do this in one place, in the valid_port() function?

That way it keeps the range checking logic in one place (now it is in 3 places in the function), which should make maintenance much simpler.

Yep, I thought about that, the thing is: what happens if the hardware is "trained" to predict that valid_port always evaluates to false, and then malicious values are stored in pdev_nr and nhport?

Quoted 4 lines

It seems to me that under this scenario we need to serialize instructions in this place.

What do you think?

I don't understand, it should not matter where you put the barrier. Be it a function call back or right after it, it does the same thing, it stops speculation from crossing that barrier.

So it _should_ work either way, if I understand the issue correctly.

If not, what am I missing?