automatic DPDK test reports
 help / color / mirror / Atom feed
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?

[ ... ]

  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).