<?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 14:18:11 +0000</lastBuildDate>
    <item>
      <title>EUVD-2026-344769</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-344769</link>
      <description>EUVD-2026-344769</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-344769</guid>
    </item>
    <item>
      <title>fkie_cve-2022-49664</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2022-49664</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;tipc: move bc link creation back to tipc_node_create&lt;/p&gt;
&lt;p&gt;Shuang Li reported a NULL pointer dereference crash:&lt;/p&gt;
&lt;p&gt;[] BUG: kernel NULL pointer dereference, address: 0000000000000068
  [] RIP: 0010:tipc_link_is_up+0x5/0x10 [tipc]
  [] Call Trace:
  []  &amp;lt;IRQ&amp;gt;
  []  tipc_bcast_rcv+0xa2/0x190 [tipc]
  []  tipc_node_bc_rcv+0x8b/0x200 [tipc]
  []  tipc_rcv+0x3af/0x5b0 [tipc]
  []  tipc_udp_recv+0xc7/0x1e0 [tipc]&lt;/p&gt;
&lt;p&gt;It was caused by the &amp;#39;l&amp;#39; passed into tipc_bcast_rcv() is NULL. When it
creates a node in tipc_node_check_dest(), after inserting the new node
into hashtable in tipc_node_create(), it creates the bc link. However,
there is a gap between this insert and bc link creation, a bc packet
may come in and get the node from the hashtable then try to dereference
its bc link, which is NULL.&lt;/p&gt;
&lt;p&gt;This patch is to fix it by moving the bc link creation before inserting
into the hashtable.&lt;/p&gt;
&lt;p&gt;Note that for a preliminary node becoming &amp;#34;real&amp;#34;, the bc link creation
should also be called before it&amp;#39;s rehashed, as we don&amp;#39;t create it for
preliminary nodes.&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;tipc: move bc link creation back to tipc_node_create&lt;/p&gt;
&lt;p&gt;Shuang Li reported a NULL pointer dereference crash:&lt;/p&gt;
&lt;p&gt;[] BUG: kernel NULL pointer dereference, address: 0000000000000068
  [] RIP: 0010:tipc_link_is_up+0x5/0x10 [tipc]
  [] Call Trace:
  []  &amp;lt;IRQ&amp;gt;
  []  tipc_bcast_rcv+0xa2/0x190 [tipc]
  []  tipc_node_bc_rcv+0x8b/0x200 [tipc]
  []  tipc_rcv+0x3af/0x5b0 [tipc]
  []  tipc_udp_recv+0xc7/0x1e0 [tipc]&lt;/p&gt;
&lt;p&gt;It was caused by the &amp;#39;l&amp;#39; passed into tipc_bcast_rcv() is NULL. When it
creates a node in tipc_node_check_dest(), after inserting the new node
into hashtable in tipc_node_create(), it creates the bc link. However,
there is a gap between this insert and bc link creation, a bc packet
may come in and get the node from the hashtable then try to dereference
its bc link, which is NULL.&lt;/p&gt;
&lt;p&gt;This patch is to fix it by moving the bc link creation before inserting
into the hashtable.&lt;/p&gt;
&lt;p&gt;Note that for a preliminary node becoming &amp;#34;real&amp;#34;, the bc link creation
should also be called before it&amp;#39;s rehashed, as we don&amp;#39;t create it for
preliminary nodes.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2022-49664</guid>
    </item>
    <item>
      <title>GHSA-v579-rch8-988w</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-v579-rch8-988w</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;tipc: move bc link creation back to tipc_node_create&lt;/p&gt;
&lt;p&gt;Shuang Li reported a NULL pointer dereference crash:&lt;/p&gt;
&lt;p&gt;[] BUG: kernel NULL pointer dereference, address: 0000000000000068
  [] RIP: 0010:tipc_link_is_up+0x5/0x10 [tipc]
  [] Call Trace:
  []  &amp;lt;IRQ&amp;gt;
  []  tipc_bcast_rcv+0xa2/0x190 [tipc]
  []  tipc_node_bc_rcv+0x8b/0x200 [tipc]
  []  tipc_rcv+0x3af/0x5b0 [tipc]
  []  tipc_udp_recv+0xc7/0x1e0 [tipc]&lt;/p&gt;
&lt;p&gt;It was caused by the &amp;#39;l&amp;#39; passed into tipc_bcast_rcv() is NULL. When it
creates a node in tipc_node_check_dest(), after inserting the new node
into hashtable in tipc_node_create(), it creates the bc link. However,
there is a gap between this insert and bc link creation, a bc packet
may come in and get the node from the hashtable then try to dereference
its bc link, which is NULL.&lt;/p&gt;
&lt;p&gt;This patch is to fix it by moving the bc link creation before inserting
into the hashtable.&lt;/p&gt;
&lt;p&gt;Note that for a preliminary node becoming &amp;#34;real&amp;#34;, the bc link creation
should also be called before it&amp;#39;s rehashed, as we don&amp;#39;t create it for
preliminary nodes.&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;tipc: move bc link creation back to tipc_node_create&lt;/p&gt;
&lt;p&gt;Shuang Li reported a NULL pointer dereference crash:&lt;/p&gt;
&lt;p&gt;[] BUG: kernel NULL pointer dereference, address: 0000000000000068
  [] RIP: 0010:tipc_link_is_up+0x5/0x10 [tipc]
  [] Call Trace:
  []  &amp;lt;IRQ&amp;gt;
  []  tipc_bcast_rcv+0xa2/0x190 [tipc]
  []  tipc_node_bc_rcv+0x8b/0x200 [tipc]
  []  tipc_rcv+0x3af/0x5b0 [tipc]
  []  tipc_udp_recv+0xc7/0x1e0 [tipc]&lt;/p&gt;
&lt;p&gt;It was caused by the &amp;#39;l&amp;#39; passed into tipc_bcast_rcv() is NULL. When it
creates a node in tipc_node_check_dest(), after inserting the new node
into hashtable in tipc_node_create(), it creates the bc link. However,
there is a gap between this insert and bc link creation, a bc packet
may come in and get the node from the hashtable then try to dereference
its bc link, which is NULL.&lt;/p&gt;
&lt;p&gt;This patch is to fix it by moving the bc link creation before inserting
into the hashtable.&lt;/p&gt;
&lt;p&gt;Note that for a preliminary node becoming &amp;#34;real&amp;#34;, the bc link creation
should also be called before it&amp;#39;s rehashed, as we don&amp;#39;t create it for
preliminary nodes.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-v579-rch8-988w</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>UBUNTU-CVE-2022-49664</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2022-49664</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:Pro:18.04:LTS: linux-aws-5.4, Ubuntu:18.04:LTS: linux-azure, Ubuntu:18.04:LTS: linux-azure-5.3, Ubuntu:Pro:18.04:LTS: linux-azure-5.4, Ubuntu:18.04:LTS: linux-azure-edge, Ubuntu:18.04:LTS: linux-gcp, Ubuntu:18.04:LTS: linux-gcp-5.3 and 114 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: tipc: move bc link creation back to tipc_node_create Shuang Li reported a NULL pointer dereference crash:   [] BUG: kernel NULL pointer dereference, address: 0000000000000068   [] RIP: 0010:tipc_link_is_up+0x5/0x10 [tipc]   [] Call Trace:   []  &amp;lt;IRQ&amp;gt;   []  tipc_bcast_rcv+0xa2/0x190 [tipc]   []  tipc_node_bc_rcv+0x8b/0x200 [tipc]   []  tipc_rcv+0x3af/0x5b0 [tipc]   []  tipc_udp_recv+0xc7/0x1e0 [tipc] It was caused by the &amp;#39;l&amp;#39; passed into tipc_bcast_rcv() is NULL. When it creates a node in tipc_node_check_dest(), after inserting the new node into hashtable in tipc_node_create(), it creates the bc link. However, there is a gap between this insert and bc link creation, a bc packet may come in and get the node from the hashtable then try to dereference its bc link, which is NULL. This patch is to fix it by moving the bc link creation before inserting into the hashtable. Note that for a preliminary node becoming &amp;#34;real&amp;#34;, the bc link creation should also be called before it&amp;#39;s rehashed, as we don&amp;#39;t create it for preliminary nodes.&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:Pro:18.04:LTS: linux-aws-5.4, Ubuntu:18.04:LTS: linux-azure, Ubuntu:18.04:LTS: linux-azure-5.3, Ubuntu:Pro:18.04:LTS: linux-azure-5.4, Ubuntu:18.04:LTS: linux-azure-edge, Ubuntu:18.04:LTS: linux-gcp, Ubuntu:18.04:LTS: linux-gcp-5.3 and 114 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: tipc: move bc link creation back to tipc_node_create Shuang Li reported a NULL pointer dereference crash:   [] BUG: kernel NULL pointer dereference, address: 0000000000000068   [] RIP: 0010:tipc_link_is_up+0x5/0x10 [tipc]   [] Call Trace:   []  &amp;lt;IRQ&amp;gt;   []  tipc_bcast_rcv+0xa2/0x190 [tipc]   []  tipc_node_bc_rcv+0x8b/0x200 [tipc]   []  tipc_rcv+0x3af/0x5b0 [tipc]   []  tipc_udp_recv+0xc7/0x1e0 [tipc] It was caused by the &amp;#39;l&amp;#39; passed into tipc_bcast_rcv() is NULL. When it creates a node in tipc_node_check_dest(), after inserting the new node into hashtable in tipc_node_create(), it creates the bc link. However, there is a gap between this insert and bc link creation, a bc packet may come in and get the node from the hashtable then try to dereference its bc link, which is NULL. This patch is to fix it by moving the bc link creation before inserting into the hashtable. Note that for a preliminary node becoming &amp;#34;real&amp;#34;, the bc link creation should also be called before it&amp;#39;s rehashed, as we don&amp;#39;t create it for preliminary nodes.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2022-49664</guid>
    </item>
  </channel>
</rss>
