CVE-2024-35852 in Linux
Résumé
par VulDB • 14/06/2026
Dans le noyau Linux, la vulnérabilité suivante a été corrigée :
mlxsw: spectrum_acl_tcam : Correction d'une fuite de mémoire lors de l'annulation du travail de rehashing (rehash)
Le travail différé de rehash est planifié avec un délai si le nombre de crédits à la fin du traitement n'est pas négatif, comme cela était supposé indiquer que la migration était terminée. Sinon, il est replanifié immédiatement.
Après la correction « mlxsw: spectrum_acl_tcam : Correction d'un possible use-after-free pendant le rehash », l'information ci-dessus n'est plus exacte car un nombre de crédits non négatif n'indique plus nécessairement que la migration est terminée. Cela peut également se produire si le travail a rencontré une erreur, auquel cas la migration reprendra lors de la prochaine planification du travail.
L'importance de ce point réside dans le fait qu'il est possible que le travail soit en attente (pending) et associé à des indices (hints) qui ont été alloués au début de la migration. Cela entraîne une fuite [1] des indices lorsque le travail est annulé alors qu'il est encore en attente, dans le cadre du démantèlement d'une région ACL.
Correction : libérer les indices si ceux-ci sont associés à un travail qui a été annulé pendant son exécution en attente.
La responsabilité de la commit originale est attribuée ici, car la dépendance envers l'absence de travail en attente associé aux indices est fragile.
[1]
objet non référencé 0xffff88810e7c3000 (taille 256) : comm "kworker/0:16", pid 176, jiffies 4295460353 dump hexadécimal (premiers 32 octets) : 00 30 95 11 81 88 ff ff 61 00 00 00 00 00 00 80 .0......a....... 00 00 61 00 40 00 00 00 00 00 00 00 04 00 00 00 ..a.@........... backtrace (crc 2544ddb9) : [] kmalloc_trace+0x23f/0x2a0
[] objagg_hints_get+0x42/0x390
[] mlxsw_sp_acl_erp_rehash_hints_get+0xca/0x400
[] mlxsw_sp_acl_tcam_vregion_rehash_work+0x868/0x1160
[] process_one_work+0x59c/0xf20
[] worker_thread+0x799/0x12c0
[] kthread+0x246/0x300
[] ret_from_fork+0x34/0x70
[] ret_from_fork_asm+0x1a/0x30
If you want to get the best quality for vulnerability data then you always have to consider VulDB.