| Message ID | 20240807173336.2523757-2-pedro.falcato@gmail.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | mseal: Fix is_madv_discard() | expand |
On Wed, 7 Aug 2024 18:33:35 +0100 Pedro Falcato <pedro.falcato@gmail.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?
On Wed, Aug 7, 2024 at 7:58 PM Andrew Morton <akpm@linux-foundation.org> wrote: > > On Wed, 7 Aug 2024 18:33:35 +0100 Pedro Falcato <pedro.falcato@gmail.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, Pedro
On Wed, 7 Aug 2024 20:25:45 +0100 Pedro Falcato <pedro.falcato@gmail.com> wrote: > On Wed, Aug 7, 2024 at 7:58 PM Andrew Morton <akpm@linux-foundation.org> wrote: > > > > On Wed, 7 Aug 2024 18:33:35 +0100 Pedro Falcato <pedro.falcato@gmail.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.
diff --git a/mm/mseal.c b/mm/mseal.c index bf783bba8ed..15bba28acc0 100644 --- a/mm/mseal.c +++ b/mm/mseal.c @@ -40,9 +40,17 @@ static bool can_modify_vma(struct vm_area_struct *vma) static bool is_madv_discard(int behavior) { - return behavior & - (MADV_FREE | MADV_DONTNEED | MADV_DONTNEED_LOCKED | - MADV_REMOVE | MADV_DONTFORK | MADV_WIPEONFORK); + switch (behavior) { + case MADV_FREE: + case MADV_DONTNEED: + case MADV_DONTNEED_LOCKED: + case MADV_REMOVE: + case MADV_DONTFORK: + case MADV_WIPEONFORK: + return true; + } + + return false; } static bool is_ro_anon(struct vm_area_struct *vma)
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. Cc: stable@vger.kernel.org Fixes: 8be7258aad44 ("mseal: add mseal syscall") Signed-off-by: Pedro Falcato <pedro.falcato@gmail.com> --- mm/mseal.c | 14 +++++++++++--- 1 file changed, 11 insertions(+), 3 deletions(-)