dangernoodle-io / breadboard / 29359529919

95%

push

github

fix: always NUL-terminate the storage STR getter on truncation (B1-947) (#867)

nvs_vt_get_typed_str's BOUNCE (truncating) branch filled the caller's
entire buffer via a bare memcpy and returned BB_OK without writing a
NUL -- a caller cannot distinguish a full read from a truncating one
(both return BB_OK), so strlen()/sscanf() on the result walks off the
end of buf. This is a regression: the pre-B1-756 bb_nv_get_str path
went through bb_strlcpy and always terminated; the typed-vtable
migration dropped that guarantee. Fixed by routing the BOUNCE branch's
copy through bb_strlcpy (components/bb_str) instead of a bare memcpy;
out_len still reports the full stored length, so truncation detection
is unchanged. This fixes the hazard for free in every merged consumer
of the typed STR path: bb_tcp_client/bb_udp_client (#864) and
bb_mqtt_client (#865).

bb_config_get_str had the identical bug in its own default-value
fallback (a field with has_default=true, on BB_ERR_NOT_FOUND) -- a
bare memcpy with no NUL guarantee. Fixed the same way, via bb_strlcpy.

bb_config_get_str also turned out to be a bare forward on its success
path for backends with no STR-aware get_typed (ram/host/sdcard, per
bb_storage's documented blob fallback) -- those backends' generic
blob .get() has no NUL contract at all, truncating OR full. Since
bb_config is the only layer that knows a given read is a STR for
those backends, it now enforces termination itself after every
successful bb_storage_get_typed() call (a bounds-only write using the
already-validated out_len/cap, not a re-scan of untrusted memory --
bb_strlcpy doesn't fit here since it requires an already-terminated
source). This is belt-and-braces for nvs (already terminates) and the
actual fix for ram/host/sdcard, previously masked by two host tests
that asserted the vulnerable behavior with a zero-prefilled buffer
(now corrected to non-zero prefill + termination assertions).

The generic blob path (nvs_vt_get / ram_get / rtc_ge... (continued)

6905 of 7543 branches covered (91.54%)

Branch coverage included in aggregate %.

4 of 4 new or added lines in 1 file covered. (100.0%)

11598 of 11867 relevant lines covered (97.73%)

2424.38 hits per line