From: "Lorenzo Stoakes (ARM)" <ljs@kernel.org>
To: Vernon Yang <vernon2gm@gmail.com>
Cc: akpm@linux-foundation.org, david@kernel.org,
nico.pache@linux.dev, ryan.roberts@arm.com, dev.jain@arm.com,
baohua@kernel.org, lance.yang@linux.dev, usama.arif@linux.dev,
zokeefe@google.com, linux-kernel@vger.kernel.org,
linux-mm@kvack.org, Vernon Yang <yanglincheng@kylinos.cn>,
stable@vger.kernel.org
Subject: Re: [PATCH v2 2/3] mm: khugepaged: fix folio is used after pte_unmap_unlock()
Date: Mon, 17 Aug 2026 17:11:56 +0100 [thread overview]
Message-ID: <aoMynfFI2XK2UXXN@lucifer> (raw)
In-Reply-To: <20260815051924.194810-3-vernon2gm@gmail.com>
On Sat, Aug 15, 2026 at 01:19:23PM +0800, Vernon Yang wrote:
> From: Vernon Yang <yanglincheng@kylinos.cn>
>
> After the page table lock has dropped, the folio can be freed
> concurrently. The trace_mm_khugepaged_scan_pmd() is left with
> a dangling folio pointer.
>
> So using the folio_pfn() before dropping the page table lock,
> closing use-after-free window.
>
> Fixes: 7d2eba0557c1 ("mm: add tracepoint for scanning pages")
> Cc: stable@vger.kernel.org
> Signed-off-by: Vernon Yang <yanglincheng@kylinos.cn>
> ---
> include/trace/events/huge_memory.h | 6 +++---
> mm/khugepaged.c | 4 +++-
> 2 files changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/include/trace/events/huge_memory.h b/include/trace/events/huge_memory.h
> index d3572d4ef453..5dc71d292f47 100644
> --- a/include/trace/events/huge_memory.h
> +++ b/include/trace/events/huge_memory.h
> @@ -55,10 +55,10 @@ SCAN_STATUS
>
> TRACE_EVENT(mm_khugepaged_scan_pmd,
>
> - TP_PROTO(struct mm_struct *mm, struct folio *folio,
> + TP_PROTO(struct mm_struct *mm, unsigned long pfn,
> int referenced, int none_or_zero, int status, int unmapped),
>
> - TP_ARGS(mm, folio, referenced, none_or_zero, status, unmapped),
> + TP_ARGS(mm, pfn, referenced, none_or_zero, status, unmapped),
>
> TP_STRUCT__entry(
> __field(struct mm_struct *, mm)
> @@ -71,7 +71,7 @@ TRACE_EVENT(mm_khugepaged_scan_pmd,
>
> TP_fast_assign(
> __entry->mm = mm;
> - __entry->pfn = folio ? folio_pfn(folio) : -1;
> + __entry->pfn = pfn;
> __entry->referenced = referenced;
> __entry->none_or_zero = none_or_zero;
> __entry->status = status;
> diff --git a/mm/khugepaged.c b/mm/khugepaged.c
> index e7830761d3a2..7c8c48577408 100644
> --- a/mm/khugepaged.c
> +++ b/mm/khugepaged.c
> @@ -1603,6 +1603,7 @@ static enum scan_result collapse_scan_pmd(struct mm_struct *mm,
> enum scan_result result = SCAN_FAIL;
> struct page *page = NULL;
> struct folio *folio = NULL;
> + unsigned long pfn = -1;
> unsigned long addr;
> unsigned long enabled_orders;
> spinlock_t *ptl;
> @@ -1778,6 +1779,7 @@ static enum scan_result collapse_scan_pmd(struct mm_struct *mm,
> result = SCAN_SUCCEED;
> }
> out_unmap:
> + pfn = folio ? folio_pfn(folio) : -1;
> pte_unmap_unlock(pte, ptl);
> if (result == SCAN_SUCCEED) {
> /* collapse_huge_page expects the lock to be dropped before calling */
> @@ -1788,7 +1790,7 @@ static enum scan_result collapse_scan_pmd(struct mm_struct *mm,
> *lock_dropped = true;
> }
> out:
> - trace_mm_khugepaged_scan_pmd(mm, folio, referenced,
> + trace_mm_khugepaged_scan_pmd(mm, pfn, referenced,
Same comment as 1/3 I don't see why we should be storing a pfn value used
nowhere else just for tracing.
> none_or_zero, result, unmapped);
> return result;
> }
> --
> 2.53.0
>
--
Cheers, Lorenzo
next prev parent reply other threads:[~2026-08-17 16:12 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-15 5:19 [PATCH v2 0/3] mm: khugepaged: fix tracepoint UAF Vernon Yang
2026-08-15 5:19 ` [PATCH v2 1/3] mm: khugepaged: fix swap entry value to folio_pfn() Vernon Yang
2026-08-17 16:10 ` Lorenzo Stoakes (ARM)
2026-08-17 16:19 ` David Hildenbrand (Arm)
2026-08-17 16:24 ` Lorenzo Stoakes (ARM)
2026-08-17 16:23 ` Lorenzo Stoakes (ARM)
2026-08-15 5:19 ` [PATCH v2 2/3] mm: khugepaged: fix folio is used after pte_unmap_unlock() Vernon Yang
2026-08-17 16:11 ` Lorenzo Stoakes (ARM) [this message]
2026-08-17 16:20 ` David Hildenbrand (Arm)
2026-08-17 16:29 ` Lorenzo Stoakes (ARM)
2026-08-17 16:33 ` Lorenzo Stoakes
2026-08-15 5:19 ` [PATCH v2 3/3] mm: khugepaged: fix folio is used after folio_put/unlock() Vernon Yang
2026-08-15 17:44 ` [PATCH v2 0/3] mm: khugepaged: fix tracepoint UAF Lance Yang
2026-08-15 18:16 ` Lance Yang
2026-08-17 2:25 ` Baolin Wang
2026-08-17 2:53 ` Lance Yang
2026-08-17 7:24 ` Baolin Wang
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=aoMynfFI2XK2UXXN@lucifer \
--to=ljs@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=baohua@kernel.org \
--cc=david@kernel.org \
--cc=dev.jain@arm.com \
--cc=lance.yang@linux.dev \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=nico.pache@linux.dev \
--cc=ryan.roberts@arm.com \
--cc=stable@vger.kernel.org \
--cc=usama.arif@linux.dev \
--cc=vernon2gm@gmail.com \
--cc=yanglincheng@kylinos.cn \
--cc=zokeefe@google.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.