[prasanna8585]

Summary

Four sibling functions in src/operators/fully-connected-nc.c compute an allocation size by multiplying caller-supplied output_channels (and, in two cases, input_channels * output_channels) by an element size, with no overflow check, and use the same unvalidated value as a write-loop bound immediately after — before any of this file's normal parameter validation (the output_channels == 0 / stride checks in create_fully_connected_nc) has run:

• xnn_create_fully_connected_nc_f16 — output_channels * sizeof(xnn_float16)
• xnn_create_fully_connected_nc_pf16 — same
• xnn_create_fully_connected_nc_f32_f16 — input_channels * output_channels * sizeof(float), and output_channels * sizeof(float) for the bias buffer
• xnn_create_fully_connected_nc_pf32_f16 — same

On a 32-bit size_t target (XNNPACK supports ARM32 and WASM32 — both real, shipping deployment targets), a channel count just above 2^31 (or 2^30 for the two-factor kernel-buffer case) wraps the multiplication to a small value. The allocation then succeeds at a tiny size while the subsequent loop still iterates the real, unwrapped channel count — a heap-buffer-overflow write. In the f16 bias-conversion path, the same loop also reads that many elements from the caller's bias array, which is only sized for the real (intended) channel count — an out-of-bounds read as well.

This is a narrow, specific gap: the main packed-weights buffer allocation a few hundred lines later in this same file is already correctly guarded with xnn_safe_mul() (see create_fully_connected_nc, packed_weights_size). This PR applies that exact same, already-established pattern to the four sites above.

Fix

Each site now computes the allocation size via xnn_safe_mul() first and returns xnn_status_invalid_parameter (consistent with this file's other validation-failure paths) if it would overflow, before doing any allocation or touching caller memory.

Verification

• Patch applies cleanly to current master.
• gcc -fsyntax-only -Wall -Wextra clean against the real repo headers, no new warnings introduced.
• Behavioral test using the repo's real xnn_safe_mul (from src/xnnpack/math.h) against the patched logic: the previously-overflowing input is now rejected with xnn_status_invalid_parameter before any allocation, and a legitimate small output_channels still succeeds unchanged.
• Bazel build/test status: see CI on this PR — not run in the reporting environment (no working Bazel/BCR network path available there).

[prasanna8585]

Hi Team,

is there any update require from my side on this ?

[Aelphy]

Nope, waiting for the internal approval.

[prasanna8585]

Hi @Aelphy ,

Just following up to check if this is ready to be merged.

[prasanna8585]

Hi @Aelphy ,

is there any update on this to get this merged?

[prasanna8585]

Hi @Aelphy ,

Just following up to check if this is ready to be merged.

[Aelphy]

Could you please rebase.

[prasanna8585]

Rebased and resolved the conflicts, but flagging something first: this looks like it may have been independently fixed upstream in 4a1dd2d (via #11362), which applies the same xnn_safe_mul guard to every site this PR touches, plus unit tests. Happy to leave this open or close it as superseded your call.