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 <[email protected]> >>>>> --- >>>>> 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. >> >>> >>> 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. > > I guess you are not wrong :) I'm fine either way, then.
... which means: Reviewed-by: Laszlo Ersek <[email protected]> (sorry, need more sleep)
