Re: [PATCH 6/6] staging: pi433: Rename enum modShaping in rf69_enum.h

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




Am 04.12.2017 um 12:33 schrieb Dan Carpenter:
On Sun, Dec 03, 2017 at 04:17:26PM +0100, Simon Sandström wrote:
diff --git a/drivers/staging/pi433/pi433_if.h b/drivers/staging/pi433/pi433_if.h
index 34ff0d4807bd..bcfe29840889 100644
--- a/drivers/staging/pi433/pi433_if.h
+++ b/drivers/staging/pi433/pi433_if.h
@@ -63,7 +63,7 @@ struct pi433_tx_cfg {
  	__u16			bit_rate;
  	__u32			dev_frequency;
  	enum modulation		modulation;
-	enum modShaping		modShaping;
+	enum mod_shaping	mod_shaping;

I looked at how mod_shaping is set and the only place is in the ioctl:

    789          case PI433_IOC_WR_TX_CFG:
    790                  if (copy_from_user(&instance->tx_cfg, argp,
    791                                          sizeof(struct pi433_tx_cfg)))
    792                          return -EFAULT;
    793                  break;

We just write over the whole config.  Including important things like
rx_cfg.fixed_message_length.  There is no locking so when we do things
like:

    385          /* fixed or unlimited length? */
    386          if (dev->rx_cfg.fixed_message_length != 0)
    387          {
    388                  if (dev->rx_cfg.fixed_message_length > dev->rx_buffer_size)
                             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
check

    389                  {
    390                          retval = -1;
    391                          goto abort;
    392                  }
    393                  bytes_total = dev->rx_cfg.fixed_message_length;
                                       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
set this in the ioctl after the check but before this line and it looks
like a security problem.

    394                  dev_dbg(dev->dev,"rx: msg len set to %d by fixed length", bytes_total);
    395          }

Anyway, I guess this patch is fine.

regards,
dan carpenter


Hi Dan,

you are mixing rx and tx. The part from IOCTL is copied from the tx-part, the lower part is dealing with rx.

With rx there should be no problem, since IOCTL is blocked, as long as an rx operation is going on.

With tx, I also expect no problems, since instance->tx_cfg is never used to configure the rf69. Everytime, you pass in new data via write() a copy of tx_cfg is made. Transmission is done, using the copy of the tx_cfg, never by using instance->tx_cfg.

But maybe I didn't got your point and misunderstand your intention.

Cheers,

Marcus
_______________________________________________
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxx
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel




[Index of Archives]     [Linux Driver Backports]     [DMA Engine]     [Linux GPIO]     [Linux SPI]     [Video for Linux]     [Linux USB Devel]     [Linux Coverity]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux