linux-input.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Bruno Prémont" <bonbons@linux-vserver.org>
To: Dan Carpenter <dan.carpenter@oracle.com>
Cc: Jiri Kosina <jkosina@suse.cz>,
	linux-input@vger.kernel.org, kernel-janitors@vger.kernel.org
Subject: Re: [patch] HID: picoLCD: off by one in dump_buff_as_hex()
Date: Mon, 17 Sep 2012 22:54:37 +0200	[thread overview]
Message-ID: <20120917225437.6f2847ee@neptune.home> (raw)
In-Reply-To: <20120914110414.GA1152@elgon.mountain>

Hi Dan,

On Fri, 14 September 2012 Dan Carpenter <dan.carpenter@oracle.com> wrote:
> We're placing the NUL terminator one character beyond the end of the
> buffer here.
> 
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
> ---
> 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

> If you decide to do it differently, then please feel to sent a patch for
> that and give me a Reported-by cookie.
> 
> diff --git a/drivers/hid/hid-picolcd_debugfs.c b/drivers/hid/hid-picolcd_debugfs.c
> index eec85b5..ff271ff0 100644
> --- a/drivers/hid/hid-picolcd_debugfs.c
> +++ b/drivers/hid/hid-picolcd_debugfs.c
> @@ -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,

  reply	other threads:[~2012-09-17 20:55 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-09-14 11:04 [patch] HID: picoLCD: off by one in dump_buff_as_hex() Dan Carpenter
2012-09-17 20:54 ` Bruno Prémont [this message]
2012-09-19 19:35   ` Bruno Prémont
2012-09-22 12:55     ` Dan Carpenter
2012-09-24 21:07       ` Jiri Kosina

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20120917225437.6f2847ee@neptune.home \
    --to=bonbons@linux-vserver.org \
    --cc=dan.carpenter@oracle.com \
    --cc=jkosina@suse.cz \
    --cc=kernel-janitors@vger.kernel.org \
    --cc=linux-input@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).