Thread (17 messages) 17 messages, 4 authors, 2018-07-27

Re: [PATCH v1 07/10] Input: atmel_mxt_ts - zero terminate config firmware file

From: Nick Dyer <nick@shmanahar.org>
Date: 2018-07-24 20:44:04
Also in: lkml

On Mon, Jul 23, 2018 at 03:35:34PM -0700, Dmitry Torokhov wrote:
On Fri, Jul 20, 2018 at 10:51:19PM +0100, Nick Dyer wrote:
quoted
From: Nick Dyer <redacted>

We use sscanf to parse the configuration file, so it's necessary to zero
terminate the configuration otherwise a truncated file can cause the
parser to run off into uninitialised memory.

Signed-off-by: Nick Dyer <redacted>
---
 drivers/input/touchscreen/atmel_mxt_ts.c | 36 +++++++++++++++++-------
 1 file changed, 26 insertions(+), 10 deletions(-)
diff --git a/drivers/input/touchscreen/atmel_mxt_ts.c b/drivers/input/touchscreen/atmel_mxt_ts.c
index 0ce126e918f1..2d1fddafb7f9 100644
--- a/drivers/input/touchscreen/atmel_mxt_ts.c
+++ b/drivers/input/touchscreen/atmel_mxt_ts.c
@@ -279,7 +279,7 @@ enum mxt_suspend_mode {
 
 /* Config update context */
 struct mxt_cfg {
-	const u8 *raw;
+	u8 *raw;
 	size_t raw_size;
 	off_t raw_pos;
 
@@ -1451,14 +1451,21 @@ static int mxt_update_cfg(struct mxt_data *data, const struct firmware *fw)
 	u32 info_crc, config_crc, calculated_crc;
 	u16 crc_start = 0;
 
-	cfg.raw = fw->data;
+	/* Make zero terminated copy of the OBP_RAW file */
+	cfg.raw = kzalloc(fw->size + 1, GFP_KERNEL);
kmemdup_nul()? I guess config it not that big to be concerned with
kmalloc() vs vmalloc() and allocation failures...
Yes, that looks like it should work. There's a limit on the size of the
data due to the I2C address space, so we should be fine.

Nick
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help