CVE-2022-49648: tracing/histograms: Fix memory leak problem
In the Linux kernel, the following vulnerability has been resolved:
tracing/histograms: Fix memory leak problem
This reverts commit 46bbe5c671e06f070428b9be142cc4ee5cedebac.
As commit 46bbe5c671e0 ("tracing: fix double free") said, the "double free" problem reported by clang static analyzer is: In parsevardefs() if there is a problem allocating vardefs.expr, the earlier vardefs.name is freed. This free is duplicated by freevardefs() which frees the rest of the list.
However, if there is a problem allocating N-th vardefs.expr: + in parsevardefs(), the freed 'earlier vardefs.name' is actually the N-th vardefs.name; + then in freevardefs(), the names from 0th to (N-1)-th are freed;
IF ALLOCATING PROBLEM HAPPENED HERE!!! -+ \ | 0th 1th (N-1)-th N-th V +-------------+-------------+-----+-------------+----------- vardefs: | name | expr | name | expr | ... | name | expr | name | /// +-------------+-------------+-----+-------------+-----------
These two frees don't act on same name, so there was no "double free" problem before. Conversely, after that commit, we get a "memory leak" problem because the above "N-th vardefs.name" is not freed.
If enable CONFIGDEBUGKMEMLEAK and inject a fault at where the N-th vardefs.expr allocated, then execute on shell like: $ echo 'hist:key=callsite:val=$v1,$v2:v1=bytesreq,v2=bytesalloc' \ /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] eventhisttriggerparse+0x206f/0x20e0 [00000000ae70d2cc] triggerprocessregex+0xc0/0x110 [0000000066737a4c] eventtriggerwrite+0x75/0xd0 [000000007341e40c] vfswrite+0xbb/0x2a0 [0000000087fde4c2] ksyswrite+0x59/0xd0 [00000000581e9cdf] dosyscall64+0x3a/0x80 [00000000cf3b065c] entrySYSCALL64afterhwframe+0x46/0xb0
Other sources
In the Linux kernel, the following vulnerability has been resolved:
tracing/histograms: Fix memory leak problem
This reverts commit 46bbe5c671e06f070428b9be142cc4ee5cedebac.
As commit 46bbe5c671e0 ("tracing: fix double free") said, the "double free" problem reported by clang static analyzer is: > In parsevardefs() if there is a problem allocating > vardefs.expr, the earlier vardefs.name is freed. > This free is duplicated by freevardefs() which frees > the rest of the list.
However, if there is a problem allocating N-th vardefs.expr: + in parsevardefs(), the freed 'earlier vardefs.name' is actually the N-th vardefs.name; + then in freevardefs(), the names from 0th to (N-1)-th are freed;
IF ALLOCATING PROBLEM HAPPENED HERE!!! -+ \ | 0th 1th (N-1)-th N-th V +-------------+-------------+-----+-------------+----------- vardefs: | name | expr | name | expr | ... | name | expr | name | /// +-------------+-------------+-----+-------------+-----------
These two frees don't act on same name, so there was no "double free" problem before. Conversely, after that commit, we get a "memory leak" problem because the above "N-th vardefs.name" is not freed.
If enable CONFIGDEBUGKMEMLEAK and inject a fault at where the N-th vardefs.expr allocated, then execute on shell like: $ echo 'hist:key=callsite:val=$v1,$v2:v1=bytesreq,v2=bytesalloc' > \ /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>] eventhisttriggerparse+0x206f/0x20e0 [<00000000ae70d2cc>] triggerprocessregex+0xc0/0x110 [<0000000066737a4c>] eventtriggerwrite+0x75/0xd0 [<000000007341e40c>] vfswrite+0xbb/0x2a0 [<0000000087fde4c2>] ksyswrite+0x59/0xd0 [<00000000581e9cdf>] dosyscall64+0x3a/0x80 [<00000000cf3b065c>] entrySYSCALL64afterhwframe+0x46/0xb0
— NVD
Affected Software
Event History
Frequently Asked Questions
What is the severity of CVE-2022-49648?
CVE-2022-49648 has not been assigned a CVSS score, but it addresses a memory leak vulnerability in the Linux kernel.
How do I fix CVE-2022-49648?
To fix CVE-2022-49648, you should update to the latest Linux kernel version that contains the patch for this vulnerability.
What versions of the Linux kernel are affected by CVE-2022-49648?
CVE-2022-49648 affects several versions of the Linux kernel, including versions between 4.19.149 to 4.19.253, 5.4.69 to 5.4.207, and others as detailed in the vulnerability report.
Is CVE-2022-49648 a critical vulnerability?
While CVE-2022-49648 may lead to resource leaks, its criticality depends on the specific system configuration and usage.
Can CVE-2022-49648 lead to system crashes?
CVE-2022-49648 primarily involves a memory leak that could potentially lead to performance degradation but not necessarily a system crash.