Summary
The insert_edge function in src/sean/wasm/graph.c accesses g->edges[source] and g->degree[source] without first verifying that source (or destination) is within the array bounds. The edges field is declared as edge *edges[MAXV + 1] (70001 elements, valid indices 0–70000). If a JavaScript caller passes a vertex index greater than 70000 via the exported insertEdge(source, destination) WASM API, the function writes past the end of the array, causing undefined behavior or a memory safety violation.
Evidence
Repository: bushidocodes/graph500-web
File(s):
src/sean/wasm/graph.c:60-79
src/sean/wasm/constants.h:1
Observed:
constants.h defines #define MAXV 70000
graph.c:17 declares edge *edges[MAXV + 1] (indices 0..70000)
graph.c:62: int32_t max = source > destination ? source : destination;
graph.c:64: if (max > g->number_vertices) g->number_vertices = max; — updates the vertex count but does not bounds-check against MAXV
graph.c:76: new_edge->next = g->edges[source]; — unchecked array access
graph.c:78: g->edges[source] = new_edge; — unchecked array write
graph.c:79: g->degree[source]++; — unchecked array write
src/sean/wasm/main.c exports insertEdge(int32_t source, int32_t destination) which forwards directly to insert_edge without any validation
Why this matters
This is a WASM module compiled with Emscripten and called from JavaScript. There is no language-level safety barrier preventing a JavaScript caller from passing arbitrarily large vertex indices. An out-of-bounds write corrupts the linear memory heap, which in WASM means adjacent allocations (including other graph state) can be silently overwritten, producing wrong BFS results or crashing the WASM instance.
Suggested fix
Add a bounds check at the top of insert_edge before any array access:
if (source <= 0 || source > MAXV || destination <= 0 || destination > MAXV) {
fprintf(stderr, "insert_edge: vertex out of range [1, %d]: source=%d dest=%d\n",
MAXV, source, destination);
return;
}
Apply the same check inside insertEdge in main.c so the public API validates inputs before forwarding them.
Summary
The
insert_edgefunction insrc/sean/wasm/graph.caccessesg->edges[source]andg->degree[source]without first verifying thatsource(ordestination) is within the array bounds. Theedgesfield is declared asedge *edges[MAXV + 1](70001 elements, valid indices 0–70000). If a JavaScript caller passes a vertex index greater than 70000 via the exportedinsertEdge(source, destination)WASM API, the function writes past the end of the array, causing undefined behavior or a memory safety violation.Evidence
Repository:
bushidocodes/graph500-webFile(s):
src/sean/wasm/graph.c:60-79src/sean/wasm/constants.h:1Observed:
constants.hdefines#define MAXV 70000graph.c:17declaresedge *edges[MAXV + 1](indices 0..70000)graph.c:62:int32_t max = source > destination ? source : destination;graph.c:64:if (max > g->number_vertices) g->number_vertices = max;— updates the vertex count but does not bounds-check againstMAXVgraph.c:76:new_edge->next = g->edges[source];— unchecked array accessgraph.c:78:g->edges[source] = new_edge;— unchecked array writegraph.c:79:g->degree[source]++;— unchecked array writesrc/sean/wasm/main.cexportsinsertEdge(int32_t source, int32_t destination)which forwards directly toinsert_edgewithout any validationWhy this matters
This is a WASM module compiled with Emscripten and called from JavaScript. There is no language-level safety barrier preventing a JavaScript caller from passing arbitrarily large vertex indices. An out-of-bounds write corrupts the linear memory heap, which in WASM means adjacent allocations (including other graph state) can be silently overwritten, producing wrong BFS results or crashing the WASM instance.
Suggested fix
Add a bounds check at the top of
insert_edgebefore any array access:Apply the same check inside
insertEdgeinmain.cso the public API validates inputs before forwarding them.