CVE-2024-46789
published 2024-09-18CVE-2024-46789: In the Linux kernel, the following vulnerability has been resolved: mm/slub: add check for s->flags in the alloc_tagging_slab_free_hook When enable…
PriorityP420medium5.5CVSS 3.1
AVLACLPRLUINSUCNINAH
EPSS
0.18%
7.4th percentile
In the Linux kernel, the following vulnerability has been resolved:
mm/slub: add check for s->flags in the alloc_tagging_slab_free_hook
When enable CONFIG_MEMCG & CONFIG_KFENCE & CONFIG_KMEMLEAK, the following
warning always occurs,This is because the following call stack occurred:
mem_pool_alloc
kmem_cache_alloc_noprof
slab_alloc_node
kfence_alloc
Once the kfence allocation is successful,slab->obj_exts will not be empty,
because it has already been assigned a value in kfence_init_pool.
Since in the prepare_slab_obj_exts_hook function,we perform a check for
s->flags & (SLAB_NO_OBJ_EXT | SLAB_NOLEAKTRACE),the alloc_tag_add function
will not be called as a result.Therefore,ref->ct remains NULL.
However,when we call mem_pool_free,since obj_ext is not empty, it
eventually leads to the alloc_tag_sub scenario being invoked. This is
where the warning occurs.
So we should add corresponding checks in the alloc_tagging_slab_free_hook.
For __GFP_NO_OBJ_EXT case,I didn't see the specific case where it's using
kfence,so I won't add the corresponding check in
alloc_tagging_slab_free_hook for now.
[ 3.734349] ------------[ cut here ]------------
[ 3.734807] alloc_tag was not set
[ 3.735129] WARNING: CPU: 4 PID: 40 at ./include/linux/alloc_tag.h:130 kmem_cache_free+0x444/0x574
[ 3.735866] Modules linked in: autofs4
[ 3.736211] CPU: 4 UID: 0 PID: 40 Comm: ksoftirqd/4 Tainted: G W 6.11.0-rc3-dirty #1
[ 3.736969] Tainted: [W]=WARN
[ 3.737258] Hardware name: QEMU KVM Virtual Machine, BIOS unknown 2/2/2022
[ 3.737875] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 3.738501] pc : kmem_cache_free+0x444/0x574
[ 3.738951] lr : kmem_cache_free+0x444/0x574
[ 3.739361] sp : ffff80008357bb60
[ 3.739693] x29: ffff80008357bb70 x28: 0000000000000000 x27: 0000000000000000
[ 3.740338] x26: ffff80008207f000 x25: ffff000b2eb2fd60 x24: ffff0000c0005700
[ 3.740982] x23: ffff8000804229e4 x22: ffff800082080000 x21: ffff800081756000
[ 3.741630] x20: fffffd7ff8253360 x19: 000000000
Affected
8 ranges
| Vendor | Product | Version range | Fixed in |
|---|---|---|---|
| debian | linux | < linux 6.10.11-1 (forky) | linux 6.10.11-1 (forky) |
| linux | linux | — | — |
| linux | linux | >= 4b8736964640fe160724e7135dc62883bddcdace < 2d476c86ba4745fcbc912ce4627df4fa80caa9ad | 2d476c86ba4745fcbc912ce4627df4fa80caa9ad |
| linux | linux | >= 4b8736964640fe160724e7135dc62883bddcdace < ab7ca09520e9c41c219a4427fe0dae24024bfe7f | ab7ca09520e9c41c219a4427fe0dae24024bfe7f |
| linux | linux_kernel | — | — |
| linux | linux_kernel | >= 0 < 6.10.11-1 | 6.10.11-1 |
| linux | linux_kernel | >= 0 < 6.10.11-1 | 6.10.11-1 |
| linux | linux_kernel | >= 6.10 < 6.10.10 | 6.10.10 |
CVSS provenance
nvdv3.15.5MEDIUMCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
osv5.5MEDIUM
vendor_debian5.5LOW
vendor_redhat5.5MEDIUM
Stop checking back — get the weekly exploitation signal.
Every Monday: what got weaponized or added to CISA KEV in the last seven days — each CVE cross-linked to its PoC, Nuclei template, and detection rule. Free, one email a week, unsubscribe in one click.
OSV
CVE-2024-46789: In the Linux kernel, the following vulnerability has been resolved: mm/slub: add check for s->flags in the alloc_tagging_slab_free_hook When enable CO
osv·2024-09-18·CVSS 5.5
CVE-2024-46789 [MEDIUM] CVE-2024-46789: In the Linux kernel, the following vulnerability has been resolved: mm/slub: add check for s->flags in the alloc_tagging_slab_free_hook When enable CO
In the Linux kernel, the following vulnerability has been resolved: mm/slub: add check for s->flags in the alloc_tagging_slab_free_hook When enable CONFIG_MEMCG & CONFIG_KFENCE & CONFIG_KMEMLEAK, the following warning always occurs,This is because the following call stack occurred: mem_pool_alloc kmem_cache_alloc_noprof slab_alloc_node kfence_alloc Once the kfence allocation is successful,slab->obj_exts will not be empty, because it has already been assigned a value in kfence_init_pool. Since in the prepare_slab_obj_exts_hook function,we perform a check for s->flags & (SLAB_NO_OBJ_EXT | SLAB_NOLEAKTRACE),the alloc_tag_add function will not be called as a result.Therefore,ref->ct remains NULL. However,when we call mem_pool_free,since obj_ext is not empty, it eventually leads to the alloc_ta
GHSA
GHSA-xmx8-5v8v-4mhj: In the Linux kernel, the following vulnerability has been resolved:
mm/slub: add check for s->flags in the alloc_tagging_slab_free_hook
When enable
ghsa_unreviewed·2024-09-18
CVE-2024-46789 [MEDIUM] GHSA-xmx8-5v8v-4mhj: In the Linux kernel, the following vulnerability has been resolved:
mm/slub: add check for s->flags in the alloc_tagging_slab_free_hook
When enable
In the Linux kernel, the following vulnerability has been resolved:
mm/slub: add check for s->flags in the alloc_tagging_slab_free_hook
When enable CONFIG_MEMCG & CONFIG_KFENCE & CONFIG_KMEMLEAK, the following
warning always occurs,This is because the following call stack occurred:
mem_pool_alloc
kmem_cache_alloc_noprof
slab_alloc_node
kfence_alloc
Once the kfence allocation is successful,slab->obj_exts will not be empty,
because it has already been assigned a value in kfence_init_pool.
Since in the prepare_slab_obj_exts_hook function,we perform a check for
s->flags & (SLAB_NO_OBJ_EXT | SLAB_NOLEAKTRACE),the alloc_tag_add function
will not be called as a result.Therefore,ref->ct remains NULL.
However,when we call mem_pool_free,since obj_ext is not empty, it
eventually leads to the all
Red Hat
kernel: mm/slub: add check for s->flags in the alloc_tagging_slab_free_hook
vendor_redhat·2024-09-18·CVSS 5.5
CVE-2024-46789 [MEDIUM] CWE-401 kernel: mm/slub: add check for s->flags in the alloc_tagging_slab_free_hook
kernel: mm/slub: add check for s->flags in the alloc_tagging_slab_free_hook
In the Linux kernel, the following vulnerability has been resolved:
mm/slub: add check for s->flags in the alloc_tagging_slab_free_hook
When enable CONFIG_MEMCG & CONFIG_KFENCE & CONFIG_KMEMLEAK, the following
warning always occurs,This is because the following call stack occurred:
mem_pool_alloc
kmem_cache_alloc_noprof
slab_alloc_node
kfence_alloc
Once the kfence allocation is successful,slab->obj_exts will not be empty,
because it has already been assigned a value in kfence_init_pool.
Since in the prepare_slab_obj_exts_hook function,we perform a check for
s->flags & (SLAB_NO_OBJ_EXT | SLAB_NOLEAKTRACE),the alloc_tag_add function
will not be called as a result.Therefore,ref->ct remains NULL.
However,when we call
Debian
CVE-2024-46789: linux - In the Linux kernel, the following vulnerability has been resolved: mm/slub: ad...
vendor_debian·2024·CVSS 5.5
CVE-2024-46789 [MEDIUM] CVE-2024-46789: linux - In the Linux kernel, the following vulnerability has been resolved: mm/slub: ad...
In the Linux kernel, the following vulnerability has been resolved: mm/slub: add check for s->flags in the alloc_tagging_slab_free_hook When enable CONFIG_MEMCG & CONFIG_KFENCE & CONFIG_KMEMLEAK, the following warning always occurs,This is because the following call stack occurred: mem_pool_alloc kmem_cache_alloc_noprof slab_alloc_node kfence_alloc Once the kfence allocation is successful,slab->obj_exts will not be empty, because it has already been assigned a value in kfence_init_pool. Since in the prepare_slab_obj_exts_hook function,we perform a check for s->flags & (SLAB_NO_OBJ_EXT | SLAB_NOLEAKTRACE),the alloc_tag_add function will not be called as a result.Therefore,ref->ct remains NULL. However,when we call mem_pool_free,since obj_ext is not empty, it eventually leads to the alloc_ta
No detection rules found.
No public exploits indexed.
No writeups or analysis indexed.
2024-09-18
Published