CVE-2022-49648 Affecting kernel-zfcpdump-modules-internal package, versions *


Severity

Recommended
0.0
medium
0
10

Based on CentOS security rating.

Do your applications use this vulnerable package?

In a few clicks we can analyze your entire application and see what components are vulnerable in your application, and suggest you quick fixes.

Test your applications
  • Snyk IDSNYK-CENTOS9-KERNELZFCPDUMPMODULESINTERNAL-9107009
  • published5 Mar 2025
  • disclosed26 Feb 2025

Introduced: 26 Feb 2025

NewCVE-2022-49648  (opens in a new tab)

How to fix?

There is no fixed version for Centos:9 kernel-zfcpdump-modules-internal.

NVD Description

Note: Versions mentioned in the description apply only to the upstream kernel-zfcpdump-modules-internal package and not the kernel-zfcpdump-modules-internal package as distributed by Centos. See How to fix? for Centos:9 relevant fixed versions and status.

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

CVSS Base Scores

version 3.1