In the Linux kernel, the following vulnerability has been resolved:<\/p>\n
mm\/slab: prevent unbounded recursion in free path with new kmalloc type<\/p>\n
Commit 280ea9c3154b (“mm\/slab: avoid allocating slabobj_ext array from
\nits own slab”) avoided recursive allocation of obj_exts from kmalloc
\ncaches of the same size, by bumping the obj_exts array’s allocation
\nsize whenever the array size equals the size of the object being
\nallocated.<\/p>\n
However, as reported by Danielle Costantino and Shakeel Butt,
\neven slabs from kmalloc caches of different sizes can form a cycle
\nby allocating obj_exts arrays from each other [1]:<\/p>\n
What happened: a KMALLOC_NORMAL slab’s obj_exts array (used by
\n allocation profiling \/ memcg accounting) is itself kmalloc()’d from a
\n KMALLOC_NORMAL cache, so the “slab holds another slab’s obj_exts array”
\n relation can form cycles. With sizeof(struct slabobj_ext) == 16 and
\n the host’s geometry:<\/p>\n
– kmalloc-512 has 64 objects\/slab -> array is 64*16 == 1024 bytes,
\n served from kmalloc-1k;
\n – kmalloc-1k has 32 objects\/slab -> array is 32*16 == 512 bytes,
\n served from kmalloc-512.<\/p>\n
A kmalloc-512 slab and a kmalloc-1k slab therefore hold each other’s
\n obj_exts array. Discarding one frees the other’s array, which empties
\n and discards that slab, which frees the first’s array, and so on:
\n __free_slab() -> free_slab_obj_exts() -> kfree() -> discard_slab() ->
\n __free_slab() recurses along the cycle until the stack is exhausted.<\/p>\n
With memory allocation profiling, this allows unbounded recursion
\nin the free path and led to a stack overflow on a production host in
\nthe Meta fleet [1]:<\/p>\n
BUG: TASK stack guard page was hit
\n Oops: stack guard page
\n RIP: 0010:kfree+0x8\/0x5d0
\n Call Trace:
\n __free_slab+0x66\/0xc0
\n kfree+0x3f0\/0x5d0
\n … ( ~125x __free_slab kfree ) …<\/p>\n
do_syscall_64<\/p>\n
It is proposed [1] to resolve this issue by always serving the obj_exts
\narray allocation from kmalloc caches (or large kmalloc) of sizes larger
\nthan the object size. However, as pointed out by Vlastimil Babka [2],
\nthis can waste an excessive amount of memory as slabs from large
\nkmalloc sizes (e.g. kmalloc-8k) generally need obj_exts arrays much
\nsmaller than the object size.<\/p>\n
Therefore, rather than bumping the size, let us take a different
\napproach; disallow formation of cycles between kmalloc types when
\nallocating obj_exts arrays. Currently, all obj_exts arrays are served
\nfrom normal kmalloc caches. Cycles cannot be created if obj_exts arrays
\nof normal kmalloc caches are served from a special kmalloc type that can
\nnever have obj_exts arrays.<\/p>\n
To achieve this, create a new kmalloc type called KMALLOC_NO_OBJ_EXT.
\nKMALLOC_NO_OBJ_EXT caches are created with SLAB_NO_OBJ_EXT flag when
\neither 1) memory allocation profiling is not permanently disabled,
\nor 2) kmalloc types with a priority higher than KMALLOC_CGROUP are
\naliased with KMALLOC_NORMAL.<\/p>\n
Sheaf bootstrapping for KMALLOC_NO_OBJ_EXT caches now must be deferred
\nbecause allocation of a barn can trigger obj_exts array allocation of
\nnormal kmalloc caches when the KMALLOC_NO_OBJ_EXT cache for that size
\nis not ready yet. For simplicity, perform bootstrapping of sheaves for
\nall kmalloc caches later.<\/p>\n
Introduce a new slab alloc flag, SLAB_ALLOC_NO_OBJ_EXT, to prevent
\nallocation of obj_exts arrays, and let kmalloc_slab() override the type
\nto KMALLOC_NO_OBJ_EXT when specified. Note that kmalloc_type() remains
\nunchanged because kmalloc_flags() bypasses the kmalloc fastpath.<\/p>\n
Do not pass SLAB_ALLOC_NO_RECURSE to kmalloc_flags() in
\nalloc_slab_obj_exts() and instead use SLAB_ALLOC_NO_OBJ_EXT only when
\nthe objects are allocated from normal kmalloc caches. While this
\nprevents unbounded recursive allocation of obj_exts, it allows
\nKMALLOC_NO_OBJ_EXT caches to have sheaves.<\/p>\n
Since sheaf allocations specify SLAB_ALLOC_NO_RECURSE that prevents
\nallocation of both sheaves and obj_exts arrays, the recursion depth
\nis bounded.<\/p>\n
obj_exts arrays for non-
\n—truncated—<\/p>\n","protected":false},"excerpt":{"rendered":"
In the Linux kernel, the following vulnerability has been resolved:<\/p>\n
mm\/slab: prevent unbounded recursion in free path with new kmalloc type<\/p>\n
Commit 280ea9c3154b (“mm\/slab: avoid allocating slabobj_ex<\/p>\n","protected":false},"template":"","meta":[],"categories":[],"tags":[],"class_list":["post-7600","vuln","type-vuln","status-publish","hentry"],"_links":{"self":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/vuln\/7600","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/vuln"}],"about":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/types\/vuln"}],"wp:attachment":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=7600"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=7600"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=7600"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}