<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" version="2.0">
  <channel>
    <title>Most recent entries from all</title>
    <link>https://db.gcve.eu</link>
    <description>Contains only the most 10 recent entries.</description>
    <docs>http://www.rssboard.org/rss-specification</docs>
    <generator>python-feedgen</generator>
    <language>en</language>
    <lastBuildDate>Sat, 24 Oct 2026 01:05:59 +0000</lastBuildDate>
    <item>
      <title>ALSA-2025:20518 — Moderate: kernel security update</title>
      <link>https://db.gcve.eu/vuln/alsa-2025:20518</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; AlmaLinux:9: kernel, AlmaLinux:9: kernel-64k, AlmaLinux:9: kernel-64k-core, AlmaLinux:9: kernel-64k-debug, AlmaLinux:9: kernel-64k-debug-core, AlmaLinux:9: kernel-64k-debug-devel, AlmaLinux:9: kernel-64k-debug-devel-matched, AlmaLinux:9: kernel-64k-debug-modules, AlmaLinux:9: kernel-64k-debug-modules-core, AlmaLinux:9: kernel-64k-debug-modules-extra and 64 more&lt;/p&gt;
&lt;p&gt;The kernel packages contain the Linux kernel, the core of any Linux operating system.&lt;/p&gt;
&lt;p&gt;Security Fix(es):&lt;/p&gt;
&lt;p&gt;* kernel: can: isotp: fix potential CAN frame reception race in isotp_rcv() (CVE-2022-48830)
  * kernel: soc: qcom: cmd-db: Map shared memory as WC, not WB (CVE-2024-46689)
  * kernel: Squashfs: sanity check symbolic link size (CVE-2024-46744)
  * kernel: vfs: fix race between evice_inodes() and find_inode()&amp;amp;#38;iput() (CVE-2024-47679)
  * kernel: x86/tdx: Fix &amp;#34;in-kernel MMIO&amp;#34; check (CVE-2024-47727)
  * kernel: rxrpc: Fix a race between socket set up and I/O thread creation (CVE-2024-49864)
  * kernel: io_uring: check if we need to reschedule during overflow flush (CVE-2024-50060)
  * kernel: can: m_can: pci: add missing m_can_class_free_dev() in probe/remove methods (CVE-2022-49024)
  * kernel: posix-clock: Fix missing timespec64 check in pc_clock_settime() (CVE-2024-50195)
  * kernel: rxrpc: Fix missing locking causing hanging calls (CVE-2024-50294)
  * kernel: io_uring/rw: fix missing NOWAIT check for O_DIRECT start write (CVE-2024-53052)
  * kernel: afs: Fix lock recursion (CVE-2024-53090)
  * kernel: virtio/vsock: Fix accept_queue memory leak (CVE-2024-53119)
  * kernel: KVM: VMX: Bury Intel PT virtualization (guest/host mode) behind CONFIG_BROKEN (CVE-2024-53135)
  * kernel: xen: Xen hypercall page unsafe against speculative attacks (Xen Security Advisory 466) (CVE-2024-53241)
  * kernel: RDMA/rxe: Fix the qp flush warnings in req (CVE-2024-53229)
  * kernel:…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; AlmaLinux:9: kernel, AlmaLinux:9: kernel-64k, AlmaLinux:9: kernel-64k-core, AlmaLinux:9: kernel-64k-debug, AlmaLinux:9: kernel-64k-debug-core, AlmaLinux:9: kernel-64k-debug-devel, AlmaLinux:9: kernel-64k-debug-devel-matched, AlmaLinux:9: kernel-64k-debug-modules, AlmaLinux:9: kernel-64k-debug-modules-core, AlmaLinux:9: kernel-64k-debug-modules-extra and 64 more&lt;/p&gt;
&lt;p&gt;The kernel packages contain the Linux kernel, the core of any Linux operating system.&lt;/p&gt;
&lt;p&gt;Security Fix(es):&lt;/p&gt;
&lt;p&gt;* kernel: can: isotp: fix potential CAN frame reception race in isotp_rcv() (CVE-2022-48830)
  * kernel: soc: qcom: cmd-db: Map shared memory as WC, not WB (CVE-2024-46689)
  * kernel: Squashfs: sanity check symbolic link size (CVE-2024-46744)
  * kernel: vfs: fix race between evice_inodes() and find_inode()&amp;amp;#38;iput() (CVE-2024-47679)
  * kernel: x86/tdx: Fix &amp;#34;in-kernel MMIO&amp;#34; check (CVE-2024-47727)
  * kernel: rxrpc: Fix a race between socket set up and I/O thread creation (CVE-2024-49864)
  * kernel: io_uring: check if we need to reschedule during overflow flush (CVE-2024-50060)
  * kernel: can: m_can: pci: add missing m_can_class_free_dev() in probe/remove methods (CVE-2022-49024)
  * kernel: posix-clock: Fix missing timespec64 check in pc_clock_settime() (CVE-2024-50195)
  * kernel: rxrpc: Fix missing locking causing hanging calls (CVE-2024-50294)
  * kernel: io_uring/rw: fix missing NOWAIT check for O_DIRECT start write (CVE-2024-53052)
  * kernel: afs: Fix lock recursion (CVE-2024-53090)
  * kernel: virtio/vsock: Fix accept_queue memory leak (CVE-2024-53119)
  * kernel: KVM: VMX: Bury Intel PT virtualization (guest/host mode) behind CONFIG_BROKEN (CVE-2024-53135)
  * kernel: xen: Xen hypercall page unsafe against speculative attacks (Xen Security Advisory 466) (CVE-2024-53241)
  * kernel: RDMA/rxe: Fix the qp flush warnings in req (CVE-2024-53229)
  * kernel:…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/alsa-2025:20518</guid>
    </item>
    <item>
      <title>certfr-2025-avi-0252 — De multiples vulnérabilités ont été découvertes dans le noyau Linux de SUSE. Certaines d'entre elles permettent à un at…</title>
      <link>https://db.gcve.eu/vuln/certfr-2025-avi-0252</link>
      <description>certfr-2025-avi-0252</description>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/certfr-2025-avi-0252</guid>
    </item>
    <item>
      <title>fkie_cve-2022-49648</title>
      <link>https://db.gcve.eu/vuln/fkie_cve-2022-49648</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;tracing/histograms: Fix memory leak problem&lt;/p&gt;
&lt;p&gt;This reverts commit 46bbe5c671e06f070428b9be142cc4ee5cedebac.&lt;/p&gt;
&lt;p&gt;As commit 46bbe5c671e0 (&amp;#34;tracing: fix double free&amp;#34;) said, the
&amp;#34;double free&amp;#34; problem reported by clang static analyzer is:
  &amp;gt; In parse_var_defs() if there is a problem allocating
  &amp;gt; var_defs.expr, the earlier var_defs.name is freed.
  &amp;gt; This free is duplicated by free_var_defs() which frees
  &amp;gt; the rest of the list.&lt;/p&gt;
&lt;p&gt;However, if there is a problem allocating N-th var_defs.expr:
  + in parse_var_defs(), the freed &amp;#39;earlier var_defs.name&amp;#39; is
    actually the N-th var_defs.name;
  + then in free_var_defs(), the names from 0th to (N-1)-th are freed;&lt;/p&gt;
&lt;p&gt;IF ALLOCATING PROBLEM HAPPENED HERE!!! -+
                                                                 \
                                                                  |
          0th           1th                 (N-1)-th      N-th    V
          +-------------+-------------+-----+-------------+-----------
var_defs: | name | expr | name | expr | ... | name | expr | name | ///
          +-------------+-------------+-----+-------------+-----------&lt;/p&gt;
&lt;p&gt;These two frees don&amp;#39;t act on same name, so there was no &amp;#34;double free&amp;#34;
problem before. Conversely, after that commit, we get a &amp;#34;memory leak&amp;#34;
problem because the above &amp;#34;N-th var_defs.name&amp;#34; is not freed.&lt;/p&gt;
&lt;p&gt;If enable CONFIG_DEBUG_KMEMLEAK and inject a fault at where the N-th
var_defs.expr a…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;tracing/histograms: Fix memory leak problem&lt;/p&gt;
&lt;p&gt;This reverts commit 46bbe5c671e06f070428b9be142cc4ee5cedebac.&lt;/p&gt;
&lt;p&gt;As commit 46bbe5c671e0 (&amp;#34;tracing: fix double free&amp;#34;) said, the
&amp;#34;double free&amp;#34; problem reported by clang static analyzer is:
  &amp;gt; In parse_var_defs() if there is a problem allocating
  &amp;gt; var_defs.expr, the earlier var_defs.name is freed.
  &amp;gt; This free is duplicated by free_var_defs() which frees
  &amp;gt; the rest of the list.&lt;/p&gt;
&lt;p&gt;However, if there is a problem allocating N-th var_defs.expr:
  + in parse_var_defs(), the freed &amp;#39;earlier var_defs.name&amp;#39; is
    actually the N-th var_defs.name;
  + then in free_var_defs(), the names from 0th to (N-1)-th are freed;&lt;/p&gt;
&lt;p&gt;IF ALLOCATING PROBLEM HAPPENED HERE!!! -+
                                                                 \
                                                                  |
          0th           1th                 (N-1)-th      N-th    V
          +-------------+-------------+-----+-------------+-----------
var_defs: | name | expr | name | expr | ... | name | expr | name | ///
          +-------------+-------------+-----+-------------+-----------&lt;/p&gt;
&lt;p&gt;These two frees don&amp;#39;t act on same name, so there was no &amp;#34;double free&amp;#34;
problem before. Conversely, after that commit, we get a &amp;#34;memory leak&amp;#34;
problem because the above &amp;#34;N-th var_defs.name&amp;#34; is not freed.&lt;/p&gt;
&lt;p&gt;If enable CONFIG_DEBUG_KMEMLEAK and inject a fault at where the N-th
var_defs.expr a…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/fkie_cve-2022-49648</guid>
    </item>
    <item>
      <title>GHSA-7rcj-vmjp-fwmv</title>
      <link>https://db.gcve.eu/vuln/ghsa-7rcj-vmjp-fwmv</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;tracing/histograms: Fix memory leak problem&lt;/p&gt;
&lt;p&gt;This reverts commit 46bbe5c671e06f070428b9be142cc4ee5cedebac.&lt;/p&gt;
&lt;p&gt;As commit 46bbe5c671e0 (&amp;#34;tracing: fix double free&amp;#34;) said, the
&amp;#34;double free&amp;#34; problem reported by clang static analyzer is:
  &amp;gt; In parse_var_defs() if there is a problem allocating
  &amp;gt; var_defs.expr, the earlier var_defs.name is freed.
  &amp;gt; This free is duplicated by free_var_defs() which frees
  &amp;gt; the rest of the list.&lt;/p&gt;
&lt;p&gt;However, if there is a problem allocating N-th var_defs.expr:
  + in parse_var_defs(), the freed &amp;#39;earlier var_defs.name&amp;#39; is
    actually the N-th var_defs.name;
  + then in free_var_defs(), the names from 0th to (N-1)-th are freed;&lt;/p&gt;
&lt;p&gt;IF ALLOCATING PROBLEM HAPPENED HERE!!! -+
                                                                 \
                                                                  |
          0th           1th                 (N-1)-th      N-th    V
          +-------------+-------------+-----+-------------+-----------
var_defs: | name | expr | name | expr | ... | name | expr | name | ///
          +-------------+-------------+-----+-------------+-----------&lt;/p&gt;
&lt;p&gt;These two frees don&amp;#39;t act on same name, so there was no &amp;#34;double free&amp;#34;
problem before. Conversely, after that commit, we get a &amp;#34;memory leak&amp;#34;
problem because the above &amp;#34;N-th var_defs.name&amp;#34; is not freed.&lt;/p&gt;
&lt;p&gt;If enable CONFIG_DEBUG_KMEMLEAK and inject a fault at where the N-th
var_defs.expr a…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;tracing/histograms: Fix memory leak problem&lt;/p&gt;
&lt;p&gt;This reverts commit 46bbe5c671e06f070428b9be142cc4ee5cedebac.&lt;/p&gt;
&lt;p&gt;As commit 46bbe5c671e0 (&amp;#34;tracing: fix double free&amp;#34;) said, the
&amp;#34;double free&amp;#34; problem reported by clang static analyzer is:
  &amp;gt; In parse_var_defs() if there is a problem allocating
  &amp;gt; var_defs.expr, the earlier var_defs.name is freed.
  &amp;gt; This free is duplicated by free_var_defs() which frees
  &amp;gt; the rest of the list.&lt;/p&gt;
&lt;p&gt;However, if there is a problem allocating N-th var_defs.expr:
  + in parse_var_defs(), the freed &amp;#39;earlier var_defs.name&amp;#39; is
    actually the N-th var_defs.name;
  + then in free_var_defs(), the names from 0th to (N-1)-th are freed;&lt;/p&gt;
&lt;p&gt;IF ALLOCATING PROBLEM HAPPENED HERE!!! -+
                                                                 \
                                                                  |
          0th           1th                 (N-1)-th      N-th    V
          +-------------+-------------+-----+-------------+-----------
var_defs: | name | expr | name | expr | ... | name | expr | name | ///
          +-------------+-------------+-----+-------------+-----------&lt;/p&gt;
&lt;p&gt;These two frees don&amp;#39;t act on same name, so there was no &amp;#34;double free&amp;#34;
problem before. Conversely, after that commit, we get a &amp;#34;memory leak&amp;#34;
problem because the above &amp;#34;N-th var_defs.name&amp;#34; is not freed.&lt;/p&gt;
&lt;p&gt;If enable CONFIG_DEBUG_KMEMLEAK and inject a fault at where the N-th
var_defs.expr a…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/ghsa-7rcj-vmjp-fwmv</guid>
    </item>
    <item>
      <title>OESA-2025-1282 — kernel security update</title>
      <link>https://db.gcve.eu/vuln/oesa-2025-1282</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; openEuler:20.03-LTS-SP4: kernel&lt;/p&gt;
&lt;p&gt;The Linux Kernel, the operating system core itself.&#13;
&#13;
Security Fix(es):&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;ARM: davinci: da850-evm: Avoid NULL pointer dereference&lt;/p&gt;
&lt;p&gt;With newer versions of GCC, there is a panic in da850_evm_config_emac()
when booting multi_v5_defconfig in QEMU under the palmetto-bmc machine:&lt;/p&gt;
&lt;p&gt;Unable to handle kernel NULL pointer dereference at virtual address 00000020
pgd = (ptrval)
[00000020] *pgd=00000000
Internal error: Oops: 5 [#1] PREEMPT ARM
Modules linked in:
CPU: 0 PID: 1 Comm: swapper Not tainted 5.15.0 #1
Hardware name: Generic DT based system
PC is at da850_evm_config_emac+0x1c/0x120
LR is at do_one_initcall+0x50/0x1e0&lt;/p&gt;
&lt;p&gt;The emac_pdata pointer in soc_info is NULL because davinci_soc_info only
gets populated on davinci machines but da850_evm_config_emac() is called
on all machines via device_initcall().&lt;/p&gt;
&lt;p&gt;Move the rmii_en assignment below the machine check so that it is only
dereferenced when running on a supported SoC.(CVE-2021-47631)&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;video: fbdev: nvidiafb: Use strscpy() to prevent buffer overflow&lt;/p&gt;
&lt;p&gt;Coverity complains of a possible buffer overflow. However,
given the &amp;amp;apos;static&amp;amp;apos; scope of nvidia_setup_i2c_bus() it looks
like that can&amp;amp;apos;t happen after examiniing the call sites.&lt;/p&gt;
&lt;p&gt;CID 19036 (#1 of 1): Copy into fixed size buffer (STRING_OVERFLOW)
1. fixed_size_dest: You might overrun the 48-character fixed-size string
  chan-&amp;amp;gt;adapter.name…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; openEuler:20.03-LTS-SP4: kernel&lt;/p&gt;
&lt;p&gt;The Linux Kernel, the operating system core itself.&#13;
&#13;
Security Fix(es):&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;ARM: davinci: da850-evm: Avoid NULL pointer dereference&lt;/p&gt;
&lt;p&gt;With newer versions of GCC, there is a panic in da850_evm_config_emac()
when booting multi_v5_defconfig in QEMU under the palmetto-bmc machine:&lt;/p&gt;
&lt;p&gt;Unable to handle kernel NULL pointer dereference at virtual address 00000020
pgd = (ptrval)
[00000020] *pgd=00000000
Internal error: Oops: 5 [#1] PREEMPT ARM
Modules linked in:
CPU: 0 PID: 1 Comm: swapper Not tainted 5.15.0 #1
Hardware name: Generic DT based system
PC is at da850_evm_config_emac+0x1c/0x120
LR is at do_one_initcall+0x50/0x1e0&lt;/p&gt;
&lt;p&gt;The emac_pdata pointer in soc_info is NULL because davinci_soc_info only
gets populated on davinci machines but da850_evm_config_emac() is called
on all machines via device_initcall().&lt;/p&gt;
&lt;p&gt;Move the rmii_en assignment below the machine check so that it is only
dereferenced when running on a supported SoC.(CVE-2021-47631)&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;video: fbdev: nvidiafb: Use strscpy() to prevent buffer overflow&lt;/p&gt;
&lt;p&gt;Coverity complains of a possible buffer overflow. However,
given the &amp;amp;apos;static&amp;amp;apos; scope of nvidia_setup_i2c_bus() it looks
like that can&amp;amp;apos;t happen after examiniing the call sites.&lt;/p&gt;
&lt;p&gt;CID 19036 (#1 of 1): Copy into fixed size buffer (STRING_OVERFLOW)
1. fixed_size_dest: You might overrun the 48-character fixed-size string
  chan-&amp;amp;gt;adapter.name…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/oesa-2025-1282</guid>
    </item>
    <item>
      <title>RHSA-2025:20518 — Red Hat Security Advisory: kernel security update</title>
      <link>https://db.gcve.eu/vuln/rhsa-2025:20518</link>
      <description>&lt;p&gt;kernel: can: isotp: fix potential CAN frame reception race in isotp_rcv() kernel: can: m_can: pci: add missing m_can_class_free_dev() in probe/remove methods kernel: can: isotp: sanitize CAN ID checks in isotp_bind() kernel: powerpc/papr_scm: don&amp;#39;t requests stats with &amp;#39;0&amp;#39; sized stats buffer kernel: efi: Do not import certificates from UEFI Secure Boot for T2 Macs kernel: powerpc/xics: fix refcount leak in icp_opal_init() kernel: powerpc/xive: Fix refcount leak in xive_spapr_init kernel: list: fix a data-race around ep-&amp;gt;rdllist kernel: powerpc/xive/spapr: correct bitmap allocation size kernel: ima: Fix potential memory leak in ima_init_crypto() kernel: ima: Fix a potential integer overflow in ima_appraise_measurement kernel: tracing/histograms: Fix memory leak problem kernel: usbnet: fix memory leak in error case kernel: linux/dim: Fix divide by 0 in RDMA DIM kernel: net: tun: unlink NAPI from device on destruction kernel: can: j1939: j1939_send_one(): fix missing CAN header initialization kernel: intel_th: Fix a resource leak in an error handling path kernel: powerpc/rtas: avoid scheduling in rtas_os_term() kernel: can: isotp: split tx timer into transmission and timeout kernel: Linux kernel: Denial of Service in xsk_diag due to use-after-free during socket cleanup kernel: smc: Fix use-after-free in tcp_write_timer_handler() kernel: inotify: Avoid reporting event with invalid wd kernel: Linux kernel (CAN J1939): Denial of Service via deadlock kernel: net/smc: fix potential p…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;kernel: can: isotp: fix potential CAN frame reception race in isotp_rcv() kernel: can: m_can: pci: add missing m_can_class_free_dev() in probe/remove methods kernel: can: isotp: sanitize CAN ID checks in isotp_bind() kernel: powerpc/papr_scm: don&amp;#39;t requests stats with &amp;#39;0&amp;#39; sized stats buffer kernel: efi: Do not import certificates from UEFI Secure Boot for T2 Macs kernel: powerpc/xics: fix refcount leak in icp_opal_init() kernel: powerpc/xive: Fix refcount leak in xive_spapr_init kernel: list: fix a data-race around ep-&amp;gt;rdllist kernel: powerpc/xive/spapr: correct bitmap allocation size kernel: ima: Fix potential memory leak in ima_init_crypto() kernel: ima: Fix a potential integer overflow in ima_appraise_measurement kernel: tracing/histograms: Fix memory leak problem kernel: usbnet: fix memory leak in error case kernel: linux/dim: Fix divide by 0 in RDMA DIM kernel: net: tun: unlink NAPI from device on destruction kernel: can: j1939: j1939_send_one(): fix missing CAN header initialization kernel: intel_th: Fix a resource leak in an error handling path kernel: powerpc/rtas: avoid scheduling in rtas_os_term() kernel: can: isotp: split tx timer into transmission and timeout kernel: Linux kernel: Denial of Service in xsk_diag due to use-after-free during socket cleanup kernel: smc: Fix use-after-free in tcp_write_timer_handler() kernel: inotify: Avoid reporting event with invalid wd kernel: Linux kernel (CAN J1939): Denial of Service via deadlock kernel: net/smc: fix potential p…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/rhsa-2025:20518</guid>
    </item>
    <item>
      <title>SUSE-SU-2025:1027-1 — Security update for the Linux Kernel</title>
      <link>https://db.gcve.eu/vuln/suse-su-2025:1027-1</link>
      <description>&lt;p&gt;Security update for the Linux Kernel&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Security update for the Linux Kernel&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/suse-su-2025:1027-1</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2022-49648</title>
      <link>https://db.gcve.eu/vuln/ubuntu-cve-2022-49648</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:16.04:LTS: linux-hwe-edge, Ubuntu:18.04:LTS: linux-aws-5.4, Ubuntu:18.04:LTS: linux-azure-5.4, Ubuntu:18.04:LTS: linux-gcp-5.4, Ubuntu:18.04:LTS: linux-hwe-5.4, Ubuntu:18.04:LTS: linux-ibm-5.4, Ubuntu:18.04:LTS: linux-oracle-5.4, Ubuntu:18.04:LTS: linux-raspi-5.4, Ubuntu:18.04:LTS: linux-aws-5.0, Ubuntu:18.04:LTS: linux-aws-5.3 and 114 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: tracing/histograms: Fix memory leak problem This reverts commit 46bbe5c671e06f070428b9be142cc4ee5cedebac. As commit 46bbe5c671e0 (&amp;#34;tracing: fix double free&amp;#34;) said, the &amp;#34;double free&amp;#34; problem reported by clang static analyzer is:   &amp;gt; In parse_var_defs() if there is a problem allocating   &amp;gt; var_defs.expr, the earlier var_defs.name is freed.   &amp;gt; This free is duplicated by free_var_defs() which frees   &amp;gt; the rest of the list. However, if there is a problem allocating N-th var_defs.expr:   + in parse_var_defs(), the freed &amp;#39;earlier var_defs.name&amp;#39; 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&amp;#39;t act on same name, so there was no &amp;#34;double free&amp;#34; problem before. Conversely, after that commit, we get a &amp;#34;memory leak&amp;#34; problem because the above &amp;#34;N-th var_defs.name&amp;#34; is not freed. If enable CONFIG_DEBUG_KMEMLEAK and inject a fault at where the N-th var_defs.expr allocate…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:16.04:LTS: linux-hwe-edge, Ubuntu:18.04:LTS: linux-aws-5.4, Ubuntu:18.04:LTS: linux-azure-5.4, Ubuntu:18.04:LTS: linux-gcp-5.4, Ubuntu:18.04:LTS: linux-hwe-5.4, Ubuntu:18.04:LTS: linux-ibm-5.4, Ubuntu:18.04:LTS: linux-oracle-5.4, Ubuntu:18.04:LTS: linux-raspi-5.4, Ubuntu:18.04:LTS: linux-aws-5.0, Ubuntu:18.04:LTS: linux-aws-5.3 and 114 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: tracing/histograms: Fix memory leak problem This reverts commit 46bbe5c671e06f070428b9be142cc4ee5cedebac. As commit 46bbe5c671e0 (&amp;#34;tracing: fix double free&amp;#34;) said, the &amp;#34;double free&amp;#34; problem reported by clang static analyzer is:   &amp;gt; In parse_var_defs() if there is a problem allocating   &amp;gt; var_defs.expr, the earlier var_defs.name is freed.   &amp;gt; This free is duplicated by free_var_defs() which frees   &amp;gt; the rest of the list. However, if there is a problem allocating N-th var_defs.expr:   + in parse_var_defs(), the freed &amp;#39;earlier var_defs.name&amp;#39; 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&amp;#39;t act on same name, so there was no &amp;#34;double free&amp;#34; problem before. Conversely, after that commit, we get a &amp;#34;memory leak&amp;#34; problem because the above &amp;#34;N-th var_defs.name&amp;#34; is not freed. If enable CONFIG_DEBUG_KMEMLEAK and inject a fault at where the N-th var_defs.expr allocate…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/ubuntu-cve-2022-49648</guid>
    </item>
  </channel>
</rss>
