linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: YoungJun Park <youngjun.park@lge.com>
To: Deepanshu Kartikey <kartikey406@gmail.com>
Cc: akpm@linux-foundation.org, chrisl@kernel.org, kasong@tencent.com,
	shikemeng@huaweicloud.com, nphamcs@gmail.com, bhe@redhat.com,
	baohua@kernel.org, linux-mm@kvack.org,
	linux-kernel@vger.kernel.org,
	syzbot+d7bc9ec4a100437aa7a2@syzkaller.appspotmail.com
Subject: Re: [PATCH] mm/swapfile: validate swap offset in unuse_pte_range()
Date: Mon, 1 Dec 2025 19:27:46 +0900	[thread overview]
Message-ID: <aS1tojIUgou6eGCh@yjaykim-PowerEdge-T330> (raw)
In-Reply-To: <20251201093741.730884-1-kartikey406@gmail.com>

On Mon, Dec 01, 2025 at 03:07:41PM +0530, Deepanshu Kartikey wrote:
> syzbot reported a WARNING in __swap_offset_to_cluster() triggered by
> an invalid swap offset during swapoff:
> 
>   WARNING: CPU: 0 PID: 9861 at mm/swap.h:87 swap_cache_get_folio+0x186/0x200
> 
> The issue occurs because unuse_pte_range() extracts a swap entry from
> a PTE and uses the offset without validating it is within bounds of
> the swap area.
> 
> While the existing swp_type() check filters entries for other swap
> areas, it cannot catch cases where the type bits are valid but the
> offset is corrupted or stale - for example, due to a race condition
> during PTE updates or memory corruption.

Since this indicates a system-level issue (race/corruption), simply
avoiding the crash seems to be the goal here.
Should we at least add a WARN_ON or somthing? 
(Unless this corruption is expected 
to be reported elsewhere beforehand, in which case a silent skip is
fine as I think)

And it looks like swap_vma_readahead() share similar logic. 
The differene is intentionally allow entries from different swap
devices (to support vma readahead). 

If the offset is corrupted or invalid in those paths, wouldn't they
suffer from similar issues? Do you think we should add the boundary
check (offset >= si->max) there as well?

Best Regards,
Youngjun Park

> 
> Reported-by: syzbot+d7bc9ec4a100437aa7a2@syzkaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?extid=d7bc9ec4a100437aa7a2
> Signed-off-by: Deepanshu Kartikey <kartikey406@gmail.com>
> ---
>  mm/swapfile.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/mm/swapfile.c b/mm/swapfile.c
> index 46d2008e4b99..fdf358df7116 100644
> --- a/mm/swapfile.c
> +++ b/mm/swapfile.c
> @@ -2277,6 +2277,8 @@ static int unuse_pte_range(struct vm_area_struct *vma, pmd_t *pmd,
>  			continue;
>  
>  		offset = swp_offset(entry);
> +		if (offset >= si->max)
> +			continue;
>  		pte_unmap(pte);
>  		pte = NULL;
>  
> -- 
> 2.43.0


  reply	other threads:[~2025-12-01 10:27 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-12-01  9:37 Deepanshu Kartikey
2025-12-01 10:27 ` YoungJun Park [this message]
2025-12-01 10:40 ` Kairui Song
2025-12-01 10:48   ` Deepanshu Kartikey
2025-12-03  2:53     ` Kairui Song
2025-12-06 12:28       ` Deepanshu Kartikey
2025-12-07  6:32         ` Chris Li

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=aS1tojIUgou6eGCh@yjaykim-PowerEdge-T330 \
    --to=youngjun.park@lge.com \
    --cc=akpm@linux-foundation.org \
    --cc=baohua@kernel.org \
    --cc=bhe@redhat.com \
    --cc=chrisl@kernel.org \
    --cc=kartikey406@gmail.com \
    --cc=kasong@tencent.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=nphamcs@gmail.com \
    --cc=shikemeng@huaweicloud.com \
    --cc=syzbot+d7bc9ec4a100437aa7a2@syzkaller.appspotmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox