<?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 00:43:17 +0000</lastBuildDate>
    <item>
      <title>bdu:2025-06065</title>
      <link>https://cve.radiocsirt.org/vuln/bdu:2025-06065</link>
      <description>bdu:2025-06065</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bdu:2025-06065</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://cve.radiocsirt.org/vuln/certfr-2025-avi-0252</link>
      <description>certfr-2025-avi-0252</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/certfr-2025-avi-0252</guid>
    </item>
    <item>
      <title>EUVD-2026-310332</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-310332</link>
      <description>EUVD-2026-310332</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-310332</guid>
    </item>
    <item>
      <title>fkie_cve-2022-49086</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2022-49086</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;net: openvswitch: fix leak of nested actions&lt;/p&gt;
&lt;p&gt;While parsing user-provided actions, openvswitch module may dynamically
allocate memory and store pointers in the internal copy of the actions.
So this memory has to be freed while destroying the actions.&lt;/p&gt;
&lt;p&gt;Currently there are only two such actions: ct() and set().  However,
there are many actions that can hold nested lists of actions and
ovs_nla_free_flow_actions() just jumps over them leaking the memory.&lt;/p&gt;
&lt;p&gt;For example, removal of the flow with the following actions will lead
to a leak of the memory allocated by nf_ct_tmpl_alloc():&lt;/p&gt;
&lt;p&gt;actions:clone(ct(commit),0)&lt;/p&gt;
&lt;p&gt;Non-freed set() action may also leak the &amp;#39;dst&amp;#39; structure for the
tunnel info including device references.&lt;/p&gt;
&lt;p&gt;Under certain conditions with a high rate of flow rotation that may
cause significant memory leak problem (2MB per second in reporter&amp;#39;s
case).  The problem is also hard to mitigate, because the user doesn&amp;#39;t
have direct control over the datapath flows generated by OVS.&lt;/p&gt;
&lt;p&gt;Fix that by iterating over all the nested actions and freeing
everything that needs to be freed recursively.&lt;/p&gt;
&lt;p&gt;New build time assertion should protect us from this problem if new
actions will be added in the future.&lt;/p&gt;
&lt;p&gt;Unfortunately, openvswitch module doesn&amp;#39;t use NLA_F_NESTED, so all
attributes has to be explicitly checked.  sample() and clone() actions
are mixing extra attributes into the user-provided action list.  That
prevents some…&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: openvswitch: fix leak of nested actions&lt;/p&gt;
&lt;p&gt;While parsing user-provided actions, openvswitch module may dynamically
allocate memory and store pointers in the internal copy of the actions.
So this memory has to be freed while destroying the actions.&lt;/p&gt;
&lt;p&gt;Currently there are only two such actions: ct() and set().  However,
there are many actions that can hold nested lists of actions and
ovs_nla_free_flow_actions() just jumps over them leaking the memory.&lt;/p&gt;
&lt;p&gt;For example, removal of the flow with the following actions will lead
to a leak of the memory allocated by nf_ct_tmpl_alloc():&lt;/p&gt;
&lt;p&gt;actions:clone(ct(commit),0)&lt;/p&gt;
&lt;p&gt;Non-freed set() action may also leak the &amp;#39;dst&amp;#39; structure for the
tunnel info including device references.&lt;/p&gt;
&lt;p&gt;Under certain conditions with a high rate of flow rotation that may
cause significant memory leak problem (2MB per second in reporter&amp;#39;s
case).  The problem is also hard to mitigate, because the user doesn&amp;#39;t
have direct control over the datapath flows generated by OVS.&lt;/p&gt;
&lt;p&gt;Fix that by iterating over all the nested actions and freeing
everything that needs to be freed recursively.&lt;/p&gt;
&lt;p&gt;New build time assertion should protect us from this problem if new
actions will be added in the future.&lt;/p&gt;
&lt;p&gt;Unfortunately, openvswitch module doesn&amp;#39;t use NLA_F_NESTED, so all
attributes has to be explicitly checked.  sample() and clone() actions
are mixing extra attributes into the user-provided action list.  That
prevents some…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2022-49086</guid>
    </item>
    <item>
      <title>GHSA-jpcv-cqh9-hpf3</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-jpcv-cqh9-hpf3</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;net: openvswitch: fix leak of nested actions&lt;/p&gt;
&lt;p&gt;While parsing user-provided actions, openvswitch module may dynamically
allocate memory and store pointers in the internal copy of the actions.
So this memory has to be freed while destroying the actions.&lt;/p&gt;
&lt;p&gt;Currently there are only two such actions: ct() and set().  However,
there are many actions that can hold nested lists of actions and
ovs_nla_free_flow_actions() just jumps over them leaking the memory.&lt;/p&gt;
&lt;p&gt;For example, removal of the flow with the following actions will lead
to a leak of the memory allocated by nf_ct_tmpl_alloc():&lt;/p&gt;
&lt;p&gt;actions:clone(ct(commit),0)&lt;/p&gt;
&lt;p&gt;Non-freed set() action may also leak the &amp;#39;dst&amp;#39; structure for the
tunnel info including device references.&lt;/p&gt;
&lt;p&gt;Under certain conditions with a high rate of flow rotation that may
cause significant memory leak problem (2MB per second in reporter&amp;#39;s
case).  The problem is also hard to mitigate, because the user doesn&amp;#39;t
have direct control over the datapath flows generated by OVS.&lt;/p&gt;
&lt;p&gt;Fix that by iterating over all the nested actions and freeing
everything that needs to be freed recursively.&lt;/p&gt;
&lt;p&gt;New build time assertion should protect us from this problem if new
actions will be added in the future.&lt;/p&gt;
&lt;p&gt;Unfortunately, openvswitch module doesn&amp;#39;t use NLA_F_NESTED, so all
attributes has to be explicitly checked.  sample() and clone() actions
are mixing extra attributes into the user-provided action list.  That
prevents some…&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: openvswitch: fix leak of nested actions&lt;/p&gt;
&lt;p&gt;While parsing user-provided actions, openvswitch module may dynamically
allocate memory and store pointers in the internal copy of the actions.
So this memory has to be freed while destroying the actions.&lt;/p&gt;
&lt;p&gt;Currently there are only two such actions: ct() and set().  However,
there are many actions that can hold nested lists of actions and
ovs_nla_free_flow_actions() just jumps over them leaking the memory.&lt;/p&gt;
&lt;p&gt;For example, removal of the flow with the following actions will lead
to a leak of the memory allocated by nf_ct_tmpl_alloc():&lt;/p&gt;
&lt;p&gt;actions:clone(ct(commit),0)&lt;/p&gt;
&lt;p&gt;Non-freed set() action may also leak the &amp;#39;dst&amp;#39; structure for the
tunnel info including device references.&lt;/p&gt;
&lt;p&gt;Under certain conditions with a high rate of flow rotation that may
cause significant memory leak problem (2MB per second in reporter&amp;#39;s
case).  The problem is also hard to mitigate, because the user doesn&amp;#39;t
have direct control over the datapath flows generated by OVS.&lt;/p&gt;
&lt;p&gt;Fix that by iterating over all the nested actions and freeing
everything that needs to be freed recursively.&lt;/p&gt;
&lt;p&gt;New build time assertion should protect us from this problem if new
actions will be added in the future.&lt;/p&gt;
&lt;p&gt;Unfortunately, openvswitch module doesn&amp;#39;t use NLA_F_NESTED, so all
attributes has to be explicitly checked.  sample() and clone() actions
are mixing extra attributes into the user-provided action list.  That
prevents some…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-jpcv-cqh9-hpf3</guid>
    </item>
    <item>
      <title>OESA-2025-1465 — kernel security update</title>
      <link>https://cve.radiocsirt.org/vuln/oesa-2025-1465</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;can: dev: can_get_echo_skb(): prevent call to kfree_skb() in hard IRQ context&lt;/p&gt;
&lt;p&gt;If a driver calls can_get_echo_skb() during a hardware IRQ (which is often, but
not always, the case), the &amp;amp;apos;WARN_ON(in_irq)&amp;amp;apos; in
net/core/skbuff.c#skb_release_head_state() might be triggered, under network
congestion circumstances, together with the potential risk of a NULL pointer
dereference.&lt;/p&gt;
&lt;p&gt;The root cause of this issue is the call to kfree_skb() instead of
dev_kfree_skb_irq() in net/core/dev.c#enqueue_to_backlog().&lt;/p&gt;
&lt;p&gt;This patch prevents the skb to be freed within the call to netif_rx() by
incrementing its reference count with skb_get(). The skb is finally freed by
one of the in-irq-context safe functions: dev_consume_skb_any() or
dev_kfree_skb_any(). The &amp;amp;quot;any&amp;amp;quot; version is used because some drivers might call
can_get_echo_skb() in a normal context.&lt;/p&gt;
&lt;p&gt;The reason for this issue to occur is that initially, in the core network
stack, loopback skb were not supposed to be received in hardware IRQ context.
The CAN stack is an exeption.&lt;/p&gt;
&lt;p&gt;This bug was previously reported back in 2017 in [1] but the proposed patch
never got accepted.&lt;/p&gt;
&lt;p&gt;While [1] directly modifies net/core/dev.c, we try to propose here a
smoother modification local to CAN network stack (the assumption
behind is that only CAN devices are affected by this issue).&lt;/p&gt;
&lt;p&gt;[1] http://lore.kern…&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;can: dev: can_get_echo_skb(): prevent call to kfree_skb() in hard IRQ context&lt;/p&gt;
&lt;p&gt;If a driver calls can_get_echo_skb() during a hardware IRQ (which is often, but
not always, the case), the &amp;amp;apos;WARN_ON(in_irq)&amp;amp;apos; in
net/core/skbuff.c#skb_release_head_state() might be triggered, under network
congestion circumstances, together with the potential risk of a NULL pointer
dereference.&lt;/p&gt;
&lt;p&gt;The root cause of this issue is the call to kfree_skb() instead of
dev_kfree_skb_irq() in net/core/dev.c#enqueue_to_backlog().&lt;/p&gt;
&lt;p&gt;This patch prevents the skb to be freed within the call to netif_rx() by
incrementing its reference count with skb_get(). The skb is finally freed by
one of the in-irq-context safe functions: dev_consume_skb_any() or
dev_kfree_skb_any(). The &amp;amp;quot;any&amp;amp;quot; version is used because some drivers might call
can_get_echo_skb() in a normal context.&lt;/p&gt;
&lt;p&gt;The reason for this issue to occur is that initially, in the core network
stack, loopback skb were not supposed to be received in hardware IRQ context.
The CAN stack is an exeption.&lt;/p&gt;
&lt;p&gt;This bug was previously reported back in 2017 in [1] but the proposed patch
never got accepted.&lt;/p&gt;
&lt;p&gt;While [1] directly modifies net/core/dev.c, we try to propose here a
smoother modification local to CAN network stack (the assumption
behind is that only CAN devices are affected by this issue).&lt;/p&gt;
&lt;p&gt;[1] http://lore.kern…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/oesa-2025-1465</guid>
    </item>
    <item>
      <title>RHSA-2022:5626 — Red Hat Security Advisory: kernel security and bug fix update</title>
      <link>https://cve.radiocsirt.org/vuln/rhsa-2022:5626</link>
      <description>&lt;p&gt;kernel: the copy-on-write implementation can grant unintended write access because of a race condition in a THP mapcount check kernel: cgroup: Use open-time creds and namespace for migration perm checks kernel: Race condition in races in sk_peer_pid and sk_peer_cred accesses kernel: dm: fix mempool NULL pointer race when completing IO kernel: Small table perturb size in the TCP source port generation algorithm can lead to information leak kernel: race condition in perf_event_open leads to privilege escalation kernel: a use-after-free write in the netfilter subsystem can lead to privilege escalation to root kernel: net: openvswitch: fix leak of nested actions&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;kernel: the copy-on-write implementation can grant unintended write access because of a race condition in a THP mapcount check kernel: cgroup: Use open-time creds and namespace for migration perm checks kernel: Race condition in races in sk_peer_pid and sk_peer_cred accesses kernel: dm: fix mempool NULL pointer race when completing IO kernel: Small table perturb size in the TCP source port generation algorithm can lead to information leak kernel: race condition in perf_event_open leads to privilege escalation kernel: a use-after-free write in the netfilter subsystem can lead to privilege escalation to root kernel: net: openvswitch: fix leak of nested actions&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/rhsa-2022:5626</guid>
    </item>
    <item>
      <title>RHSA-2022:7683 — Red Hat Security Advisory: kernel security, bug fix, and enhancement update</title>
      <link>https://cve.radiocsirt.org/vuln/rhsa-2022:7683</link>
      <description>&lt;p&gt;kernel: off-path attacker may inject data or terminate victim&amp;#39;s TCP session kernel: race condition in VT_RESIZEX ioctl when vc_cons[i].d is already NULL leading to NULL pointer dereference kernel: use-after-free vulnerability in function sco_sock_sendmsg() kernel: memory leak for large arguments in video_usercopy function in drivers/media/v4l2-core/v4l2-ioctl.c kernel: veth: ensure skb entering GRO are not cloned. kernel: inet: fully convert sk-&amp;gt;sk_rx_dst to RCU rules kernel: NFSD: Fix READDIR buffer overflow kernel: cpufreq: CPPC: Fix potential memleak in cppc_cpufreq_cpu_init kernel: nvme-rdma: destroy cm id before destroy qp to avoid use after free kernel: regmap: Fix possible double-free in regcache_rbtree_exit() kernel: ethtool: do not perform operations on net devices being unregistered kernel: scsi: scsi_debug: Fix type in min_t to avoid stack OOB kernel: KVM: x86/mmu: Zap _all_ roots when unmapping gfn range in TDP MMU kernel: udmabuf: validate ubuf-&amp;gt;pagecount kernel: drm/virtio: Ensure that objs is not NULL in virtio_gpu_array_put_free() kernel: smb2_ioctl_query_info NULL pointer dereference kernel: NULL pointer dereference in udf_expand_file_adinicbdue() during writeback kernel: swiotlb information leak with DMA_FROM_DEVICE kernel: uninitialized registers on stack in nft_do_chain can cause kernel pointer leakage to UM kernel: race condition in snd_pcm_hw_free leading to use-after-free kernel: use-after-free in tc_new_tfilter() in net/sched/cls_api.c kernel: KVM: cm…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;kernel: off-path attacker may inject data or terminate victim&amp;#39;s TCP session kernel: race condition in VT_RESIZEX ioctl when vc_cons[i].d is already NULL leading to NULL pointer dereference kernel: use-after-free vulnerability in function sco_sock_sendmsg() kernel: memory leak for large arguments in video_usercopy function in drivers/media/v4l2-core/v4l2-ioctl.c kernel: veth: ensure skb entering GRO are not cloned. kernel: inet: fully convert sk-&amp;gt;sk_rx_dst to RCU rules kernel: NFSD: Fix READDIR buffer overflow kernel: cpufreq: CPPC: Fix potential memleak in cppc_cpufreq_cpu_init kernel: nvme-rdma: destroy cm id before destroy qp to avoid use after free kernel: regmap: Fix possible double-free in regcache_rbtree_exit() kernel: ethtool: do not perform operations on net devices being unregistered kernel: scsi: scsi_debug: Fix type in min_t to avoid stack OOB kernel: KVM: x86/mmu: Zap _all_ roots when unmapping gfn range in TDP MMU kernel: udmabuf: validate ubuf-&amp;gt;pagecount kernel: drm/virtio: Ensure that objs is not NULL in virtio_gpu_array_put_free() kernel: smb2_ioctl_query_info NULL pointer dereference kernel: NULL pointer dereference in udf_expand_file_adinicbdue() during writeback kernel: swiotlb information leak with DMA_FROM_DEVICE kernel: uninitialized registers on stack in nft_do_chain can cause kernel pointer leakage to UM kernel: race condition in snd_pcm_hw_free leading to use-after-free kernel: use-after-free in tc_new_tfilter() in net/sched/cls_api.c kernel: KVM: cm…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/rhsa-2022:7683</guid>
    </item>
    <item>
      <title>SUSE-SU-2025:01600-1 — Security update for the Linux Kernel</title>
      <link>https://cve.radiocsirt.org/vuln/suse-su-2025:01600-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-2025:01600-1</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2022-49086</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2022-49086</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:Pro:14.04:LTS: linux-aws, Ubuntu:Pro:14.04:LTS: linux-azure, Ubuntu:Pro:14.04:LTS: linux-lts-xenial, Ubuntu:Pro:16.04:LTS: linux, Ubuntu:Pro:16.04:LTS: linux-aws, Ubuntu:Pro:16.04:LTS: linux-aws-hwe, Ubuntu:Pro:16.04:LTS: linux-azure, Ubuntu:Pro:16.04:LTS: linux-gcp, Ubuntu:Pro:16.04:LTS: linux-hwe, Ubuntu:16.04:LTS: linux-hwe-edge and 136 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: net: openvswitch: fix leak of nested actions While parsing user-provided actions, openvswitch module may dynamically allocate memory and store pointers in the internal copy of the actions. So this memory has to be freed while destroying the actions. Currently there are only two such actions: ct() and set().  However, there are many actions that can hold nested lists of actions and ovs_nla_free_flow_actions() just jumps over them leaking the memory. For example, removal of the flow with the following actions will lead to a leak of the memory allocated by nf_ct_tmpl_alloc():   actions:clone(ct(commit),0) Non-freed set() action may also leak the &amp;#39;dst&amp;#39; structure for the tunnel info including device references. Under certain conditions with a high rate of flow rotation that may cause significant memory leak problem (2MB per second in reporter&amp;#39;s case).  The problem is also hard to mitigate, because the user doesn&amp;#39;t have direct control over the datapath flows generated by OVS. Fix that by iterating over all the nested actions and freeing everything that needs to be freed recursively. New build time assertion should protect us from this problem if new actions will be added in the future. Unfortunately, openvswitch module doesn&amp;#39;t use NLA_F_NESTED, so all attributes has to be explicitly checked.  sample() and clone() actions are mixing extra attributes into the user-provided action list.  That prevents some code gener…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:Pro:14.04:LTS: linux-aws, Ubuntu:Pro:14.04:LTS: linux-azure, Ubuntu:Pro:14.04:LTS: linux-lts-xenial, Ubuntu:Pro:16.04:LTS: linux, Ubuntu:Pro:16.04:LTS: linux-aws, Ubuntu:Pro:16.04:LTS: linux-aws-hwe, Ubuntu:Pro:16.04:LTS: linux-azure, Ubuntu:Pro:16.04:LTS: linux-gcp, Ubuntu:Pro:16.04:LTS: linux-hwe, Ubuntu:16.04:LTS: linux-hwe-edge and 136 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: net: openvswitch: fix leak of nested actions While parsing user-provided actions, openvswitch module may dynamically allocate memory and store pointers in the internal copy of the actions. So this memory has to be freed while destroying the actions. Currently there are only two such actions: ct() and set().  However, there are many actions that can hold nested lists of actions and ovs_nla_free_flow_actions() just jumps over them leaking the memory. For example, removal of the flow with the following actions will lead to a leak of the memory allocated by nf_ct_tmpl_alloc():   actions:clone(ct(commit),0) Non-freed set() action may also leak the &amp;#39;dst&amp;#39; structure for the tunnel info including device references. Under certain conditions with a high rate of flow rotation that may cause significant memory leak problem (2MB per second in reporter&amp;#39;s case).  The problem is also hard to mitigate, because the user doesn&amp;#39;t have direct control over the datapath flows generated by OVS. Fix that by iterating over all the nested actions and freeing everything that needs to be freed recursively. New build time assertion should protect us from this problem if new actions will be added in the future. Unfortunately, openvswitch module doesn&amp;#39;t use NLA_F_NESTED, so all attributes has to be explicitly checked.  sample() and clone() actions are mixing extra attributes into the user-provided action list.  That prevents some code gener…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2022-49086</guid>
    </item>
  </channel>
</rss>
