Skip to contentSkip to conversation

HID: picoLCD: off by one in dump_buff_as_hex()

PATCH In review Dan Carpenter 3 participants 5 messages Sep 14, 2012 – Sep 24, 2012

Subsystems (3)
lore
Share & tools
lore
#0 lore raw

PATCH 1/1 HID: picoLCD: off by one in dump_buff_as_hex()

We're placing the NUL terminator one character beyond the end of the buffer here.

---
This change obviously don't make the code worse, but I'm not positive it's the right fix. I'm not sure the lines before are doing the right thing either, if we had two chars of remaining space then wouldn't it be better to put the new line and NUL in the unused space?

If you decide to do it differently, then please feel to sent a patch for that and give me a Reported-by cookie.

drivers/hid/hid-picolcd_debugfs.c +1 -1
index eec85b5..ff271ff0 100644
@@ -390,7 +390,7 @@ static void dump_buff_as_hex(char *dst, size_t dst_sz, const u8 *data,
 		dst[j--] = '\0';
 		dst[j] = '\n';
 	} else
-		dst[j] = '\0';
+		dst[dst_sz - 1] = '\0';
 }
 
 void picolcd_debug_out_report(struct picolcd_data *data,
maintainer
#1 lore raw

Hi Dan,

Quoted 9 lines · On Fri, 14 September 2012 Dan Carpenter <[email protected]> wrote:

We're placing the NUL terminator one character beyond the end of the buffer here.

---
This change obviously don't make the code worse, but I'm not positive it's the right fix. I'm not sure the lines before are doing the right thing either, if we had two chars of remaining space then wouldn't it be better to put the new line and NUL in the unused space?

The output buffer full should not happen as the 256 bytes buffer can hold more than the max expected report size of 64 bytes.

An option would be to convert to hex_dump_to_buffer(), but as this happens partially under IRQ context - even though for debugging purposes - the switch may be a bit too expensive, especially as one still has to append linefeed after it.

I think I will extend your fix slightly in order to cover "too much input" in a way visible to /sys/kernel/hid/*/events reader (for the case that reports would grow in size).

Though no need to check for minimal output buffer size as callers are local and feed in #defined sized buffer.

More on Wednesday evening, too late today and no time tomorrow.

Bruno

Quoted 16 lines

If you decide to do it differently, then please feel to sent a patch for that and give me a Reported-by cookie.

drivers/hid/hid-picolcd_debugfs.c +1 -1
index eec85b5..ff271ff0 100644
@@ -390,7 +390,7 @@ static void dump_buff_as_hex(char *dst, size_t dst_sz, const u8 *data,
 		dst[j--] = '\0';
 		dst[j] = '\n';
 	} else
-		dst[j] = '\0';
+		dst[dst_sz - 1] = '\0';
 }
 
 void picolcd_debug_out_report(struct picolcd_data *data,
maintainer
#2 lore raw

Dan,

What's your opinion on below alternative patch? In addition to yours it makes would-overflow visible.

It does not check for output buffer having non-zero size but as callers are local with #defined buffer size I don't think that would be needed.

Author: Bruno Prémont <[email protected]>
Date: Wed Sep 19 21:18:10 2012 +0200
Subject: HID: picoLCD: bounds check in dump_buff_as_hex()

Make sure we keep enough space for terminating NUL character after last newline. If we have too much data, replace last byte with '.'s to make overflow visible.

Using hex_dump_to_buffer() is not interesting as it adds more overhead and does not append the trailing linefeed.

---
 drivers/hid/hid-picolcd_debugfs.c |   14 ++++++++------
 1 files changed, 8 insertions(+), 6 deletions(-)
drivers/hid/hid-picolcd_debugfs.c +6 -6
index 868853a..c5c2fd9 100644
@@ -381,16 +381,16 @@ static void dump_buff_as_hex(char *dst, size_t dst_sz, const u8 *data,
 		const size_t data_len)
 {
 	int i, j;
-	for (i = j = 0; i < data_len && j + 3 < dst_sz; i++) {
+	for (i = j = 0; i < data_len && j + 4 < dst_sz; i++) {
 		dst[j++] = hex_asc[(data[i] >> 4) & 0x0f];
 		dst[j++] = hex_asc[data[i] & 0x0f];
 		dst[j++] = ' ';
 	}
-	if (j < dst_sz) {
-		dst[j--] = '\0';
-		dst[j] = '\n';
-	} else
-		dst[j] = '\0';
+	dst[j]   = '\0';
+	if (j > 0)
+		dst[j-1] = '\n';
+	if (i < data_len && j > 2)
+		dst[j-2] = dst[j-3] = '.';
 }
 
 void picolcd_debug_out_report(struct picolcd_data *data,
#3 lore raw
Quoted 9 lines · Bruno Prémont

Dan,

What's your opinion on below alternative patch? In addition to yours it makes would-overflow visible.

It does not check for output buffer having non-zero size but as callers are local with #defined buffer size I don't think that would be needed.

Sorry for the delay. Looks good to me.

regards,
dan carpenter

--
To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

#4 lore raw
Quoted 9 lines · Dan Carpenter
Quoted 7 lines

What's your opinion on below alternative patch? In addition to yours it makes would-overflow visible.

It does not check for output buffer having non-zero size but as callers are local with #defined buffer size I don't think that would be needed.

Sorry for the delay. Looks good to me.

I am picking Bruno's patch. Thanks,

Signature · 2 lines
Jiri Kosina
SUSE Labs