https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Wed, 07 Oct 2026 15:13:22 +0000 https://cve.radiocsirt.org/vuln/cve-2022-49648 <p><strong>Affected:</strong> Linux</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>tracing/histograms: Fix memory leak problem</p> <p>This reverts commit 46bbe5c671e06f070428b9be142cc4ee5cedebac.</p> <p>As commit 46bbe5c671e0 (&#34;tracing: fix double free&#34;) said, the &#34;double free&#34; problem reported by clang static analyzer is: &gt; In parse_var_defs() if there is a problem allocating &gt; var_defs.expr, the earlier var_defs.name is freed. &gt; This free is duplicated by free_var_defs() which frees &gt; the rest of the list.</p> <p>However, if there is a problem allocating N-th var_defs.expr: + in parse_var_defs(), the freed &#39;earlier var_defs.name&#39; is actually the N-th var_defs.name; + then in free_var_defs(), the names from 0th to (N-1)-th are freed;</p> <p>IF ALLOCATING PROBLEM HAPPENED HERE!!! -+ \ | 0th 1th (N-1)-th N-th V +-------------+-------------+-----+-------------+----------- var_defs: | name | expr | name | expr | ... | name | expr | name | /// +-------------+-------------+-----+-------------+-----------</p> <p>These two frees don&#39;t act on same name, so there was no &#34;double free&#34; problem before. Conversely, after that commit, we get a &#34;memory leak&#34; problem because the above &#34;N-th var_defs.name&#34; is not freed.</p> <p>If enable CONFIG_DEBUG_KMEMLEAK and inject a fault at where the N-th var_defs.expr a…</p> <p><strong>Affected:</strong> Linux</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>tracing/histograms: Fix memory leak problem</p> <p>This reverts commit 46bbe5c671e06f070428b9be142cc4ee5cedebac.</p> <p>As commit 46bbe5c671e0 (&#34;tracing: fix double free&#34;) said, the &#34;double free&#34; problem reported by clang static analyzer is: &gt; In parse_var_defs() if there is a problem allocating &gt; var_defs.expr, the earlier var_defs.name is freed. &gt; This free is duplicated by free_var_defs() which frees &gt; the rest of the list.</p> <p>However, if there is a problem allocating N-th var_defs.expr: + in parse_var_defs(), the freed &#39;earlier var_defs.name&#39; is actually the N-th var_defs.name; + then in free_var_defs(), the names from 0th to (N-1)-th are freed;</p> <p>IF ALLOCATING PROBLEM HAPPENED HERE!!! -+ \ | 0th 1th (N-1)-th N-th V +-------------+-------------+-----+-------------+----------- var_defs: | name | expr | name | expr | ... | name | expr | name | /// +-------------+-------------+-----+-------------+-----------</p> <p>These two frees don&#39;t act on same name, so there was no &#34;double free&#34; problem before. Conversely, after that commit, we get a &#34;memory leak&#34; problem because the above &#34;N-th var_defs.name&#34; is not freed.</p> <p>If enable CONFIG_DEBUG_KMEMLEAK and inject a fault at where the N-th var_defs.expr a…</p> https://cve.radiocsirt.org/vuln/cve-2022-49648