Re: SLUB: sysfs lets root force slab order below required minimum, causing memory corruption

[Christopher Lameter]

On Wed, 4 Mar 2020, David Rientjes wrote:

> I'm not sure how dependent the CONFIG_SLUB_DEBUG users are on being able
> to modify these are runtime (they've been around for 12+ years) but I
> agree that it seems particularly dangerous.

The order of each individual slab page is stored in struct page. That is
why every slub slab page can have a different order. This enabled fallback
to order 0 allocations and also allows a dynamic configuration of the
order at runtime.

> The slub_debug kernel command line options are already pretty
> comprehensive as described by Documentation/vm/slub.rst.  I *think* these
> tunables were primarily introduced for kernel debugging and not general
> purpose, perhaps with the exception of "order".

What do you mean by "general purpose? Certainly the allocator should not
blow up when forcing zero order allocations.

> So I think we may be able to fix "order" with a combination of my patch as
> well as a fix to the freelist randomization and that the others should
> likely be made read only.

Hmmm. races increases as more metadata is added that is depending on the
size of the slab page and the number of objects in it.