Skip to content

fix: add buffer-length check in cn10k_ml_model.c#1066

Closed
orbisai0security wants to merge 1 commit into
F-Stack:devfrom
orbisai0security:fix-cn10k-ml-model-buffer-bounds-check
Closed

fix: add buffer-length check in cn10k_ml_model.c#1066
orbisai0security wants to merge 1 commit into
F-Stack:devfrom
orbisai0security:fix-cn10k-ml-model-buffer-bounds-check

Conversation

@orbisai0security
Copy link
Copy Markdown

Summary

Fix critical severity security issue in dpdk/drivers/ml/cnxk/cn10k_ml_model.c.

Vulnerability

Field Value
ID V-002
Severity CRITICAL
Scanner multi_agent_ai
Rule V-002
File dpdk/drivers/ml/cnxk/cn10k_ml_model.c:333
Assessment Confirmed exploitable
CWE CWE-120

Description: The cn10k ML model loading code uses rte_memcpy with sizes directly from model metadata (metadata->init_model.file_size, metadata->main_model.file_size, metadata->finish_model.file_size, metadata->weights_bias.file_size) without validating that these sizes fit within the allocated DMA buffer. An attacker who can supply a crafted ML model file with manipulated size fields can cause heap buffer overflow in DMA memory, potentially achieving arbitrary code execution in driver context.

Changes

  • dpdk/drivers/ml/cnxk/cn10k_ml_model.c

Verification

  • Build passes
  • Scanner re-scan confirms fix
  • LLM code review passed

Automated security fix by OrbisAI Security

Automated security fix generated by OrbisAI Security
@jfb8856606
Copy link
Copy Markdown
Contributor

Thanks for the report. The bound check is technically reasonable and the underlying issue does exist in the upstream DPDK as well.

However, F-Stack embeds DPDK as a vendor copy and we deliberately avoid carrying our own patches against the DPDK source tree — fixes like this should land in upstream DPDK first (via https://patches.dpdk.org/ / DPDK mailing list), then flow into F-Stack through a normal DPDK version bump. Patching the embedded DPDK directly creates merge conflicts and long-term maintenance overhead on every DPDK upgrade.

Additionally, this driver targets Marvell OCTEON cnxk ML accelerators, which is not part of the typical F-Stack networking workload, and the cnxk ML driver isn't even built by default in F-Stack environments (it requires libarchive / jansson / dlpack / dmlc / tvm_runtime / tvmdp).

Please consider submitting this fix to upstream DPDK. Once it lands there and reaches the LTS branch we use, F-Stack will pick it up automatically. Closing this PR for now — no offense intended.

@jfb8856606 jfb8856606 closed this May 29, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants