From: Heiko Carstens <hca@linux.ibm.com>
To: Miaoqian Lin <linmq006@gmail.com>
Cc: Alexander Gordeev <agordeev@linux.ibm.com>,
Gerald Schaefer <gerald.schaefer@linux.ibm.com>,
Vasily Gorbik <gor@linux.ibm.com>,
Christian Borntraeger <borntraeger@linux.ibm.com>,
Sven Schnelle <svens@linux.ibm.com>,
linux-s390@vger.kernel.org, linux-kernel@vger.kernel.org,
bpf@vger.kernel.org, stable@vger.kernel.org
Subject: Re: [PATCH] s390/mm: Fix memory leak in add_marker() when kvrealloc fails
Date: Mon, 27 Oct 2025 11:14:51 +0100 [thread overview]
Message-ID: <20251027101451.14551A49-hca@linux.ibm.com> (raw)
In-Reply-To: <20251026091351.36275-1-linmq006@gmail.com>
On Sun, Oct 26, 2025 at 05:13:51PM +0800, Miaoqian Lin wrote:
> When kvrealloc() fails, the original markers memory is leaked
> because the function directly assigns the NULL to the markers pointer,
> losing the reference to the original memory.
>
> As a result, the kvfree() in pt_dump_init() ends up freeing NULL instead
> of the previously allocated memory.
>
> Fix this by using a temporary variable to store kvrealloc()'s return
> value and only update the markers pointer on success.
>
> Found via static anlaysis and this is similar to commit 42378a9ca553
> ("bpf, verifier: Fix memory leak in array reallocation for stack state")
>
> Fixes: d0e7915d2ad3 ("s390/mm/ptdump: Generate address marker array dynamically")
> Cc: stable@vger.kernel.org
> Signed-off-by: Miaoqian Lin <linmq006@gmail.com>
> ---
> arch/s390/mm/dump_pagetables.c | 9 ++++++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/arch/s390/mm/dump_pagetables.c b/arch/s390/mm/dump_pagetables.c
> index 9af2aae0a515..0f2e0c93a1e0 100644
> --- a/arch/s390/mm/dump_pagetables.c
> +++ b/arch/s390/mm/dump_pagetables.c
> @@ -291,16 +291,19 @@ static int ptdump_cmp(const void *a, const void *b)
>
> static int add_marker(unsigned long start, unsigned long end, const char *name)
> {
> + struct addr_marker *new_markers;
> size_t oldsize, newsize;
>
> oldsize = markers_cnt * sizeof(*markers);
> newsize = oldsize + 2 * sizeof(*markers);
> if (!oldsize)
> - markers = kvmalloc(newsize, GFP_KERNEL);
> + new_markers = kvmalloc(newsize, GFP_KERNEL);
> else
> - markers = kvrealloc(markers, newsize, GFP_KERNEL);
> - if (!markers)
> + new_markers = kvrealloc(markers, newsize, GFP_KERNEL);
> + if (!new_markers)
> goto error;
> +
> + markers = new_markers;
This is not better to the situation before. If the allocation fails,
markers_cnt will be set to zero, but the old valid markers pointer will stay,
which means that the next call to add_marker() will allocate a new area via
kvmalloc() instead of kvrealloc(), and thus leaking the old area too.
add_marker() needs to changes to return in a manner that both marker and
marker_cnt correlate with each other. And I guess it is also easily possible
to get rid of the two different allocation paths.
Care to send a new version?
next prev parent reply other threads:[~2025-10-27 10:15 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-26 9:13 [PATCH] s390/mm: Fix memory leak in add_marker() when kvrealloc fails Miaoqian Lin
2025-10-27 10:14 ` Heiko Carstens [this message]
2025-10-27 11:53 ` 林妙倩
2025-10-27 12:31 ` Heiko Carstens
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=20251027101451.14551A49-hca@linux.ibm.com \
--to=hca@linux.ibm.com \
--cc=agordeev@linux.ibm.com \
--cc=borntraeger@linux.ibm.com \
--cc=bpf@vger.kernel.org \
--cc=gerald.schaefer@linux.ibm.com \
--cc=gor@linux.ibm.com \
--cc=linmq006@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=stable@vger.kernel.org \
--cc=svens@linux.ibm.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.