<?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://cve.radiocsirt.org</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, 03 Oct 2026 10:30:38 +0000</lastBuildDate>
    <item>
      <title>bdu:2024-09139</title>
      <link>https://cve.radiocsirt.org/vuln/bdu:2024-09139</link>
      <description>bdu:2024-09139</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bdu:2024-09139</guid>
    </item>
    <item>
      <title>certfr-2024-avi-0420 — 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://cve.radiocsirt.org/vuln/certfr-2024-avi-0420</link>
      <description>certfr-2024-avi-0420</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/certfr-2024-avi-0420</guid>
    </item>
    <item>
      <title>EUVD-2026-309590</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-309590</link>
      <description>EUVD-2026-309590</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-309590</guid>
    </item>
    <item>
      <title>fkie_cve-2021-47199</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2021-47199</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;net/mlx5e: CT, Fix multiple allocations and memleak of mod acts&lt;/p&gt;
&lt;p&gt;CT clear action offload adds additional mod hdr actions to the
flow&amp;#39;s original mod actions in order to clear the registers which
hold ct_state.
When such flow also includes encap action, a neigh update event
can cause the driver to unoffload the flow and then reoffload it.&lt;/p&gt;
&lt;p&gt;Each time this happens, the ct clear handling adds that same set
of mod hdr actions to reset ct_state until the max of mod hdr
actions is reached.&lt;/p&gt;
&lt;p&gt;Also the driver never releases the allocated mod hdr actions and
causing a memleak.&lt;/p&gt;
&lt;p&gt;Fix above two issues by moving CT clear mod acts allocation
into the parsing actions phase and only use it when offloading the rule.
The release of mod acts will be done in the normal flow_put().&lt;/p&gt;
&lt;p&gt;backtrace:
    [&amp;lt;000000007316e2f3&amp;gt;] krealloc+0x83/0xd0
    [&amp;lt;00000000ef157de1&amp;gt;] mlx5e_mod_hdr_alloc+0x147/0x300 [mlx5_core]
    [&amp;lt;00000000970ce4ae&amp;gt;] mlx5e_tc_match_to_reg_set_and_get_id+0xd7/0x240 [mlx5_core]
    [&amp;lt;0000000067c5fa17&amp;gt;] mlx5e_tc_match_to_reg_set+0xa/0x20 [mlx5_core]
    [&amp;lt;00000000d032eb98&amp;gt;] mlx5_tc_ct_entry_set_registers.isra.0+0x36/0xc0 [mlx5_core]
    [&amp;lt;00000000fd23b869&amp;gt;] mlx5_tc_ct_flow_offload+0x272/0x1f10 [mlx5_core]
    [&amp;lt;000000004fc24acc&amp;gt;] mlx5e_tc_offload_fdb_rules.part.0+0x150/0x620 [mlx5_core]
    [&amp;lt;00000000dc741c17&amp;gt;] mlx5e_tc_encap_flows_add+0x489/0x690 [mlx5_core]
    [&amp;lt;00000000e92e49d7&amp;gt;] mlx5e_rep_update_flows+0x6e4/0x9b0 [m…&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;net/mlx5e: CT, Fix multiple allocations and memleak of mod acts&lt;/p&gt;
&lt;p&gt;CT clear action offload adds additional mod hdr actions to the
flow&amp;#39;s original mod actions in order to clear the registers which
hold ct_state.
When such flow also includes encap action, a neigh update event
can cause the driver to unoffload the flow and then reoffload it.&lt;/p&gt;
&lt;p&gt;Each time this happens, the ct clear handling adds that same set
of mod hdr actions to reset ct_state until the max of mod hdr
actions is reached.&lt;/p&gt;
&lt;p&gt;Also the driver never releases the allocated mod hdr actions and
causing a memleak.&lt;/p&gt;
&lt;p&gt;Fix above two issues by moving CT clear mod acts allocation
into the parsing actions phase and only use it when offloading the rule.
The release of mod acts will be done in the normal flow_put().&lt;/p&gt;
&lt;p&gt;backtrace:
    [&amp;lt;000000007316e2f3&amp;gt;] krealloc+0x83/0xd0
    [&amp;lt;00000000ef157de1&amp;gt;] mlx5e_mod_hdr_alloc+0x147/0x300 [mlx5_core]
    [&amp;lt;00000000970ce4ae&amp;gt;] mlx5e_tc_match_to_reg_set_and_get_id+0xd7/0x240 [mlx5_core]
    [&amp;lt;0000000067c5fa17&amp;gt;] mlx5e_tc_match_to_reg_set+0xa/0x20 [mlx5_core]
    [&amp;lt;00000000d032eb98&amp;gt;] mlx5_tc_ct_entry_set_registers.isra.0+0x36/0xc0 [mlx5_core]
    [&amp;lt;00000000fd23b869&amp;gt;] mlx5_tc_ct_flow_offload+0x272/0x1f10 [mlx5_core]
    [&amp;lt;000000004fc24acc&amp;gt;] mlx5e_tc_offload_fdb_rules.part.0+0x150/0x620 [mlx5_core]
    [&amp;lt;00000000dc741c17&amp;gt;] mlx5e_tc_encap_flows_add+0x489/0x690 [mlx5_core]
    [&amp;lt;00000000e92e49d7&amp;gt;] mlx5e_rep_update_flows+0x6e4/0x9b0 [m…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2021-47199</guid>
    </item>
    <item>
      <title>GHSA-q54v-653w-2v9v</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-q54v-653w-2v9v</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;net/mlx5e: CT, Fix multiple allocations and memleak of mod acts&lt;/p&gt;
&lt;p&gt;CT clear action offload adds additional mod hdr actions to the
flow&amp;#39;s original mod actions in order to clear the registers which
hold ct_state.
When such flow also includes encap action, a neigh update event
can cause the driver to unoffload the flow and then reoffload it.&lt;/p&gt;
&lt;p&gt;Each time this happens, the ct clear handling adds that same set
of mod hdr actions to reset ct_state until the max of mod hdr
actions is reached.&lt;/p&gt;
&lt;p&gt;Also the driver never releases the allocated mod hdr actions and
causing a memleak.&lt;/p&gt;
&lt;p&gt;Fix above two issues by moving CT clear mod acts allocation
into the parsing actions phase and only use it when offloading the rule.
The release of mod acts will be done in the normal flow_put().&lt;/p&gt;
&lt;p&gt;backtrace:
    [&amp;lt;000000007316e2f3&amp;gt;] krealloc+0x83/0xd0
    [&amp;lt;00000000ef157de1&amp;gt;] mlx5e_mod_hdr_alloc+0x147/0x300 [mlx5_core]
    [&amp;lt;00000000970ce4ae&amp;gt;] mlx5e_tc_match_to_reg_set_and_get_id+0xd7/0x240 [mlx5_core]
    [&amp;lt;0000000067c5fa17&amp;gt;] mlx5e_tc_match_to_reg_set+0xa/0x20 [mlx5_core]
    [&amp;lt;00000000d032eb98&amp;gt;] mlx5_tc_ct_entry_set_registers.isra.0+0x36/0xc0 [mlx5_core]
    [&amp;lt;00000000fd23b869&amp;gt;] mlx5_tc_ct_flow_offload+0x272/0x1f10 [mlx5_core]
    [&amp;lt;000000004fc24acc&amp;gt;] mlx5e_tc_offload_fdb_rules.part.0+0x150/0x620 [mlx5_core]
    [&amp;lt;00000000dc741c17&amp;gt;] mlx5e_tc_encap_flows_add+0x489/0x690 [mlx5_core]
    [&amp;lt;00000000e92e49d7&amp;gt;] mlx5e_rep_update_flows+0x6e4/0x9b0 [m…&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;net/mlx5e: CT, Fix multiple allocations and memleak of mod acts&lt;/p&gt;
&lt;p&gt;CT clear action offload adds additional mod hdr actions to the
flow&amp;#39;s original mod actions in order to clear the registers which
hold ct_state.
When such flow also includes encap action, a neigh update event
can cause the driver to unoffload the flow and then reoffload it.&lt;/p&gt;
&lt;p&gt;Each time this happens, the ct clear handling adds that same set
of mod hdr actions to reset ct_state until the max of mod hdr
actions is reached.&lt;/p&gt;
&lt;p&gt;Also the driver never releases the allocated mod hdr actions and
causing a memleak.&lt;/p&gt;
&lt;p&gt;Fix above two issues by moving CT clear mod acts allocation
into the parsing actions phase and only use it when offloading the rule.
The release of mod acts will be done in the normal flow_put().&lt;/p&gt;
&lt;p&gt;backtrace:
    [&amp;lt;000000007316e2f3&amp;gt;] krealloc+0x83/0xd0
    [&amp;lt;00000000ef157de1&amp;gt;] mlx5e_mod_hdr_alloc+0x147/0x300 [mlx5_core]
    [&amp;lt;00000000970ce4ae&amp;gt;] mlx5e_tc_match_to_reg_set_and_get_id+0xd7/0x240 [mlx5_core]
    [&amp;lt;0000000067c5fa17&amp;gt;] mlx5e_tc_match_to_reg_set+0xa/0x20 [mlx5_core]
    [&amp;lt;00000000d032eb98&amp;gt;] mlx5_tc_ct_entry_set_registers.isra.0+0x36/0xc0 [mlx5_core]
    [&amp;lt;00000000fd23b869&amp;gt;] mlx5_tc_ct_flow_offload+0x272/0x1f10 [mlx5_core]
    [&amp;lt;000000004fc24acc&amp;gt;] mlx5e_tc_offload_fdb_rules.part.0+0x150/0x620 [mlx5_core]
    [&amp;lt;00000000dc741c17&amp;gt;] mlx5e_tc_encap_flows_add+0x489/0x690 [mlx5_core]
    [&amp;lt;00000000e92e49d7&amp;gt;] mlx5e_rep_update_flows+0x6e4/0x9b0 [m…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-q54v-653w-2v9v</guid>
    </item>
    <item>
      <title>gsd-2021-47199</title>
      <link>https://cve.radiocsirt.org/vuln/gsd-2021-47199</link>
      <description>gsd-2021-47199</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/gsd-2021-47199</guid>
    </item>
    <item>
      <title>OESA-2024-1566 — kernel security update</title>
      <link>https://cve.radiocsirt.org/vuln/oesa-2024-1566</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; openEuler:22.03-LTS-SP3: kernel&lt;/p&gt;
&lt;p&gt;The Linux Kernel, the operating system core itself.&#13;
&#13;
Security Fix(es):&#13;
&#13;
In the Linux kernel, the following vulnerability has been resolved:&#13;
&#13;
scsi: core: Fix scsi_mode_sense() buffer length handling&#13;
&#13;
Several problems exist with scsi_mode_sense() buffer length handling:&#13;
&#13;
 1) The allocation length field of the MODE SENSE(10) command is 16-bits,
    occupying bytes 7 and 8 of the CDB. With this command, access to mode
    pages larger than 255 bytes is thus possible. However, the CDB
    allocation length field is set by assigning len to byte 8 only, thus
    truncating buffer length larger than 255.&#13;
&#13;
 2) If scsi_mode_sense() is called with len smaller than 8 with
    sdev-&amp;amp;gt;use_10_for_ms set, or smaller than 4 otherwise, the buffer length
    is increased to 8 and 4 respectively, and the buffer is zero filled
    with these increased values, thus corrupting the memory following the
    buffer.&#13;
&#13;
Fix these 2 problems by using put_unaligned_be16() to set the allocation
length field of MODE SENSE(10) CDB and by returning an error when len is
too small.&#13;
&#13;
Furthermore, if len is larger than 255B, always try MODE SENSE(10) first,
even if the device driver did not set sdev-&amp;amp;gt;use_10_for_ms. In case of
invalid opcode error for MODE SENSE(10), access to mode pages larger than
255 bytes are not retried using MODE SENSE(6). To avoid buffer length
overflows for the MODE_SENSE(10) case, check that len is smaller than 65535
bytes.&#13;
&#13;
While at it, also fix the folowing:&#13;
&#13;
 *…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; openEuler:22.03-LTS-SP3: kernel&lt;/p&gt;
&lt;p&gt;The Linux Kernel, the operating system core itself.&#13;
&#13;
Security Fix(es):&#13;
&#13;
In the Linux kernel, the following vulnerability has been resolved:&#13;
&#13;
scsi: core: Fix scsi_mode_sense() buffer length handling&#13;
&#13;
Several problems exist with scsi_mode_sense() buffer length handling:&#13;
&#13;
 1) The allocation length field of the MODE SENSE(10) command is 16-bits,
    occupying bytes 7 and 8 of the CDB. With this command, access to mode
    pages larger than 255 bytes is thus possible. However, the CDB
    allocation length field is set by assigning len to byte 8 only, thus
    truncating buffer length larger than 255.&#13;
&#13;
 2) If scsi_mode_sense() is called with len smaller than 8 with
    sdev-&amp;amp;gt;use_10_for_ms set, or smaller than 4 otherwise, the buffer length
    is increased to 8 and 4 respectively, and the buffer is zero filled
    with these increased values, thus corrupting the memory following the
    buffer.&#13;
&#13;
Fix these 2 problems by using put_unaligned_be16() to set the allocation
length field of MODE SENSE(10) CDB and by returning an error when len is
too small.&#13;
&#13;
Furthermore, if len is larger than 255B, always try MODE SENSE(10) first,
even if the device driver did not set sdev-&amp;amp;gt;use_10_for_ms. In case of
invalid opcode error for MODE SENSE(10), access to mode pages larger than
255 bytes are not retried using MODE SENSE(6). To avoid buffer length
overflows for the MODE_SENSE(10) case, check that len is smaller than 65535
bytes.&#13;
&#13;
While at it, also fix the folowing:&#13;
&#13;
 *…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/oesa-2024-1566</guid>
    </item>
    <item>
      <title>SUSE-SU-2024:1644-1 — Security update for the Linux Kernel</title>
      <link>https://cve.radiocsirt.org/vuln/suse-su-2024:1644-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://cve.radiocsirt.org/vuln/suse-su-2024:1644-1</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2021-47199</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2021-47199</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.0, Ubuntu:18.04:LTS: linux-aws-5.3, Ubuntu:18.04:LTS: linux-azure, Ubuntu:18.04:LTS: linux-azure-5.3, Ubuntu:18.04:LTS: linux-azure-edge, Ubuntu:18.04:LTS: linux-gcp, Ubuntu:18.04:LTS: linux-gcp-5.3, Ubuntu:18.04:LTS: linux-gke-4.15, Ubuntu:18.04:LTS: linux-gke-5.4 and 57 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: CT, Fix multiple allocations and memleak of mod acts CT clear action offload adds additional mod hdr actions to the flow&amp;#39;s original mod actions in order to clear the registers which hold ct_state. When such flow also includes encap action, a neigh update event can cause the driver to unoffload the flow and then reoffload it. Each time this happens, the ct clear handling adds that same set of mod hdr actions to reset ct_state until the max of mod hdr actions is reached. Also the driver never releases the allocated mod hdr actions and causing a memleak. Fix above two issues by moving CT clear mod acts allocation into the parsing actions phase and only use it when offloading the rule. The release of mod acts will be done in the normal flow_put().  backtrace:     [&amp;lt;000000007316e2f3&amp;gt;] krealloc+0x83/0xd0     [&amp;lt;00000000ef157de1&amp;gt;] mlx5e_mod_hdr_alloc+0x147/0x300 [mlx5_core]     [&amp;lt;00000000970ce4ae&amp;gt;] mlx5e_tc_match_to_reg_set_and_get_id+0xd7/0x240 [mlx5_core]     [&amp;lt;0000000067c5fa17&amp;gt;] mlx5e_tc_match_to_reg_set+0xa/0x20 [mlx5_core]     [&amp;lt;00000000d032eb98&amp;gt;] mlx5_tc_ct_entry_set_registers.isra.0+0x36/0xc0 [mlx5_core]     [&amp;lt;00000000fd23b869&amp;gt;] mlx5_tc_ct_flow_offload+0x272/0x1f10 [mlx5_core]     [&amp;lt;000000004fc24acc&amp;gt;] mlx5e_tc_offload_fdb_rules.part.0+0x150/0x620 [mlx5_core]     [&amp;lt;00000000dc741c17&amp;gt;] mlx5e_tc_encap_flows_add+0x489/0x690 [mlx5_core]     [&amp;lt;00000000e92e49d7&amp;gt;] mlx5e_rep_update_flows+0x6e4/0x9b0 [mlx5_co…&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.0, Ubuntu:18.04:LTS: linux-aws-5.3, Ubuntu:18.04:LTS: linux-azure, Ubuntu:18.04:LTS: linux-azure-5.3, Ubuntu:18.04:LTS: linux-azure-edge, Ubuntu:18.04:LTS: linux-gcp, Ubuntu:18.04:LTS: linux-gcp-5.3, Ubuntu:18.04:LTS: linux-gke-4.15, Ubuntu:18.04:LTS: linux-gke-5.4 and 57 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: CT, Fix multiple allocations and memleak of mod acts CT clear action offload adds additional mod hdr actions to the flow&amp;#39;s original mod actions in order to clear the registers which hold ct_state. When such flow also includes encap action, a neigh update event can cause the driver to unoffload the flow and then reoffload it. Each time this happens, the ct clear handling adds that same set of mod hdr actions to reset ct_state until the max of mod hdr actions is reached. Also the driver never releases the allocated mod hdr actions and causing a memleak. Fix above two issues by moving CT clear mod acts allocation into the parsing actions phase and only use it when offloading the rule. The release of mod acts will be done in the normal flow_put().  backtrace:     [&amp;lt;000000007316e2f3&amp;gt;] krealloc+0x83/0xd0     [&amp;lt;00000000ef157de1&amp;gt;] mlx5e_mod_hdr_alloc+0x147/0x300 [mlx5_core]     [&amp;lt;00000000970ce4ae&amp;gt;] mlx5e_tc_match_to_reg_set_and_get_id+0xd7/0x240 [mlx5_core]     [&amp;lt;0000000067c5fa17&amp;gt;] mlx5e_tc_match_to_reg_set+0xa/0x20 [mlx5_core]     [&amp;lt;00000000d032eb98&amp;gt;] mlx5_tc_ct_entry_set_registers.isra.0+0x36/0xc0 [mlx5_core]     [&amp;lt;00000000fd23b869&amp;gt;] mlx5_tc_ct_flow_offload+0x272/0x1f10 [mlx5_core]     [&amp;lt;000000004fc24acc&amp;gt;] mlx5e_tc_offload_fdb_rules.part.0+0x150/0x620 [mlx5_core]     [&amp;lt;00000000dc741c17&amp;gt;] mlx5e_tc_encap_flows_add+0x489/0x690 [mlx5_core]     [&amp;lt;00000000e92e49d7&amp;gt;] mlx5e_rep_update_flows+0x6e4/0x9b0 [mlx5_co…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2021-47199</guid>
    </item>
    <item>
      <title>WID-SEC-W-2024-0851 — Linux Kernel: Mehrere Schwachstellen</title>
      <link>https://cve.radiocsirt.org/vuln/wid-sec-w-2024-0851</link>
      <description>&lt;p&gt;Ein lokaler Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen Denial of Service Angriff durchzuführen oder unbekannte Auswirkungen zu verursachen.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Ein lokaler Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen Denial of Service Angriff durchzuführen oder unbekannte Auswirkungen zu verursachen.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/wid-sec-w-2024-0851</guid>
    </item>
  </channel>
</rss>
