linux-cve-announce - CVE-2022-49648: tracing/histograms: Fix memory leak problem

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
Message-ID: <2025022620-CVE-2022-49648-ffaa@gregkh>
Date: Wed, 26 Feb 2025 03:23:31 +0100
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: linux-cve-announce@...r.kernel.org
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Subject: CVE-2022-49648: tracing/histograms: Fix memory leak problem

Description
===========

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 parse_var_defs() if there is a problem allocating
  > var_defs.expr, the earlier var_defs.name is freed.
  > This free is duplicated by free_var_defs() which frees
  > 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' > \
/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

The Linux kernel CVE team has assigned CVE-2022-49648 to this issue.


Affected and fixed versions
===========================

	Issue introduced in 4.19.149 with commit 240dd5118a9e0454f280ffeae63f22bd14735733 and fixed in 4.19.253 with commit eb622d5580b9e2ff694f62da6410618bd73853cb
	Issue introduced in 5.4.69 with commit e92c490f104993cea35e5f5d5108ac12df1850ac and fixed in 5.4.207 with commit ecc6dec12c33aa92c086cd702af9f544ddaf3c75
	Issue introduced in 5.9 with commit 46bbe5c671e06f070428b9be142cc4ee5cedebac and fixed in 5.10.132 with commit 78a1400c42ee11197eb1f0f85ba51df9a4fdfff0
	Issue introduced in 5.9 with commit 46bbe5c671e06f070428b9be142cc4ee5cedebac and fixed in 5.15.56 with commit 22eeff55679d9e7c0f768c79bfbd83e2f8142d89
	Issue introduced in 5.9 with commit 46bbe5c671e06f070428b9be142cc4ee5cedebac and fixed in 5.18.13 with commit 4d453eb5e1eec89971aa5b3262857ee26cfdffd3
	Issue introduced in 5.9 with commit 46bbe5c671e06f070428b9be142cc4ee5cedebac and fixed in 5.19 with commit 7edc3945bdce9c39198a10d6129377a5c53559c2
	Issue introduced in 5.8.13 with commit e3a23511638a3dcf0275c1e71a46d1ca2e2e6788

Please see https://www.kernel.org for a full list of currently supported
kernel versions by the kernel community.

Unaffected versions might change over time as fixes are backported to
older supported kernel versions.  The official CVE entry at
	https://cve.org/CVERecord/?id=CVE-2022-49648
will be updated if fixes are backported, please check that for the most
up to date information about this issue.


Affected files
==============

The file(s) affected by this issue are:
	kernel/trace/trace_events_hist.c


Mitigation
==========

The Linux kernel CVE team recommends that you update to the latest
stable kernel version for this, and many other bugfixes.  Individual
changes are never tested alone, but rather are part of a larger kernel
release.  Cherry-picking individual commits is not recommended or
supported by the Linux kernel community at all.  If however, updating to
the latest release is impossible, the individual changes to resolve this
issue can be found at these commits:
	https://git.kernel.org/stable/c/eb622d5580b9e2ff694f62da6410618bd73853cb
	https://git.kernel.org/stable/c/ecc6dec12c33aa92c086cd702af9f544ddaf3c75
	https://git.kernel.org/stable/c/78a1400c42ee11197eb1f0f85ba51df9a4fdfff0
	https://git.kernel.org/stable/c/22eeff55679d9e7c0f768c79bfbd83e2f8142d89
	https://git.kernel.org/stable/c/4d453eb5e1eec89971aa5b3262857ee26cfdffd3
	https://git.kernel.org/stable/c/7edc3945bdce9c39198a10d6129377a5c53559c2