2.3 KiB
Contiki-NG 5-MOAD Scan — 2026-03-31
Target: https://github.com/contiki-ng/contiki-ng (depth=1) Focus: os/net/, os/lib/, os/sys/, os/services/lwm2m/
MOAD-0001 (CWE-407) — CLEAN
Neighbor table lookup (index_from_lladdr in os/net/nbr-table.c) is O(N) per
per-packet call, where N = NBR_TABLE_CONF_MAX_NEIGHBORS (default 16). This is
O(N) per event, not O(N^2). N is bounded by a compile-time constant, not user input.
Route lookup (uip_ds6_route_lookup in os/net/ipv6/uip-ds6-route.c) is similarly
O(R) per packet, R bounded by NETSTACK_MAX_ROUTE_ENTRIES (default 16).
TSCH link lookup (tsch_schedule_get_link_by_handle) is O(S*L) for S slotframes
and L links. Both are bounded small in practice for IoT deployments.
No unbounded O(N^2) hot-path defect found. The linked-list structures are appropriate for constrained IoT with small, fixed-size neighbor tables.
MOAD-0002 (Intertangle) — CLEAN
Contiki-NG uses a protothread/event-driven cooperative scheduler. Each subsystem (TSCH, RPL, CoAP, LwM2M, 6LoWPAN) registers independently with the netstack. No shared mutable god object coupling independent subsystems found.
MOAD-0003 (Leaked Context) — CLEAN
Contiki-NG is an embedded RTOS using cooperative protothreads, not OS threads. No ThreadLocal, pthreads, or task-local storage patterns found. MOAD-0003 does not apply to this architecture.
MOAD-0004 (CWE-312) — 1 DEFECT FOUND
See contiki-0001.
os/services/lwm2m/lwm2m-security.c write_security_object() logs the raw LwM2M
PSK secret key and PKI public key bytes via LOG_DBG_COAP_STRING at LOG_DBG
level. LOG_CONF_LEVEL_LWM2M defaults to LOG_LEVEL_NONE in production builds
but is runtime-configurable and is set to LOG_LEVEL_DBG in example projects
(examples/libs/logging/project-conf.h). When debug logging is active the
device's network authentication credentials are written to UART/serial in
cleartext, where they can be captured by gateway nodes and stored in cloud
infrastructure.
MOAD-0005 (Thundering Herd) — CLEAN
Contiki-NG uses cooperative scheduling — only one protothread executes at a time.
There is no concurrent cache stampede possible within a single node. The SPI bus
uses spi_arch_lock_and_open/spi_arch_close_and_unlock for hardware-level
exclusive access. No concurrent get+null+compute+put pattern found.