pin_index can be 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/ptp/ptp_chardev.c:253 ptp_ioctl() warn: potential spectre issue
'ops->pin_config' [r] (local cap)
Fix this by sanitizing pin_index before using it to index
ops->pin_config, and before passing it as an argument to
function ptp_set_pinfunc(), in which it is used to index
info->pin_config.
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>
Acked-by: Richard Cochran <richardcochran@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
 
 #include <linux/slab.h>
 #include <linux/timekeeping.h>
 
+#include <linux/nospec.h>
+
 #include "ptp_private.h"
 
 static int ptp_disable_pinfunc(struct ptp_clock_info *ops,
                        err = -EINVAL;
                        break;
                }
+               pin_index = array_index_nospec(pin_index, ops->n_pins);
                if (mutex_lock_interruptible(&ptp->pincfg_mux))
                        return -ERESTARTSYS;
                pd = ops->pin_config[pin_index];
                        err = -EINVAL;
                        break;
                }
+               pin_index = array_index_nospec(pin_index, ops->n_pins);
                if (mutex_lock_interruptible(&ptp->pincfg_mux))
                        return -ERESTARTSYS;
                err = ptp_set_pinfunc(ptp, pin_index, pd.func, pd.chan);