The Linux stack is short; we need to be able to count the number
of bytes used at stack on each function. So, we don't like to
use variable-length arrays, as complained by smatch:
        drivers/media/dvb-frontends/horus3a.c:57:19: warning: Variable length 
array is used.

The max usecase of the driver seems to be 10 bytes + 1 for the
register.

So, let's be safe and allocate 11 bytes for the write buffer.
This should be enough to cover all cases. If not, let's print
an error message.

Signed-off-by: Mauro Carvalho Chehab <mche...@osg.samsung.com>
---
 drivers/media/dvb-frontends/ascot2e.c | 12 ++++++++++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/media/dvb-frontends/ascot2e.c 
b/drivers/media/dvb-frontends/ascot2e.c
index ae7e463c2f9b..f770f6a2c987 100644
--- a/drivers/media/dvb-frontends/ascot2e.c
+++ b/drivers/media/dvb-frontends/ascot2e.c
@@ -26,6 +26,8 @@
 #include "ascot2e.h"
 #include "dvb_frontend.h"
 
+#define MAX_WRITE_REGSIZE 10
+
 enum ascot2e_state {
        STATE_UNKNOWN,
        STATE_SLEEP,
@@ -120,16 +122,22 @@ static int ascot2e_write_regs(struct ascot2e_priv *priv,
                              u8 reg, const u8 *data, u32 len)
 {
        int ret;
-       u8 buf[len+1];
+       u8 buf[MAX_WRITE_REGSIZE + 1];
        struct i2c_msg msg[1] = {
                {
                        .addr = priv->i2c_address,
                        .flags = 0,
-                       .len = sizeof(buf),
+                       .len = len + 1,
                        .buf = buf,
                }
        };
 
+       if (len + 1 >= sizeof(buf)) {
+               dev_warn(&priv->i2c->dev,"wr reg=%04x: len=%d is too big!\n",
+                        reg, len + 1);
+               return -E2BIG;
+       }
+
        ascot2e_i2c_debug(priv, reg, 1, data, len);
        buf[0] = reg;
        memcpy(&buf[1], data, len);
-- 
2.4.3

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to