fix: add buffer-length check in cn10k_ml_model.c#1066
Conversation
Automated security fix generated by OrbisAI Security
|
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. |
Summary
Fix critical severity security issue in
dpdk/drivers/ml/cnxk/cn10k_ml_model.c.Vulnerability
V-002dpdk/drivers/ml/cnxk/cn10k_ml_model.c:333Description: 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.cVerification
Automated security fix by OrbisAI Security