From: sashiko-bot@kernel.org
To: "Hamid Nassiby" <hamid.nassiby@nokia.com>
Cc: "Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
"Sasha Levin" <sashal@kernel.org>,
"Ran Xiaokai" <ran.xiaokai@zte.com.cn>,
ranxiaokai627@163.com,
"Andrew Morton" <akpm@linux-foundation.org>,
"Vlastimil Babka" <vbabka@suse.cz>,
"Michal Hocko" <mhocko@suse.com>,
"Oscar Salvador" <osalvador@suse.de>,
"Mauricio Faria de Oliveira" <mfo@igalia.com>,
linux-mm@kvack.org
Subject: Re: [PATCH 6.18.y] Revert "mm/page_owner: fix memory leak in page_owner_stack_fops->release()"
Date: Tue, 10 Nov 2026 14:16:04 +0000 [thread overview]
Message-ID: <sashiko-outbox-207182@kernel.org> (raw)
In-Reply-To: <20261109141527.2880867-1-hamid.nassiby@nokia.com>
Thank you for your contribution! Sashiko AI review found 1 potential
issue to consider:
- [Low] mm/page_owner: missing Fixes trailer for commit 05a8edf607be
--
commit 9eb622d1a73d326e41d0bbcc302c141ec9c886ab
Author: Hamid Nassiby <hamid.nassiby@nokia.com>
> Revert "mm/page_owner: fix memory leak in page_owner_stack_fops->release()"
>
> This reverts commit 05a8edf607be826738dfc620a17d9d98e8976762, which is
> commit a76a5ae2c6c6 upstream.
>
> The upstream change is only correct on top of commit 156c0c5d1463
> ("mm/page_owner: introduce struct stack_print_ctx"), which first appeared
> in v6.19. That commit makes page_owner_stack_open() allocate a struct
> stack_print_ctx through seq_open_private() and moves the stack_list
> cursor into it, so ->release() must free it with seq_release_private().
> 6.18 does not have that commit: page_owner_stack_open() passes a size of 0
> to seq_open_private(), so there is nothing to leak, and
> stack_start()/stack_next() store the current struct stack node directly
> in m->private.
>
> The upstream commit was backported because it is tagged for stable and
> carries a Fixes tag for 765973a09803 ("mm,page_owner: display all stacks
> and their count"), but the leak it fixes only exists since 156c0c5d1463.
>
> seq_release_private() kfree()s m->private. Closing show_stacks before
> EOF therefore frees a struct stack node that is still linked in
> stack_list, and the next reader of show_stacks walks into freed memory.
> On v6.18.60 (x86_64 QEMU, KASAN, page_owner=on), a single 4 KiB read()
> and close() followed by a full read gives:
>
> BUG: KASAN: slab-use-after-free in stack_print+0x165/0x170
> Read of size 8 at addr ff110000062adfc0 by task init/1
> ...
> Allocated by task 1:
> __kasan_kmalloc+0x7f/0x90
> __set_page_owner+0x4a5/0x720
> ...
> Freed by task 1:
> kfree+0xf8/0x460
> seq_release_private+0x58/0x110
> full_proxy_release+0xa1/0x130
> __fput+0x35c/0xac0
> __x64_sys_close+0x79/0xd0
> ...
> The buggy address belongs to the object at ff110000062adfc0
> which belongs to the cache kmalloc-16 of size 16
>
> Without KASAN, the same bug panics arm64 hardware running a
> 6.12.108-based kernel ("head -12 show_stacks; cat show_stacks").
>
> With this revert applied, the QEMU reproducer completes 20
> partial-read/full-read cycles without a KASAN report. mm/page_owner.c is
> unchanged between v6.18.60 and v6.18.62.
>
> Backporting 156c0c5d1463 instead is not proposed: it prepares for the
> new show_handles and show_stacks_handles debugfs files rather than
> fixing anything, so reverting the backport is the minimal change for
> stable.
>
> Link: https://lore.kernel.org/stable/20260106170556.173097317@linuxfoundation.org/
> Signed-off-by: Hamid Nassiby <hamid.nassiby@nokia.com>
[Severity: Low]
Should this revert include a Fixes tag for the backported commit that
introduced the slab-use-after-free:
Fixes: 05a8edf607be ("mm/page_owner: fix memory leak in page_owner_stack_fops->release()")
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261109141527.2880867-1-hamid.nassiby@nokia.com?part=1
next prev parent reply other threads:[~2026-11-10 14:16 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-09 14:15 [PATCH 6.18.y] Revert "mm/page_owner: fix memory leak in page_owner_stack_fops->release()" Hamid Nassiby
2026-11-09 19:36 ` Mauricio Faria de Oliveira
2026-11-10 14:16 ` sashiko-bot [this message]
2026-11-10 20:59 ` Sasha Levin
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=sashiko-outbox-207182@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=gregkh@linuxfoundation.org \
--cc=hamid.nassiby@nokia.com \
--cc=linux-mm@kvack.org \
--cc=mfo@igalia.com \
--cc=mhocko@suse.com \
--cc=osalvador@suse.de \
--cc=ran.xiaokai@zte.com.cn \
--cc=ranxiaokai627@163.com \
--cc=sashal@kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
--cc=vbabka@suse.cz \
/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.