From: fengchengwen <fengchengwen@huawei.com>
To: Stephen Hemminger <stephen@networkplumber.org>
Cc: <dpdklab@iol.unh.edu>, <test-report@dpdk.org>,
"dev@dpdk.org" <dev@dpdk.org>
Subject: Re: |WARNING| argparse: support range step for corelist parsing
Date: Tue, 27 Oct 2026 10:00:39 +0800 [thread overview]
Message-ID: <01b1ac92-e2f7-41d2-8b26-10bba7d3d197@huawei.com> (raw)
In-Reply-To: <20261019091940.5f31d146@phoenix.local>
On 10/20/2026 12:19 AM, Stephen Hemminger wrote:
> On Mon, 19 Oct 2026 16:36:12 +0800
> fengchengwen <fengchengwen@huawei.com> wrote:
>
>>> When `step` is large and `min + step` exceeds `INT32_MAX`, the loop counter wraps around to a negative value, creating an infinite loop. The variables `min` and `max` are `int` (32-bit signed), and `step` is `int32_t`. If a malicious or mistaken user provides input like `"0-100:2147483647"`, the addition `min += step` will overflow after the first iteration.
>>
>> False positive, the:
>> errno = 0;
>> idx = strtol(value, &end, 10);
>> last = end;
>> if (errno || idx > UINT16_MAX) {
>> ARGPARSE_LOG(ERR, "argument %s contains a numerical value out of range!",
>> arg->name_long);
>> return -EINVAL;
>> }
>> already treat such input as an error.
>
> Since non-negative steps don't make sense, I would use strtoul() instead
> and bound it by MAX_LCORE
Hi Stephen,
Thanks for your suggestion.
While using strtoul() and bounding by MAX_LCORE sounds logical, I prefer to keep
the current implementation for the following reasons:
1. Current validation is already safe: if using strtoul() we should also keep
"
if (!isdigit(*value)) {
ARGPARSE_LOG(ERR, "argument %s has an unexpected non digit character!",
arg->name_long);
return -EINVAL;
}
"
because we don't want "+1" as a valid input.
If there has no error, then idx is valid in [0, LONG_MAX], it will never be negative in
the following execute flow.
2. MAX_LCORE varies across platforms: MAX_LCORE is a build-time configuration that heavily
depends on the target SoC. On some resource-constrained or specific SoCs, MAX_LCORE might
be configured to a very small number (e.g., 4). If we enforce MAX_LCORE as a hard limit for
the step value, it will cause certain valid test cases or generalized step ranges to fail
prematurely on those platforms, reducing the robustness of the argparse library.
Best regards,
Chengwen
>
prev parent reply other threads:[~2026-10-27 2:00 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <<20261016093001.9067-1-fengchengwen@huawei.com>
[not found] ` <20261016100926.06D096051830@postal.iol.unh.edu>
2026-10-19 8:27 ` |WARNING| argparse: support range step for corelist parsing fengchengwen
[not found] ` <20261016101228.123E46051830@postal.iol.unh.edu>
2026-10-19 8:36 ` fengchengwen
2026-10-19 16:19 ` Stephen Hemminger
2026-10-27 2:00 ` fengchengwen [this message]
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=01b1ac92-e2f7-41d2-8b26-10bba7d3d197@huawei.com \
--to=fengchengwen@huawei.com \
--cc=dev@dpdk.org \
--cc=dpdklab@iol.unh.edu \
--cc=stephen@networkplumber.org \
--cc=test-report@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