> > case PI433_IOC_WR_TX_CFG:
> > if (copy_from_user(>tx_cfg, argp,
> >sizeof(struct pi433_tx_cfg)))
> > return -EFAULT;
> > break;
>
> Btw, it looks so wrong to me that we copy partial data to
> >tx_cfg... I'd really prefer copying it to a tmp
On Sat, Jun 09, 2018 at 11:48:42AM -0400, Hugo Lefeuvre wrote:
> case PI433_IOC_WR_TX_CFG:
> if (copy_from_user(>tx_cfg, argp,
>sizeof(struct pi433_tx_cfg)))
> return -EFAULT;
> break;
Btw, it looks so wrong to me that we copy partial data to
> > After discussing this issue on the kernel newbies mailing list[0] we
> > came to the conclusion that it is very unlikely that pi433_release and
> > pi433_ioctl would ever run concurrently in this case. This is also
> > true for read/write. Unless one can find a situation where this might
> >
On Thu, Jun 07, 2018 at 08:45:03AM -0400, Hugo Lefeuvre wrote:
> After discussing this issue on the kernel newbies mailing list[0] we
> came to the conclusion that it is very unlikely that pi433_release and
> pi433_ioctl would ever run concurrently in this case. This is also
> true for read/write.
> Add a mutex fixing a potential NULL pointer dereference in the pi433
> driver.
>
> If pi433_release and pi433_ioctl are concurrently called,
> pi433_release might set filp->private_data to NULL while pi433_ioctl
> is still accessing it, leading to NULL pointer dereference. This issue
> might
Add a mutex fixing a potential NULL pointer dereference in the pi433
driver.
If pi433_release and pi433_ioctl are concurrently called,
pi433_release might set filp->private_data to NULL while pi433_ioctl
is still accessing it, leading to NULL pointer dereference. This issue
might also affect
