From: 0-day Robot <robot@bytheb.org>
To: test-report@dpdk.org, Stephen Hemminger <stephen@networkplumber.org>
Subject: |SUCCESS| pw159223 [PATCH v5 12/17] eal: check for hugefile path overflow
Date: Tue, 16 Dec 2025 11:12:23 -0500 [thread overview]
Message-ID: <20251216161223.762587-1-robot@bytheb.org> (raw)
In-Reply-To: <20251207191242.165619-13-stephen@networkplumber.org>
Test-Label: 0day Robot - Claude SONNET
Test-Status: SUCCESS
http://dpdk.org/patch/159223
_AI Review Comments Available_
git sha: Not available
Author: Stephen Hemminger <stephen@networkplumber.org>
eal: check for hugefile path overflow
This commit adds overflow checking when constructing huge file paths to
prevent PATH_MAX buffer overruns.
> diff --git a/lib/eal/common/eal_filesystem.h b/lib/eal/common/eal_filesystem.h
> index 2de88d7cc2..90b1cbb484 100644
> --- a/lib/eal/common/eal_filesystem.h
> +++ b/lib/eal/common/eal_filesystem.h
> @@ -100,12 +100,14 @@ eal_hugepage_data_path(void)
>
> /** String format for hugepage map files. */
> #define HUGEFILE_FMT "%s/%smap_%d"
> -static inline const char *
> +static inline __rte_warn_unused_result const char *
> eal_get_hugefile_path(char *buffer, size_t buflen, const char *hugedir, int f_id)
> {
> - snprintf(buffer, buflen, HUGEFILE_FMT, hugedir,
> - eal_get_hugefile_prefix(), f_id);
> - return buffer;
> + if (snprintf(buffer, buflen, HUGEFILE_FMT, hugedir,
> + eal_get_hugefile_prefix(), f_id) >= (int)buflen)
> + return NULL;
> + else
> + return buffer;
> }
The buffer parameter is always modified by snprintf even on overflow.
Will calling code incorrectly use a truncated path when this function
returns NULL?
[ ... ]
> diff --git a/lib/eal/linux/eal_hugepage_info.c b/lib/eal/linux/eal_hugepage_info.c
> index fe3351259e..cddffb9efb 100644
> --- a/lib/eal/linux/eal_hugepage_info.c
> +++ b/lib/eal/linux/eal_hugepage_info.c
> @@ -68,11 +68,14 @@ create_shared_memory(const char *filename, const size_t mem_size)
>
> static int get_hp_sysfs_value(const char *subdir, const char *file, unsigned long *val)
> {
> - char path[PATH_MAX];
> + char *path = NULL;
> + int ret;
>
> - snprintf(path, sizeof(path), "%s/%s/%s",
> - sys_dir_path, subdir, file);
> - return eal_parse_sysfs_value(path, val);
> + if (asprintf(&path, "%s/%s/%s", sys_dir_path, subdir, file) < 0)
> + return -1;
> + ret = eal_parse_sysfs_value(path, val);
> + free(path);
> + return ret;
> }
[ ... ]
> @@ -133,13 +136,15 @@ get_num_hugepages(const char *subdir, size_t sz, unsigned int reusable_pages)
> static uint32_t
> get_num_hugepages_on_node(const char *subdir, unsigned int socket, size_t sz)
> {
> - char path[PATH_MAX], socketpath[PATH_MAX];
> + char *path = NULL, *socketpath = NULL;
> DIR *socketdir;
> unsigned long num_pages = 0;
> const char *nr_hp_file = "free_hugepages";
>
> - snprintf(socketpath, sizeof(socketpath), "%s/node%u/hugepages",
> - sys_pages_numa_dir_path, socket);
> + if (asprintf(&socketpath, "%s/node%u/hugepages", sys_pages_numa_dir_path, socket) < 0) {
> + EAL_LOG(ERR, "Can not format node huge page path");
> + goto nopages;
> + }
[ ... ]
> @@ -147,17 +152,16 @@ get_num_hugepages_on_node(const char *subdir, unsigned int socket, size_t sz)
> closedir(socketdir);
> } else {
> /* Can't find socket dir, so ignore it */
> - return 0;
> + goto nopages;
> }
>
> - if (snprintf(path, sizeof(path), "%s/%s/%s", socketpath, subdir, nr_hp_file) >= PATH_MAX) {
> - EAL_LOG(NOTICE, "Socket path %s/%s/%s is truncated",
> - socketpath, subdir, nr_hp_file);
> - return 0;
> + if (asprintf(&path, "%s/%s/%s", socketpath, subdir, nr_hp_file) < 0) {
> + EAL_LOG(ERR, "Can not format free hugepages path");
> + goto nopages;
> }
>
> if (eal_parse_sysfs_value(path, &num_pages) < 0)
> - return 0;
> + goto nopages;
Does this change affect the original behavior? Previously, the function
would return 0 after logging if the path was valid but file parsing
failed. Now it goes to nopages which also returns 0 but cleans up memory.
[ ... ]
> @@ -204,7 +212,7 @@ get_hugepage_dir(uint64_t hugepage_sz, char *hugedir, int len)
> const char proc_mounts[] = "/proc/mounts";
> const char pagesize_opt[] = "pagesize=";
> const size_t pagesize_opt_len = sizeof(pagesize_opt) - 1;
> - char found[PATH_MAX] = "";
> + const char *found = NULL;
[ ... ]
> @@ -247,7 +255,7 @@ get_hugepage_dir(uint64_t hugepage_sz, char *hugedir, int len)
> * If no --huge-dir option has been given, we're done.
> */
> if (internal_conf->hugepage_dir == NULL) {
> - strlcpy(found, entry.mnt_dir, len);
> + found = entry.mnt_dir;
> break;
> }
[ ... ]
> @@ -267,13 +275,13 @@ get_hugepage_dir(uint64_t hugepage_sz, char *hugedir, int len)
> * We found a match, but only prefer it if it's a longer match
> * (so /mnt/1 is preferred over /mnt for matching /mnt/1/2)).
> */
> - if (mountpt_len > strlen(found))
> - strlcpy(found, entry.mnt_dir, len);
> + if (found == NULL || mountpt_len > strlen(found))
> + found = strdupa(entry.mnt_dir);
Does this usage of strdupa create a stack memory management issue? The
strdupa allocation will be freed when get_hugepage_dir returns, but
found is only used within this function scope, so this appears safe.
[ ... ]
> diff --git a/lib/eal/linux/eal_memalloc.c b/lib/eal/linux/eal_memalloc.c
> index 1e60e21620..d9e8ea76b9 100644
> --- a/lib/eal/linux/eal_memalloc.c
> +++ b/lib/eal/linux/eal_memalloc.c
> @@ -276,12 +277,18 @@ get_seg_fd(char *path, int buflen, struct hugepage_info *hi,
>
> if (internal_conf->single_file_segments) {
> out_fd = &fd_list[list_idx].memseg_list_fd;
> - eal_get_hugefile_path(path, buflen, hi->hugedir, list_idx);
> + huge_path = eal_get_hugefile_path(path, buflen, hi->hugedir, list_idx);
> } else {
> out_fd = &fd_list[list_idx].fds[seg_idx];
> - eal_get_hugefile_path(path, buflen, hi->hugedir,
> + huge_path = eal_get_hugefile_path(path, buflen, hi->hugedir,
> list_idx * RTE_MAX_MEMSEG_PER_LIST + seg_idx);
> }
> + if (huge_path == NULL) {
> + EAL_LOG(DEBUG, "%s(): hugefile path truncated: '%s'",
> + __func__, path);
> + return -1;
> + }
When eal_get_hugefile_path returns NULL due to overflow, is the path
buffer in a defined state for logging purposes?
[ ... ]
next prev parent reply other threads:[~2025-12-16 16:12 UTC|newest]
Thread overview: 65+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20251205022948.327743-1-stephen@networkplumber.org>
[not found] ` <20251207191242.165619-1-stephen@networkplumber.org>
[not found] ` <20251207191242.165619-13-stephen@networkplumber.org>
2025-12-07 19:15 ` checkpatch
2025-12-16 16:12 ` 0-day Robot [this message]
[not found] ` <20251207191242.165619-12-stephen@networkplumber.org>
2025-12-07 19:16 ` |SUCCESS| pw159222 [PATCH v5 11/17] eal: limit maximum runtime directory and socket paths checkpatch
2025-12-16 16:12 ` 0-day Robot
[not found] ` <20251207191242.165619-11-stephen@networkplumber.org>
2025-12-07 19:16 ` |SUCCESS| pw159221 [PATCH v5 10/17] eal: add check for sysfs path overflow checkpatch
2025-12-16 16:12 ` |SUCCESS| pw159221 " 0-day Robot
[not found] ` <20251207191242.165619-10-stephen@networkplumber.org>
2025-12-07 19:16 ` |SUCCESS| pw159220 [PATCH v5 09/17] eal: avoid format overflow when handling addresses checkpatch
2025-12-16 16:12 ` 0-day Robot
[not found] ` <20251207191242.165619-9-stephen@networkplumber.org>
2025-12-07 19:16 ` |SUCCESS| pw159219 [PATCH v5 08/17] eal: warn if thread name is truncated checkpatch
2025-12-16 16:12 ` |SUCCESS| pw169219 " 0-day Robot
[not found] ` <20251207191242.165619-7-stephen@networkplumber.org>
2025-12-07 19:17 ` |WARNING| pw159217 [PATCH v5 06/17] telemetry: avoid possible string overflow checkpatch
2025-12-16 16:12 ` |SUCCESS| " 0-day Robot
[not found] ` <20251207191242.165619-5-stephen@networkplumber.org>
2025-12-07 19:17 ` |SUCCESS| pw159215 [PATCH v5 04/17] graph: avoid overflowing comment buffer checkpatch
2025-12-16 16:12 ` 0-day Robot
[not found] ` <20251207191242.165619-2-stephen@networkplumber.org>
2025-12-07 19:17 ` |SUCCESS| pw159212 [PATCH v5 01/17] eal: use C library to parse filesystem table checkpatch
2025-12-16 16:11 ` 0-day Robot
[not found] ` <20251207191242.165619-16-stephen@networkplumber.org>
2025-12-07 19:19 ` |SUCCESS| pw159226 [PATCH v5 15/17] ethdev: avoid possible overflow in xstat names checkpatch
2025-12-16 16:12 ` 0-day Robot
[not found] ` <20251207191242.165619-3-stephen@networkplumber.org>
2025-12-16 16:12 ` |SUCCESS| pw159213 [PATCH v5 02/17] lpm: restrict name size 0-day Robot
[not found] ` <20251207191242.165619-4-stephen@networkplumber.org>
2025-12-16 16:12 ` |SUCCESS| pw159214 [PATCH v5 03/17] hash: add checks for hash name length 0-day Robot
[not found] ` <20251207191242.165619-6-stephen@networkplumber.org>
2025-12-07 19:17 ` |SUCCESS| pw159216 [PATCH v5 05/17] latencystats: add check for string overflow checkpatch
2025-12-16 16:12 ` 0-day Robot
[not found] ` <20251207191242.165619-8-stephen@networkplumber.org>
2025-12-07 19:17 ` |SUCCESS| pw159218 [PATCH v5 07/17] efd: handle possible name truncation checkpatch
2025-12-16 16:12 ` 0-day Robot
[not found] ` <20251207191242.165619-14-stephen@networkplumber.org>
2025-12-07 19:14 ` |SUCCESS| pw159224 [PATCH v5 13/17] eal: check tailq length checkpatch
2025-12-16 16:12 ` 0-day Robot
[not found] ` <20251207191242.165619-15-stephen@networkplumber.org>
2025-12-07 19:13 ` |SUCCESS| pw159225 [PATCH v5 14/17] eal: handle long shared library path checkpatch
2025-12-16 16:12 ` 0-day Robot
[not found] ` <20251207191242.165619-17-stephen@networkplumber.org>
2025-12-07 19:19 ` |SUCCESS| pw159227 [PATCH v5 16/17] vhost: check for overflow in xstat name checkpatch
2025-12-16 16:12 ` 0-day Robot
[not found] ` <20251207191242.165619-18-stephen@networkplumber.org>
2025-12-07 18:47 ` |SUCCESS| pw159212-159228 [PATCH v5 17/17] lib: enable format overflow warnings qemudev
2025-12-07 18:54 ` |FAILURE| " qemudev
2025-12-07 19:19 ` |SUCCESS| pw159228 " checkpatch
2025-12-07 20:59 ` |FAILURE| " 0-day Robot
2025-12-08 10:39 ` |FAILURE| pw159212-159228 [PATCH] [v5,17/17] lib: enable format over dpdklab
2025-12-08 10:43 ` dpdklab
2025-12-08 10:44 ` |WARNING| " dpdklab
2025-12-08 10:45 ` |PENDING| " dpdklab
2025-12-08 10:45 ` |SUCCESS| " dpdklab
2025-12-08 10:45 ` |FAILURE| " dpdklab
2025-12-08 10:47 ` dpdklab
2025-12-08 10:47 ` |SUCCESS| " dpdklab
2025-12-08 10:48 ` |FAILURE| " dpdklab
2025-12-08 10:51 ` |WARNING| " dpdklab
2025-12-08 11:02 ` |SUCCESS| " dpdklab
2025-12-08 11:02 ` |FAILURE| " dpdklab
2025-12-08 11:03 ` |SUCCESS| " dpdklab
2025-12-08 11:12 ` dpdklab
2025-12-08 11:12 ` |FAILURE| " dpdklab
2025-12-08 11:15 ` dpdklab
2025-12-08 11:22 ` |WARNING| " dpdklab
2025-12-08 11:24 ` |FAILURE| " dpdklab
2025-12-08 14:29 ` dpdklab
2025-12-08 16:06 ` dpdklab
2025-12-10 4:01 ` dpdklab
2025-12-10 4:17 ` dpdklab
2025-12-16 1:28 ` dpdklab
2025-12-16 16:12 ` |SUCCESS| pw159228 [PATCH v5 17/17] lib: enable format overflow warnings 0-day Robot
2025-12-16 23:31 ` |SUCCESS| pw159212-159228 [PATCH] [v5,17/17] lib: enable format over dpdklab
2025-12-16 23:38 ` |WARNING| " dpdklab
2025-12-16 23:39 ` |SUCCESS| " dpdklab
2025-12-16 23:43 ` |FAILURE| " dpdklab
2025-12-16 23:49 ` |SUCCESS| " dpdklab
2025-12-16 23:59 ` |FAILURE| " dpdklab
2025-12-17 0:09 ` |WARNING| " dpdklab
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=20251216161223.762587-1-robot@bytheb.org \
--to=robot@bytheb.org \
--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;
as well as URLs for NNTP newsgroup(s).