qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] fw_cfg: fix memory corruption when all fw_cfg s


From: Marcel Apfelbaum
Subject: Re: [Qemu-devel] [PATCH] fw_cfg: fix memory corruption when all fw_cfg slots are used
Date: Tue, 9 Jan 2018 15:41:24 +0200
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.4.0

On 09/01/2018 15:36, Laszlo Ersek wrote:
On 01/09/18 14:35, Laszlo Ersek wrote:
On 01/09/18 14:33, Laszlo Ersek wrote:
On 01/09/18 14:18, Marcel Apfelbaum wrote:
On 09/01/2018 15:09, Laszlo Ersek wrote:

Hi Laszlo,

I'll respond first to this mail' I'll take my time with the rest :)

On 01/08/18 22:50, Marcel Apfelbaum wrote:
When all the fw_cfg slots are used, a write is made outside the
bounds of the fw_cfg files array as part of the sort algorithm.

Fix it by avoiding an unnecessary array element move.
Fix also an assert while at it.

Signed-off-by: Marcel Apfelbaum <address@hidden>
---
   hw/nvram/fw_cfg.c | 6 ++++--
   1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/hw/nvram/fw_cfg.c b/hw/nvram/fw_cfg.c
index 753ac0e4ea..4313484b21 100644
--- a/hw/nvram/fw_cfg.c
+++ b/hw/nvram/fw_cfg.c
@@ -784,7 +784,7 @@ void fw_cfg_add_file_callback(FWCfgState *s,
const char *filename,
        * index and "i - 1" is the one being copied from, thus the
        * unusual start and end in the for statement.
        */
-    for (i = count + 1; i > index; i--) {
+    for (i = count; i > index; i--) {
           s->files->f[i] = s->files->f[i - 1];
           s->files->f[i].select = cpu_to_be16(FW_CFG_FILE_FIRST + i);
           s->entries[0][FW_CFG_FILE_FIRST + i] =

This hunk looks correct to me.

After my change or before?

Well, the source code doesn't have "hunks", patches have hunks. :)

So, I meant, this part of your patch was correct, IMO.


Thanks, I didn't realize the distinction.


I think I am right.
At this point we have "count" elements in the array.
That means the last element in the array is at arr[count - 1].
We want to make room for the new element at index, so we move
all the elements from index to index + 1.

The first element we should move is arr[count - 1] to arr[count].
But the code moved arr[count] to arr [count + 1].
This move is not needed.


  We currently have count elements in the
array, so we cannot normally access the element *at* count. However, we
are extending the array right now, therefore we can assign (store) the
element at count (and then we'll increment count later). But accessing
an element at (count+1) is wrong.

@@ -833,7 +833,6 @@ void *fw_cfg_modify_file(FWCfgState *s, const
char *filename,
       assert(s->files);
         index = be32_to_cpu(s->files->count);
-    assert(index < fw_cfg_file_slots(s));
         for (i = 0; i < index; i++) {
           if (strcmp(filename, s->files->f[i].name) == 0) {
@@ -843,6 +842,9 @@ void *fw_cfg_modify_file(FWCfgState *s, const
char *filename,
               return ptr;
           }
       }
+
+    assert(index < fw_cfg_file_slots(s));
+
       /* add new one */
       fw_cfg_add_file_callback(s, filename, NULL, NULL, NULL, data,
len, true);
       return NULL;


I think I agree with Marc-André here, when I say, replace the assert
with a comment instead? (About the fact that fw_cfg_add_file_callback()
will assert(), *if* we reach that far.)

Hmm, what should we add to the comment? "We lost, brace for impact :)"

My point, if we are going to abort, let's abort as early as we can.
But if is a consensus, I'll get rid of it.

No, it's going to be another assert, just later. Assume that at this
point we have (index == fw_cfg_file_slots(s)), because the function
didn't find the element to modify, so it decides to add a new one, but
also we do not have room for the new one. So, with the suggested removal
of the assert, we call fw_cfg_add_file_callback().

Then, fw_cfg_add_file_callback() does:

     if (!s->files) {
         dsize = sizeof(uint32_t) + sizeof(FWCfgFile) * fw_cfg_file_slots(s);
         s->files = g_malloc0(dsize);
         fw_cfg_add_bytes(s, FW_CFG_FILE_DIR, s->files, dsize);
     }

     count = be32_to_cpu(s->files->count);
     assert(count < fw_cfg_file_slots(s));

The (!s->files) condition is expected to eval to false (our table is
full, so we do have a table).

And then, the assert() below the "if" will fire.

Am I missing something?

Hm, OK, your point was, abort as *early* as we can.


Right (if we are going to loose, let's loose as soon as we can).

I guess you are not wrong :) I'm fine either way, then.

... which means:

Reviewed-by: Laszlo Ersek <address@hidden>


Appreciated!

(sorry, need more sleep)


Thanks for looking into it,
Marcel




reply via email to

[Prev in Thread] Current Thread [Next in Thread]