linux-kernel - Re: [PATCH] mm/swapfile: validate swap offset in unuse_pte

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CACePvbVOPBW64FNjaf5+sjWM9Y4BgzkHyB5NcWG7G-kUhEOpAg@mail.gmail.com>
Date: Sun, 7 Dec 2025 10:32:14 +0400
From: Chris Li <chrisl@...nel.org>
To: Deepanshu Kartikey <kartikey406@...il.com>
Cc: Kairui Song <ryncsn@...il.com>, akpm@...ux-foundation.org, shikemeng@...weicloud.com, 
	nphamcs@...il.com, bhe@...hat.com, baohua@...nel.org, linux-mm@...ck.org, 
	linux-kernel@...r.kernel.org, YoungJun Park <youngjun.park@....com>, 
	syzbot+d7bc9ec4a100437aa7a2@...kaller.appspotmail.com
Subject: Re: [PATCH] mm/swapfile: validate swap offset in unuse_pte_range()

On Sat, Dec 6, 2025 at 4:28 PM Deepanshu Kartikey <kartikey406@...il.com> wrote:
>
> On Wed, Dec 3, 2025 at 8:24 AM Kairui Song <ryncsn@...il.com> wrote:
> > > If softleaf v3 has fixed the underlying issue, I can withdraw this
> > > patch. Or if you think a defensive sanity check still has value, I can
> > > update the commit message to reflect that it is defensive hardening
> > > rather than a fix for an active bug.
> >
> > A sanity check here is acceptable since swapoff is cold and the
> > overhead is hardly visible. No strong opinion on this one.
>
> Hi Kairui,
>
> Thank you for the link and clarification!

Thanks for working on this.

>
> I'll study Lorenzo's fix to understand the root cause better.
>
> Since you mentioned a sanity check is acceptable here, should I update
> the commit message to frame this as defensive hardening rather than a
> bug fix? Something like:
>
>     mm/swapfile: add defensive bounds check in unuse_pte_range()
>
>     Add a sanity check to validate the swap offset is within bounds
>     before using it. While there is no known code path that can
>     trigger an out-of-bounds offset, this provides defense against
>     potential edge cases or memory corruption.

Adding a defensive hardening is justified. Basically, the kernel
shouldn't put an invalid swap entry in the pte. If the swap entry read
back from the pte is invalid (out of range). That means there is some
kind of bug that might be able to cause data corruption. Bail out and
add a WARN_ONCE or the preferred equivalent version if triggered to
expose the possible data corruption.

I understand there is some opinion about avoiding using WARN. I will
leave other comments on what is the best way to notify the possible
data corruption. Because it is possible data corruption we are talking
about,  silently skipping over the possible data corruption bug is
worse.

That is just my take on this.

>
>     The overhead is negligible since swapoff is a cold path.

Ack.

Chris