"value":"In the Linux kernel, the following vulnerability has been resolved:\n\ntracing/histograms: Fix memory leak problem\n\nThis reverts commit 46bbe5c671e06f070428b9be142cc4ee5cedebac.\n\nAs commit 46bbe5c671e0 (\"tracing: fix double free\") said, the\n\"double free\" problem reported by clang static analyzer is:\n > In parse_var_defs() if there is a problem allocating\n > var_defs.expr, the earlier var_defs.name is freed.\n > This free is duplicated by free_var_defs() which frees\n > the rest of the list.\n\nHowever, if there is a problem allocating N-th var_defs.expr:\n + in parse_var_defs(), the freed 'earlier var_defs.name' is\n actually the N-th var_defs.name;\n + then in free_var_defs(), the names from 0th to (N-1)-th are freed;\n\n IF ALLOCATING PROBLEM HAPPENED HERE!!! -+\n \\\n |\n 0th 1th (N-1)-th N-th V\n +-------------+-------------+-----+-------------+-----------\nvar_defs: | name | expr | name | expr | ... | name | expr | name | ///\n +-------------+-------------+-----+-------------+-----------\n\nThese two frees don't act on same name, so there was no \"double free\"\nproblem before. Conversely, after that commit, we get a \"memory leak\"\nproblem because the above \"N-th var_defs.name\" is not freed.\n\nIf enable CONFIG_DEBUG_KMEMLEAK and inject a fault at where the N-th\nvar_defs.expr allocated, then execute on shell like:\n $ echo 'hist:key=call_site:val=$v1,$v2:v1=bytes_req,v2=bytes_alloc' > \\\n/sys/kernel/debug/tracing/events/kmem/kmalloc/trigger\n\nThen kmemleak reports:\n unreferenced object 0xffff8fb100ef3518 (size 8):\n comm \"bash\", pid 196, jiffies 4295681690 (age 28.538s)\n hex dump (first 8 bytes):\n 76 31 00 00 b1 8f ff ff v1......\n backtrace:\n [<0000000038fe4895>] kstrdup+0x2d/0x60\n [<00000000c99c049a>] event_hist_trigger_parse+0x206f/0x20e0\n [<00000000ae70d2cc>] trigger_process_regex+0xc0/0x110\n [<0000000066737a4c>] event_trigger_write+0x75/0xd0\n [<000000007341e40c>] vfs_write+0xbb/0x2a0\n [<0000000087fde4c2>] ksys_write+0x59/0xd0\n [<00000000581e9cdf>] do_syscall_64+0x3a/0x80\n [<00000000cf3b065c>] entry_SYSCALL_64_after_hwframe+0x46/0xb0"
"value":"En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tracing/histograms: Fix memory leak problem Esto revierte el commit 46bbe5c671e06f070428b9be142cc4ee5cedebac. Como dec\u00eda el commit 46bbe5c671e0 (\"tracing: fix double free\"), el problema de \"doble liberaci\u00f3n\" informado por el analizador est\u00e1tico 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\u00f3n se duplica mediante free_var_defs(), que libera el resto de la lista. Sin embargo, si hay un problema al asignar la N-\u00e9sima var_defs.expr: + en parse_var_defs(), el 'var_defs.name anterior' liberado es en realidad el N-\u00e9simo var_defs.name; + entonces en free_var_defs(), los nombres del 0 al (N-1)-\u00e9simo se liberan; \u00a1SI SUCEDI\u00d3 UN PROBLEMA DE ASIGNACI\u00d3N AQU\u00cd!!! -+ \\ | 0th 1th (N-1)-th N-th V +-------------+-------------+-----+-------------+----------- var_defs: | name | expr | name | expr | ... | name | expr | name | /// +-------------+-------------+-----+-------------+----------- Estas dos liberaciones no act\u00faan sobre el mismo nombre, por lo que antes no hab\u00eda un problema de \"doble liberaci\u00f3n\". Por el contrario, despu\u00e9s de esa confirmaci\u00f3n, tenemos un problema de \"p\u00e9rdida de memoria\" porque el \"N-\u00e9simo var_defs.name\" anterior no se libera. Si habilita CONFIG_DEBUG_KMEMLEAK e inyecta un error en el lugar donde se asign\u00f3 el N-\u00e9simo 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 "
