Hi Tom, I've checked 661173 and it looks like a false positive - but one that is likely to reappear going forward.
On Tue, Oct 27, 2026 at 5:27 AM Tom Rini <[email protected]> wrote: > > Here's the latest report. Since it says 20 out of 25, I downloaded a > report as well and the 5 not listed here are: [...] > CID 661173, String not null terminated, boot/bootmeth_bls.c,bls_boot > > CID 661173: (#1 of 1): String not null terminated (STRING_NULL) > 7. string_null: Passing unterminated string label->name to parse_label_keys, > which expects a null-terminated string.[show details] > 309 ret = parse_label_keys(&body, &scratch, label, true); > 310 if (ret < 0) The string it complains about arrives via memdup_nul(), which does (in lib/string.c:357-358): dst[len] = '\0'; return memcpy(dst, src, len); Apparently Coverity misses the assignment of the terminator which precedes the memcpy call and flags the string as unterminated. Shall we swap the order of those two operations to keep Coverity happy going forward? The behavior doesn't change either way, although directly returning the memcpy result (as it is done currently) looks a bit neater to me. Best regards, Alexey
