From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 613B94705A for ; Tue, 16 Dec 2025 17:12:29 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 4FA7A4042F; Tue, 16 Dec 2025 17:12:29 +0100 (CET) Received: from mail-qt1-f175.google.com (mail-qt1-f175.google.com [209.85.160.175]) by mails.dpdk.org (Postfix) with ESMTP id 4893A4026D for ; Tue, 16 Dec 2025 17:12:27 +0100 (CET) Received: by mail-qt1-f175.google.com with SMTP id d75a77b69052e-4ee14ba3d9cso47676331cf.1 for ; Tue, 16 Dec 2025 08:12:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bytheb-org.20230601.gappssmtp.com; s=20230601; t=1765901546; x=1766506346; darn=dpdk.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:to:from:from:to:cc:subject:date:message-id :reply-to; bh=UISbYygE0c8WuMuQa6B7TG4As3/nwVYEsb3mAkm64UI=; b=m+zTNdMzygJlyOvWtlGp95pQeMIck/AVQpehWwmYVVC1HkmJGXtAUEDjUA96IBuig7 RdUPu7PW6OEpJwG0dfe2bcgNYmuBFgX7V40ydexDGWKvGdCwp4a5NWAMsVMli4SiOG70 LkVL8+2/B+VhH310t56a/sSUiHChFmMmlrf4PA82ifCBMsIbI2Shg0trOurmESrUwnyG glB5J7eS5flJcUUMMbF+4n+zsAM0hKvvN85v41O21TzTr9WDjhOW+5KuiMQyP0DH3OOw nS1vFxbQxdLYDTNnUWt6VJWeDEKa0SSH2yEvJc14n5ifAwyLCvS0e07OE4+D5v0hqwU7 EhtA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1765901546; x=1766506346; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:to:from:x-gm-gg:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=UISbYygE0c8WuMuQa6B7TG4As3/nwVYEsb3mAkm64UI=; b=kSUiNAG8OPUqYxVTKpKZtLTEwL4fRU59ZEtGzRi8yTUUYTwkd3djwjNNtHuGH5fH3G gqn5hbbTIg5KyOpLRLJJVXcpu1m6BSdhtQDbzukRYjN8BHnSOid8ycZUBzjQaQSpgKKq BNVA+iP1ml9G7ZsOfHSP4mHQQYrMuj+EFmO5CkAzeGiALCvccst0uCEWXETaQY+kbHhG aFnTGtfMfZcQtGKkDGEJXU5H3fX5LGZgbikby899YUsicwY4CZVTLXlKyYEiwyds9vu7 etETMWC2YYeGYdI9a7rOUkUx7uE/iguQ/WMaipz35d9KwHYszK472lyA4T1RzZD4JOBU iGrA== X-Gm-Message-State: AOJu0Yzi+Sw0rS+7LiPtTAZfzHVhx1EJw3P2AutgJ28BwZhdYXMkcTXZ +bn3yQiZnrle/9gMOF9YYL5lzaub0R9I75xw0LeJgk4/h3wY27cDQcwXzVpD4Faq7WSjvsyRlz/ NtO8N X-Gm-Gg: AY/fxX6QXV9BM6EfTOxm0mTYrEQ2x/dbp5UZFJQ3lKu8nJ4E+mhA1qXdmXPIbQiLf+r 07OfryJZoIZR1Y+w3GlqmMOfA6kn/q3hKF4gDWt8wTg8/FHjQS25xKd1RjVuR04+CTEnxMQnGIy umovhoMYZOwh+N0tByyWf7S9CE9HMSuSzALdAc3Q7NS+p7F5rjOVVmR20jXbUkvwSxtRyqfByLk VhQNXd1B+AFyzlBr89iF5/hPhnfjvlbkDvWfETv9XiPnF+NHwJR1+SJckOvYjHFGBEXEdLzdE17 erZSY30gOcycq7IQnxOuj6/3ZZSr0wUi/6MIvD/myzMUNT/FGMIN2zFhW7NMJiF5Uxy2k3sSYBB 2Ug4Rhwr151bY5PHdZfikHyhhQEnIAiNqBmQlwI8uEnKA0AXvksFLt60BmMPJ/WsLWS1PwyU+FA pS7rP2BXrlirsEsdDDiA== X-Google-Smtp-Source: AGHT+IHH0tJF3fCyRaKZS2z50crqNP3hJ3QOkkGE/PFeb3cHYk7aNuqjSjN4vRp8ygliZ9WvsndUCw== X-Received: by 2002:a05:622a:110e:b0:4ed:b570:2d4c with SMTP id d75a77b69052e-4f1d059d4a9mr204407861cf.43.1765901545785; Tue, 16 Dec 2025 08:12:25 -0800 (PST) Received: from RHTRH0061144.redhat.com ([47.14.5.10]) by smtp.gmail.com with ESMTPSA id d75a77b69052e-4f345c5b73asm18401541cf.29.2025.12.16.08.12.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 16 Dec 2025 08:12:25 -0800 (PST) From: 0-day Robot To: test-report@dpdk.org, Stephen Hemminger Subject: |SUCCESS| pw159223 [PATCH v5 12/17] eal: check for hugefile path overflow Date: Tue, 16 Dec 2025 11:12:23 -0500 Message-ID: <20251216161223.762587-1-robot@bytheb.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20251207191242.165619-13-stephen@networkplumber.org> References: <20251205022948.327743-1-stephen@networkplumber.org> <20251207191242.165619-1-stephen@networkplumber.org> <20251207191242.165619-13-stephen@networkplumber.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: test-report@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: automatic DPDK test reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: test-report-bounces@dpdk.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 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? [ ... ]