[v4,0/3] Actually fix freelist pointer vs redzoning

Message

Kees Cook June 8, 2021, 6:39 p.m. UTC

v4:
- remove redundant size check
v3: https://lore.kernel.org/lkml/[e-mail]
v2: https://lore.kernel.org/lkml/[e-mail]
v1: https://lore.kernel.org/lkml/[e-mail]

This fixes redzoning vs the freelist pointer (both for middle-position
and very small caches). Both are "theoretical" fixes, in that I see no
evidence of such small-sized caches actually be used in the kernel, but
that's no reason to let the bugs continue to exist, especially since
people doing local development keep tripping over it. :)

Thanks!

-Kees


Kees Cook (3):
  mm/slub: Clarify verification reporting
  mm/slub: Fix redzoning for small allocations
  mm/slub: Actually fix freelist pointer vs redzoning

 Documentation/vm/slub.rst | 10 +++++-----
 mm/slab_common.c          |  3 +--
 mm/slub.c                 | 36 +++++++++++++++---------------------
 3 files changed, 21 insertions(+), 28 deletions(-)

Comments

Andrew Morton June 8, 2021, 8:53 p.m. UTC | #1

On Tue,  8 Jun 2021 11:39:52 -0700 Kees Cook <[e-mail]> wrote:

> This fixes redzoning vs the freelist pointer (both for middle-position
> and very small caches). Both are "theoretical" fixes, in that I see no
> evidence of such small-sized caches actually be used in the kernel, but
> that's no reason to let the bugs continue to exist, especially since
> people doing local development keep tripping over it. :)

So I don't think this is suitable -stable material?

It's a bit odd that patches 2&3 were cc:stable but #1 was not.  Makes
one afraid that 2&3 might have had a dependency anyway.

So I'm thinking that the whole series can just be for 5.14-rc1, in the
sent order.

Kees Cook June 8, 2021, 11:08 p.m. UTC | #2

On Tue, Jun 08, 2021 at 01:53:27PM -0700, Andrew Morton wrote:
> On Tue,  8 Jun 2021 11:39:52 -0700 Kees Cook <[e-mail]> wrote:
> 
> > This fixes redzoning vs the freelist pointer (both for middle-position
> > and very small caches). Both are "theoretical" fixes, in that I see no
> > evidence of such small-sized caches actually be used in the kernel, but
> > that's no reason to let the bugs continue to exist, especially since
> > people doing local development keep tripping over it. :)
> 
> So I don't think this is suitable -stable material?

Yeah, I think it's -stable material, but I'd like some bake time in
-next just in case. zplin saw that there was a 2 * sizeof(void *) case
that existed in the kernel that would trip over the issue.

> It's a bit odd that patches 2&3 were cc:stable but #1 was not.  Makes
> one afraid that 2&3 might have had a dependency anyway.

#1 is entirely cosmetic. It should also be fine to put into -stable, but
since it had no operational impact, I figured it didn't need to be.

> So I'm thinking that the whole series can just be for 5.14-rc1, in the
> sent order.

Unless I'm missing something big, yeah, that would be my preference too.
(And -stable can pick it up then.)