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/addeed0e-2afb-fc74-3daf-0c0d47922e81%40siemens.com.
