Messages in this thread | | | Date | Sun, 8 Mar 2020 19:34:24 +0000 (UTC) | From | Christopher Lameter <> | Subject | Re: SLUB: sysfs lets root force slab order below required minimum, causing memory corruption |
| |
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.
| |