[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20240807123153.227390ebb7c6dff911b5fddf@linux-foundation.org>
Date: Wed, 7 Aug 2024 12:31:53 -0700
From: Andrew Morton <akpm@...ux-foundation.org>
To: Pedro Falcato <pedro.falcato@...il.com>
Cc: Shuah Khan <shuah@...nel.org>, "Liam R. Howlett"
<Liam.Howlett@...cle.com>, Jeff Xu <jeffxu@...omium.org>, Kees Cook
<kees@...nel.org>, linux-mm@...ck.org, linux-kernel@...r.kernel.org,
linux-kselftest@...r.kernel.org, stable@...r.kernel.org
Subject: Re: [PATCH 1/2] mseal: Fix is_madv_discard()
On Wed, 7 Aug 2024 20:25:45 +0100 Pedro Falcato <pedro.falcato@...il.com> wrote:
> On Wed, Aug 7, 2024 at 7:58 PM Andrew Morton <akpm@...ux-foundation.org> wrote:
> >
> > On Wed, 7 Aug 2024 18:33:35 +0100 Pedro Falcato <pedro.falcato@...il.com> wrote:
> >
> > > is_madv_discard did its check wrong. MADV_ flags are not bitwise,
> > > they're normal sequential numbers. So, for instance:
> > > behavior & (/* ... */ | MADV_REMOVE)
> > >
> > > tagged both MADV_REMOVE and MADV_RANDOM (bit 0 set) as
> > > discard operations. This is obviously incorrect, so use
> > > a switch statement instead.
> >
> > Please describe the userspace-visible runtime effects of this bug?
>
> The kernel could erroneously block certain madvises (e.g MADV_RANDOM
> or MADV_HUGEPAGE) on sealed VMAs due to them sharing bits with blocked
> MADV operations (e.g REMOVE or WIPEONFORK).
Thanks, I updated the changelog.
Powered by blists - more mailing lists