{"id":"DEBIAN-CVE-2022-49648","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:   \u003e In parse_var_defs() if there is a problem allocating   \u003e var_defs.expr, the earlier var_defs.name is freed.   \u003e This free is duplicated by free_var_defs() which frees   \u003e the rest of the list.  However, if there is a problem allocating N-th var_defs.expr:   + in parse_var_defs(), the freed 'earlier var_defs.name' is     actually the N-th var_defs.name;   + then in free_var_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 CONFIG_DEBUG_KMEMLEAK and inject a fault at where the N-th var_defs.expr allocated, then execute on shell like:   $ echo 'hist:key=call_site:val=$v1,$v2:v1=bytes_req,v2=bytes_alloc' \u003e \\ /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:       [\u003c0000000038fe4895\u003e] kstrdup+0x2d/0x60       [\u003c00000000c99c049a\u003e] event_hist_trigger_parse+0x206f/0x20e0       [\u003c00000000ae70d2cc\u003e] trigger_process_regex+0xc0/0x110       [\u003c0000000066737a4c\u003e] event_trigger_write+0x75/0xd0       [\u003c000000007341e40c\u003e] vfs_write+0xbb/0x2a0       [\u003c0000000087fde4c2\u003e] ksys_write+0x59/0xd0       [\u003c00000000581e9cdf\u003e] do_syscall_64+0x3a/0x80       [\u003c00000000cf3b065c\u003e] entry_SYSCALL_64_after_hwframe+0x46/0xb0","modified":"2026-09-01T16:05:32.935254110Z","published":"2025-02-26T07:01:39.957Z","upstream":["CVE-2022-49648"],"references":[{"type":"ADVISORY","url":"https://security-tracker.debian.org/tracker/CVE-2022-49648"}],"affected":[{"package":{"name":"linux","ecosystem":"Debian:12","purl":"pkg:deb/debian/linux?arch=source&distro=bookworm"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"5.18.14-1"}]}],"ecosystem_specific":{"urgency":"not yet assigned"},"database_specific":{"source":"https://storage.googleapis.com/osv-test-debian-osv/debian-cve-osv/DEBIAN-CVE-2022-49648.json"}},{"package":{"name":"linux","ecosystem":"Debian:13","purl":"pkg:deb/debian/linux?arch=source&distro=trixie"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"5.18.14-1"}]}],"ecosystem_specific":{"urgency":"not yet assigned"},"database_specific":{"source":"https://storage.googleapis.com/osv-test-debian-osv/debian-cve-osv/DEBIAN-CVE-2022-49648.json"}},{"package":{"name":"linux","ecosystem":"Debian:14","purl":"pkg:deb/debian/linux?arch=source&distro=forky"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"5.18.14-1"}]}],"ecosystem_specific":{"urgency":"not yet assigned"},"database_specific":{"source":"https://storage.googleapis.com/osv-test-debian-osv/debian-cve-osv/DEBIAN-CVE-2022-49648.json"}}],"schema_version":"1.9.0","severity":[{"type":"CVSS_V3","score":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H"}]}