[re-adding the list]

On 25.05.21 08:00, Häner, Michael (SI BP R&D ZG FW CCP) wrote:
> I have also looked at the allocation. I came to a similar conclusion,
> but I wasn't sure. That's why I only considered copying.
> 

Copying is ok if allocation of the same size happened right before that.
In fact, strdup could actually do both things... Maybe a reason to drop
the patch in favor of a v2 that does exactly that.

Jan

> Michael
> 
> On Tue, 2021-05-25 at 07:27 +0200, Jan Kiszka wrote:
>> On 23.05.21 22:18, Michael Haener wrote:
>>> Avoid the "stringop-overflow" error. The so far specified bound
>>> depends on the length of the source argument.
>>>
>>> Signed-off-by: Michael Haener <[email protected]>
>>> ---
>>>  env/env_config_partitions.c | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/env/env_config_partitions.c
>>> b/env/env_config_partitions.c
>>> index f4b17e2..3b211e6 100644
>>> --- a/env/env_config_partitions.c
>>> +++ b/env/env_config_partitions.c
>>> @@ -61,7 +61,7 @@ bool probe_config_partitions(CONFIG_PART
>>> *cfgpart)
>>>                                     return false;
>>>                             }
>>>                     }
>>> -                   strncpy(cfgpart[count].devpath, devpath,
>>> +                   memcpy(cfgpart[count].devpath, devpath,
>>>                             strlen(devpath) + 1);
>>>                     if (probe_config_file(&cfgpart[count])) {
>>>                             printf_debug("%s", "Environment file
>>> found.\n");
>>>
>>
>> The change makes sense, specifically when looking at the code above
>> it
>> that allocates cfgpart[count].devpath accordingly.
>>
>> However, as we are at it: The condition for allocating looks
>> suspicious.
>> We only do so when devpath wasn't allocated yet. What could cause
>> that
>> case? Are we then sure that devpath was allocated with the right
>> size?
>> Very likely, because we are still on the same system, and bgenv_init
>> calls probe_config_partitions only once while bgenv_finalize properly
>> cleans up afterwards. All that is likely needlessly convoluted.
>>
>> So, bonus for sorting /that/ out as well.
>>
>> Thanks, this one merged already.
>>
>> Jan
>>

-- 
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux

-- 
You received this message because you are subscribed to the Google Groups "EFI 
Boot Guard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/efibootguard-dev/0b8deceb-e3d3-f4b2-b542-1074c73f05da%40siemens.com.

Reply via email to