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 <mar...@redhat.com>
>>>> ---
>>>> 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.
Thanks
Laszlo
