From: bugzilla@dpdk.org
To: dev@dpdk.org
Subject: [DPDK/other Bug 1748] Clarification on Possible Buffer Overflow Issues Reported by Fortify Tool
Date: Mon, 07 Jul 2025 09:12:57 +0000 [thread overview]
Message-ID: <bug-1748-3@https.bugs.dpdk.org/> (raw)
[-- Attachment #1: Type: text/plain, Size: 2643 bytes --]
https://bugs.dpdk.org/show_bug.cgi?id=1748
Bug ID: 1748
Summary: Clarification on Possible Buffer Overflow Issues
Reported by Fortify Tool
Product: DPDK
Version: 23.11
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: Normal
Component: other
Assignee: dev@dpdk.org
Reporter: nagendra.balagani@oracle.com
Target Milestone: ---
Hello Team,
While running Fortify static analysis on our code base that uses DPDK, we
observed some potential buffer overflow issues being reported within DPDK
library calls. At first glance, these instances appear to be false positives,
but we would like to confirm with the community and maintainers to ensure there
are no hidden risks.
Could you please help review these findings or suggest if there are any known
false positives in this area?
here are the detailed Fortify reports with exact file paths and line numbers
for your reference.
### Instance 1: rte_crypto.h Line 207
memset(op->asym, 0, sizeof(struct rte_crypto_asym_op));
Tool Description : The function __rte_crypto_op_reset() in rte_crypto.h writes
outside the bounds of asym on line 207, which could corrupt data, cause the
program to crash, or lead to the execution of malicious code.
Analysis Trace
rte_crypto.h:181 - Buffer asym Declared
rte_crypto.h:207 - memset()
Buffer Size: 0 bytes Write Length: 168 bytes
### Instance 2: rte_crypto_sym.h: 885
memset(op, 0, sizeof(*op));
Tool Description: The program writes outside the bounds of allocated memory,
which could corrupt data, crash the program, or lead to the execution of
malicious code.
Analysis Trace
rte_crypto.h:204 - Caller: __rte_crypto_op_reset
Buffer Size: 0
rte_crypto_sym.h:885 - memset()
Buffer Size: 0 bytes Write Length: 64 bytes [var 0] op.$offset: 0
### Instance3: rte_lpm.h: 347
tbl24_indexes[i] = ips[i] >> 8;
Tool Description: The function rte_lpm_lookup_bulk_func() in rte_lpm.h writes
outside the bounds of tbl24_indexes on line 347, which could corrupt data,
cause the program to crash, or lead to the execution of malicious code.
Analysis Trace
rte_lpm.h:339 - Buffer tbl24_indexes Allocated
rte_lpm.h:347 - Assignment to tbl24_indexes
Buffer Size: 262143 bytes Write Length: 1048572 bytes [var 0]
tbl24_indexes.$offset: 0 [var 1] i: 262142
Thank you in advance for your support and guidance.
Regards,
Nagendra
--
You are receiving this mail because:
You are the assignee for the bug.
[-- Attachment #2: Type: text/html, Size: 4532 bytes --]
reply other threads:[~2025-07-07 9:13 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=bug-1748-3@https.bugs.dpdk.org/ \
--to=bugzilla@dpdk.org \
--cc=dev@dpdk.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).