All of lore.kernel.org
 help / color / mirror / Atom feed
From: Wolfgang Bumiller <w.bumiller@proxmox.com>
To: P J P <ppandit@redhat.com>
Cc: qemu-devel@nongnu.org, Ling Liu <liuling-it@360.cn>
Subject: Re: [Qemu-devel] [PATCH] hmp: avoid redundant null termination of buffer
Date: Fri, 8 Jan 2016 15:38:31 +0100	[thread overview]
Message-ID: <20160108143831.GA7632@olga> (raw)
In-Reply-To: <alpine.LFD.2.20.1601081925150.30835@wniryva>

On Fri, Jan 08, 2016 at 07:29:31PM +0530, P J P wrote:
> +-- On Fri, 8 Jan 2016, Wolfgang Bumiller wrote --+
> | Ah yes, how could I miss that. Maybe just add a min() around the
> | keyname_len computation?
> | 
> | - keyname_len = separator ? separator - keys : strlen(keys);
> | + keyname_len = MIN(sizeof(keyname_buf), separator ? separator - keys : strlen(keys))
> 
>   Actually, only use for 'keyname_len' is in the subsequent if statement, 

And the replacing of the minus in combined keys.

> which IIUC compares the keyname_buf for "<" key. Maybe it could say
> 
>   + if (!strncmp(keyname_buf, "<-", 2))
> 
> and remove the 'keyname_len' altogether.

This wouldn't catch '<' without '-'. (`sendkey <`)
Also, strncmp with a length of 1 (in the original) seems weird.

In the end my MIN() approach would be too forgiving when a key name is
longer than keyname_buf and its 15-byte substring exists (which I
doubt, though). Ie. {15chars}{and more} would be treated as {15chars}.
Worse with {15chars}{and more}-{anotherkey}.

keyname_len is not useless and perhaps it would be best to just do an
early error check there as I do below.
This makes sure no OOB write happens and changes the error output to
include the 'keys' part instead of keyname_buf. We can do this because
the two other `goto err_out` cases happen after using keyname_buf which
had been pstrcpy()d from the last keys, so 'keys' will contain the same
or more info, and works better for the new case since a string that is
too long might be cut off and then only part of it is displayed if the
input is say a combination of one too-long (thus invalid) key and a
second one.

Alternatively the if() can simply happen after pstrcpy() as a cut-off
error should be good enough anyway.

@@ -1749,6 +1749,9 @@ void hmp_sendkey(Monitor *mon, const QDict *qdict)
     while (1) {
         separator = strchr(keys, '-');
         keyname_len = separator ? separator - keys : strlen(keys);
+        if (keyname_len >= sizeof(keyname_buf))
+            goto err_out;
+
         pstrcpy(keyname_buf, sizeof(keyname_buf), keys);

         /* Be compatible with old interface, convert user inputted "<" */
@@ -1800,7 +1803,7 @@ out:
     return;

 err_out:
-    monitor_printf(mon, "invalid parameter: %s\n", keyname_buf);
+    monitor_printf(mon, "invalid parameter: %s\n", keys);
     goto out;
 }

  reply	other threads:[~2016-01-08 14:38 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-17 12:40 [Qemu-devel] [PATCH] hmp: avoid redundant null termination of buffer P J P
2015-12-18  3:46 ` 刘令
2015-12-18  4:34   ` P J P
2015-12-22 18:48 ` Luiz Capitulino
2016-01-12  8:41   ` Markus Armbruster
2016-01-08  9:19 ` Wolfgang Bumiller
2016-01-08 12:19   ` P J P
2016-01-08 13:02     ` Wolfgang Bumiller
2016-01-08 13:59       ` P J P
2016-01-08 14:38         ` Wolfgang Bumiller [this message]
2016-01-08 17:32           ` P J P
2016-01-09  9:31             ` Wolfgang Bumiller
2016-01-09 13:03               ` P J P
2016-01-10  7:56                 ` Michael Tokarev
2016-01-11  7:00                   ` P J P
2016-01-11  7:59                   ` Wolfgang Bumiller
2016-01-11  8:22                     ` P J P
2016-01-12  8:45                     ` Markus Armbruster
2016-01-12  9:27                       ` Wolfgang Bumiller
2016-01-12 16:00                         ` Markus Armbruster
2016-01-12 16:25                           ` Wolfgang Bumiller
2016-01-12 16:52                             ` Markus Armbruster
2016-01-13  8:09                               ` Wolfgang Bumiller
2016-01-18 13:02                                 ` Markus Armbruster
2016-01-18 13:38                                   ` Wolfgang Bumiller
2016-01-18 14:23                                     ` Markus Armbruster
2016-01-26  9:36                                       ` Michael Tokarev
2016-01-28 10:52                                         ` Michael Tokarev
2016-01-28 14:45                                           ` Markus Armbruster

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=20160108143831.GA7632@olga \
    --to=w.bumiller@proxmox.com \
    --cc=liuling-it@360.cn \
    --cc=ppandit@redhat.com \
    --cc=qemu-devel@nongnu.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.