CVE-2022-49648

Source
https://cve.org/CVERecord?id=CVE-2022-49648
Import Source
https://storage.googleapis.com/osv-test-cve-osv-conversion/osv-output/CVE-2022-49648.json
JSON Data
https://api.test.osv.dev/v1/vulns/CVE-2022-49648
Downstream
Related
Published
2025-02-26T02:23:52.035Z
Modified
2026-03-20T12:24:42.899663Z
Severity
  • 5.5 (Medium) CVSS_V3 - CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H CVSS Calculator
Summary
tracing/histograms: Fix memory leak problem
Details

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 freevar_defs(), the names from 0th to (N-1)-th are freed;

                    IF ALLOCATING PROBLEM HAPPENED HERE!!! -+
                                                             \
                                                              |
      0th           1th                 (N-1)-th      N-th    V
      +-------------+-------------+-----+-------------+-----------

var_defs: | 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 var_defs.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>] entrySYSCALL64after_hwframe+0x46/0xb0

Database specific
{
    "osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2022/49xxx/CVE-2022-49648.json",
    "cna_assigner": "Linux"
}
References

Affected packages

Git / git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git

Affected ranges

Type
GIT
Repo
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Events
Introduced
240dd5118a9e0454f280ffeae63f22bd14735733
Fixed
eb622d5580b9e2ff694f62da6410618bd73853cb
Type
GIT
Repo
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Events
Introduced
e92c490f104993cea35e5f5d5108ac12df1850ac
Fixed
ecc6dec12c33aa92c086cd702af9f544ddaf3c75
Type
GIT
Repo
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Events
Introduced
46bbe5c671e06f070428b9be142cc4ee5cedebac
Fixed
78a1400c42ee11197eb1f0f85ba51df9a4fdfff0
Fixed
22eeff55679d9e7c0f768c79bfbd83e2f8142d89
Fixed
4d453eb5e1eec89971aa5b3262857ee26cfdffd3
Fixed
7edc3945bdce9c39198a10d6129377a5c53559c2
Type
GIT
Repo
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Events
Introduced
0 Unknown introduced commit / All previous commits are affected
Last affected
e3a23511638a3dcf0275c1e71a46d1ca2e2e6788

Database specific

source
"https://storage.googleapis.com/osv-test-cve-osv-conversion/osv-output/CVE-2022-49648.json"