| Message ID | 20181218161445.GA10311@embeddedor (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | loop: Fix potential Spectre v1 vulnerability | expand |
diff --git a/drivers/block/loop.c b/drivers/block/loop.c index 0939f36548c9..015d255f451b 100644 --- a/drivers/block/loop.c +++ b/drivers/block/loop.c @@ -83,6 +83,8 @@ #include <linux/uaccess.h> +#include <linux/nospec.h> + static DEFINE_IDR(loop_index_idr); static DEFINE_MUTEX(loop_ctl_mutex); @@ -1205,6 +1207,7 @@ loop_set_status(struct loop_device *lo, const struct loop_info64 *info) err = -EINVAL; goto out_unfreeze; } + type = array_index_nospec(type, MAX_LO_CRYPT); xfer = xfer_funcs[type]; if (xfer == NULL) { err = -EINVAL;
type 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: drivers/block/loop.c:1208 loop_set_status() warn: potential spectre issue 'xfer_funcs' [r] (local cap) Fix this by sanitizing type before using it to index xfer_funcs. 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> --- drivers/block/loop.c | 3 +++ 1 file changed, 3 insertions(+)