Vulnerabilidad en kernel de Linux (CVE-2022-49648)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tracing/histograms: Fix memory leak problem Esto revierte el commit 46bbe5c671e06f070428b9be142cc4ee5cedebac. Como decía el commit 46bbe5c671e0 ("tracing: fix double free"), el problema de "doble liberación" informado por el analizador estático de clang es: > En parse_var_defs(), si hay un problema al asignar var_defs.expr, se libera el var_defs.name anterior. > Esta liberación se duplica mediante free_var_defs(), que libera el resto de la lista. Sin embargo, si hay un problema al asignar la N-ésima var_defs.expr: + en parse_var_defs(), el 'var_defs.name anterior' liberado es en realidad el N-ésimo var_defs.name; + entonces en free_var_defs(), los nombres del 0 al (N-1)-ésimo se liberan; ¡SI SUCEDIÓ UN PROBLEMA DE ASIGNACIÓN AQUÍ!!! -+ \ | 0th 1th (N-1)-th N-th V +-------------+-------------+-----+-------------+----------- var_defs: | name | expr | name | expr | ... | name | expr | name | /// +-------------+-------------+-----+-------------+----------- Estas dos liberaciones no actúan sobre el mismo nombre, por lo que antes no había un problema de "doble liberación". Por el contrario, después de esa confirmación, tenemos un problema de "pérdida de memoria" porque el "N-ésimo var_defs.name" anterior no se libera. Si habilita CONFIG_DEBUG_KMEMLEAK e inyecta un error en el lugar donde se asignó el N-ésimo var_defs.expr, entonces ejecute en el shell de esta manera: $ echo 'hist:key=call_site:val=$v1,$v2:v1=bytes_req,v2=bytes_alloc' > \ /sys/kernel/debug/tracing/events/kmem/kmalloc/trigger Then kmemleak reports: unreferenced object 0xffff8fb100ef3518 (size 8): comm "bash", pid 196, jiffies 4295681690 (age 28.538s) hex dump (first 8 bytes): 76 31 00 00 b1 8f ff ff v1...... backtrace: [<0000000038fe4895>] kstrdup+0x2d/0x60 [<00000000c99c049a>] event_hist_trigger_parse+0x206f/0x20e0 [<00000000ae70d2cc>] trigger_process_regex+0xc0/0x110 [<0000000066737a4c>] event_trigger_write+0x75/0xd0 [<000000007341e40c>] vfs_write+0xbb/0x2a0 [<0000000087fde4c2>] ksys_write+0x59/0xd0 [<00000000581e9cdf>] do_syscall_64+0x3a/0x80 [<00000000cf3b065c>] entry_SYSCALL_64_after_hwframe+0x46/0xb0