java-topology/defects/contiki-ng/SCAN.md

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.