scripts/tracepoint-update.c | 2 ++ 1 file changed, 2 insertions(+)
When realloc() fails in add_string(), the function returns -1 but leaves
*vals pointing to the previously allocated memory. This can cause memory
leaks in callers like make_trace_array() that return on error without
freeing the partially built array.
Fix this by freeing *vals and setting it to NULL when realloc() fails.
This makes the error handling self-contained in add_string() so callers
don't need to handle cleanup on failure.
This bug is found by my static analysis tool and my code review.
Signed-off-by: Weigang He <geoffreyhe2@gmail.com>
---
scripts/tracepoint-update.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/scripts/tracepoint-update.c b/scripts/tracepoint-update.c
index 90046aedc97b9..5cf43c0aac891 100644
--- a/scripts/tracepoint-update.c
+++ b/scripts/tracepoint-update.c
@@ -49,6 +49,8 @@ static int add_string(const char *str, const char ***vals, int *count)
array = realloc(array, sizeof(char *) * size);
if (!array) {
fprintf(stderr, "Failed memory allocation\n");
+ free(*vals);
+ *vals = NULL;
return -1;
}
*vals = array;
--
2.34.1
On Mon, 19 Jan 2026 11:45:42 +0000
Weigang He <geoffreyhe2@gmail.com> wrote:
> When realloc() fails in add_string(), the function returns -1 but leaves
> *vals pointing to the previously allocated memory. This can cause memory
> leaks in callers like make_trace_array() that return on error without
> freeing the partially built array.
>
> Fix this by freeing *vals and setting it to NULL when realloc() fails.
> This makes the error handling self-contained in add_string() so callers
> don't need to handle cleanup on failure.
This looks not enough. If the memory allocation is failed, it should NOT
continue anything.
I think we need to make the command itself failure when it fails to
allocate memory, as below:
diff --git a/scripts/tracepoint-update.c b/scripts/tracepoint-update.c
index 90046aedc97b..1b4129a21942 100644
--- a/scripts/tracepoint-update.c
+++ b/scripts/tracepoint-update.c
@@ -94,7 +94,7 @@ static void make_trace_array(struct elf_tracepoint *etrace)
if (!len)
continue;
if (add_string(str, &vals, &count) < 0)
- return;
+ exit(EXIT_FAILURE);
}
/* If CONFIG_TRACEPOINT_VERIFY_USED is not set, there's nothing to do */
Thank you,
>
> This bug is found by my static analysis tool and my code review.
>
> Signed-off-by: Weigang He <geoffreyhe2@gmail.com>
> ---
> scripts/tracepoint-update.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/scripts/tracepoint-update.c b/scripts/tracepoint-update.c
> index 90046aedc97b9..5cf43c0aac891 100644
> --- a/scripts/tracepoint-update.c
> +++ b/scripts/tracepoint-update.c
> @@ -49,6 +49,8 @@ static int add_string(const char *str, const char ***vals, int *count)
> array = realloc(array, sizeof(char *) * size);
> if (!array) {
> fprintf(stderr, "Failed memory allocation\n");
> + free(*vals);
> + *vals = NULL;
> return -1;
> }
> *vals = array;
> --
> 2.34.1
>
--
Masami Hiramatsu (Google) <mhiramat@kernel.org>
On Wed, 21 Jan 2026 11:22:53 +0900 Masami Hiramatsu (Google) <mhiramat@kernel.org> wrote: > > > > Fix this by freeing *vals and setting it to NULL when realloc() fails. > > This makes the error handling self-contained in add_string() so callers > > don't need to handle cleanup on failure. > > This looks not enough. If the memory allocation is failed, it should NOT > continue anything. > > I think we need to make the command itself failure when it fails to > allocate memory, as below: That's a separate bug. I'm taking this current patch as-is as a fix for the leak. Not stopping immediately is a separate issue. -- Steve
… > This bug is found by my static analysis tool … Will any additional background information become more helpful here? > --- > scripts/tracepoint-update.c | 2 ++ … Some contributors would appreciate patch version descriptions. https://lore.kernel.org/all/?q=%22This+looks+like+a+new+version+of+a+previously+submitted+patch%22 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst?h=v6.19-rc6#n310 Regards, Markus
© 2016 - 2026 Red Hat, Inc.