<?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://vulnerability.circl.lu</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>Fri, 02 Oct 2026 14:31:44 +0000</lastBuildDate>
    <item>
      <title>BELL-CVE-2023-54200</title>
      <link>https://vulnerability.circl.lu/vuln/bell-cve-2023-54200</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Alpaquita:stream: linux-lts&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Alpaquita:stream: linux-lts&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/bell-cve-2023-54200</guid>
    </item>
    <item>
      <title>fkie_cve-2023-54200</title>
      <link>https://vulnerability.circl.lu/vuln/fkie_cve-2023-54200</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;netfilter: nf_tables: always release netdev hooks from notifier&lt;/p&gt;
&lt;p&gt;This reverts &amp;#34;netfilter: nf_tables: skip netdev events generated on netns removal&amp;#34;.&lt;/p&gt;
&lt;p&gt;The problem is that when a veth device is released, the veth release
callback will also queue the peer netns device for removal.&lt;/p&gt;
&lt;p&gt;Its possible that the peer netns is also slated for removal.  In this
case, the device memory is already released before the pre_exit hook of
the peer netns runs:&lt;/p&gt;
&lt;p&gt;BUG: KASAN: slab-use-after-free in nf_hook_entry_head+0x1b8/0x1d0
Read of size 8 at addr ffff88812c0124f0 by task kworker/u8:1/45
Workqueue: netns cleanup_net
Call Trace:
 nf_hook_entry_head+0x1b8/0x1d0
 __nf_unregister_net_hook+0x76/0x510
 nft_netdev_unregister_hooks+0xa0/0x220
 __nft_release_hook+0x184/0x490
 nf_tables_pre_exit_net+0x12f/0x1b0
 ..&lt;/p&gt;
&lt;p&gt;Order is:
1. First netns is released, veth_dellink() queues peer netns device
   for removal
2. peer netns is queued for removal
3. peer netns device is released, unreg event is triggered
4. unreg event is ignored because netns is going down
5. pre_exit hook calls nft_netdev_unregister_hooks but device memory
   might be free&amp;#39;d already.&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;netfilter: nf_tables: always release netdev hooks from notifier&lt;/p&gt;
&lt;p&gt;This reverts &amp;#34;netfilter: nf_tables: skip netdev events generated on netns removal&amp;#34;.&lt;/p&gt;
&lt;p&gt;The problem is that when a veth device is released, the veth release
callback will also queue the peer netns device for removal.&lt;/p&gt;
&lt;p&gt;Its possible that the peer netns is also slated for removal.  In this
case, the device memory is already released before the pre_exit hook of
the peer netns runs:&lt;/p&gt;
&lt;p&gt;BUG: KASAN: slab-use-after-free in nf_hook_entry_head+0x1b8/0x1d0
Read of size 8 at addr ffff88812c0124f0 by task kworker/u8:1/45
Workqueue: netns cleanup_net
Call Trace:
 nf_hook_entry_head+0x1b8/0x1d0
 __nf_unregister_net_hook+0x76/0x510
 nft_netdev_unregister_hooks+0xa0/0x220
 __nft_release_hook+0x184/0x490
 nf_tables_pre_exit_net+0x12f/0x1b0
 ..&lt;/p&gt;
&lt;p&gt;Order is:
1. First netns is released, veth_dellink() queues peer netns device
   for removal
2. peer netns is queued for removal
3. peer netns device is released, unreg event is triggered
4. unreg event is ignored because netns is going down
5. pre_exit hook calls nft_netdev_unregister_hooks but device memory
   might be free&amp;#39;d already.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/fkie_cve-2023-54200</guid>
    </item>
    <item>
      <title>GHSA-jgcg-mpfg-g663</title>
      <link>https://vulnerability.circl.lu/vuln/ghsa-jgcg-mpfg-g663</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;netfilter: nf_tables: always release netdev hooks from notifier&lt;/p&gt;
&lt;p&gt;This reverts &amp;#34;netfilter: nf_tables: skip netdev events generated on netns removal&amp;#34;.&lt;/p&gt;
&lt;p&gt;The problem is that when a veth device is released, the veth release
callback will also queue the peer netns device for removal.&lt;/p&gt;
&lt;p&gt;Its possible that the peer netns is also slated for removal.  In this
case, the device memory is already released before the pre_exit hook of
the peer netns runs:&lt;/p&gt;
&lt;p&gt;BUG: KASAN: slab-use-after-free in nf_hook_entry_head+0x1b8/0x1d0
Read of size 8 at addr ffff88812c0124f0 by task kworker/u8:1/45
Workqueue: netns cleanup_net
Call Trace:
 nf_hook_entry_head+0x1b8/0x1d0
 __nf_unregister_net_hook+0x76/0x510
 nft_netdev_unregister_hooks+0xa0/0x220
 __nft_release_hook+0x184/0x490
 nf_tables_pre_exit_net+0x12f/0x1b0
 ..&lt;/p&gt;
&lt;p&gt;Order is:
1. First netns is released, veth_dellink() queues peer netns device
   for removal
2. peer netns is queued for removal
3. peer netns device is released, unreg event is triggered
4. unreg event is ignored because netns is going down
5. pre_exit hook calls nft_netdev_unregister_hooks but device memory
   might be free&amp;#39;d already.&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;netfilter: nf_tables: always release netdev hooks from notifier&lt;/p&gt;
&lt;p&gt;This reverts &amp;#34;netfilter: nf_tables: skip netdev events generated on netns removal&amp;#34;.&lt;/p&gt;
&lt;p&gt;The problem is that when a veth device is released, the veth release
callback will also queue the peer netns device for removal.&lt;/p&gt;
&lt;p&gt;Its possible that the peer netns is also slated for removal.  In this
case, the device memory is already released before the pre_exit hook of
the peer netns runs:&lt;/p&gt;
&lt;p&gt;BUG: KASAN: slab-use-after-free in nf_hook_entry_head+0x1b8/0x1d0
Read of size 8 at addr ffff88812c0124f0 by task kworker/u8:1/45
Workqueue: netns cleanup_net
Call Trace:
 nf_hook_entry_head+0x1b8/0x1d0
 __nf_unregister_net_hook+0x76/0x510
 nft_netdev_unregister_hooks+0xa0/0x220
 __nft_release_hook+0x184/0x490
 nf_tables_pre_exit_net+0x12f/0x1b0
 ..&lt;/p&gt;
&lt;p&gt;Order is:
1. First netns is released, veth_dellink() queues peer netns device
   for removal
2. peer netns is queued for removal
3. peer netns device is released, unreg event is triggered
4. unreg event is ignored because netns is going down
5. pre_exit hook calls nft_netdev_unregister_hooks but device memory
   might be free&amp;#39;d already.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/ghsa-jgcg-mpfg-g663</guid>
    </item>
    <item>
      <title>RHSA-2023:6583 — Red Hat Security Advisory: kernel security, bug fix, and enhancement update</title>
      <link>https://vulnerability.circl.lu/vuln/rhsa-2023:6583</link>
      <description>&lt;p&gt;kernel: seg6: fix the iif in the IPv6 socket control block Kernel: race when faulting a device private page in memory manager kernel: use-after-free in l1oip timer handlers kernel: Rate limit overflow messages in r8152 in intr_callback kernel: vmwgfx: use-after-free in vmw_cmd_res_check kernel: vmwgfx: use-after-free in vmw_execbuf_tie_context hw: Intel: Gather Data Sampling (GDS) side channel vulnerability kernel: Information leak in l2cap_parse_conf_req in net/bluetooth/l2cap_core.c kernel: perf: Fix perf_pending_task() UaF kernel: gpiolib: fix memory leak in gpiochip_setup_dev() kernel: memcg: fix possible use-after-free in memcg_write_event_control() kernel: mm/khugepaged: invoke MMU notifiers in shmem/file collapse paths kernel: char: tpm: Protect tpm_pm_suspend with locks kernel: ixgbevf: Fix resource leak in ixgbevf_init_module() kernel: dax: make sure inodes are flushed before destroy cache kernel: watch_queue: Actually free the watch kernel: watch_queue: Fix NULL dereference in error cleanup kernel: rtc: pl031: fix rtc features null pointer dereference kernel: tpm: fix reference counting for struct tpm_chip kernel: NFSv4: Don&amp;#39;t hold the layoutget locks across multiple RPC calls kernel: xprtrdma: treat all calls not a bcall when bc_serv is NULL kernel: net: ipv6: unexport __init-annotated seg6_hmac_init() kernel: af_unix: Fix a data-race in unix_dgram_peer_wake_me(). kernel: regulator: scmi: Fix refcount leak in scmi_regulator_probe kernel: mm/mempolicy: fix uninit-v…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;kernel: seg6: fix the iif in the IPv6 socket control block Kernel: race when faulting a device private page in memory manager kernel: use-after-free in l1oip timer handlers kernel: Rate limit overflow messages in r8152 in intr_callback kernel: vmwgfx: use-after-free in vmw_cmd_res_check kernel: vmwgfx: use-after-free in vmw_execbuf_tie_context hw: Intel: Gather Data Sampling (GDS) side channel vulnerability kernel: Information leak in l2cap_parse_conf_req in net/bluetooth/l2cap_core.c kernel: perf: Fix perf_pending_task() UaF kernel: gpiolib: fix memory leak in gpiochip_setup_dev() kernel: memcg: fix possible use-after-free in memcg_write_event_control() kernel: mm/khugepaged: invoke MMU notifiers in shmem/file collapse paths kernel: char: tpm: Protect tpm_pm_suspend with locks kernel: ixgbevf: Fix resource leak in ixgbevf_init_module() kernel: dax: make sure inodes are flushed before destroy cache kernel: watch_queue: Actually free the watch kernel: watch_queue: Fix NULL dereference in error cleanup kernel: rtc: pl031: fix rtc features null pointer dereference kernel: tpm: fix reference counting for struct tpm_chip kernel: NFSv4: Don&amp;#39;t hold the layoutget locks across multiple RPC calls kernel: xprtrdma: treat all calls not a bcall when bc_serv is NULL kernel: net: ipv6: unexport __init-annotated seg6_hmac_init() kernel: af_unix: Fix a data-race in unix_dgram_peer_wake_me(). kernel: regulator: scmi: Fix refcount leak in scmi_regulator_probe kernel: mm/mempolicy: fix uninit-v…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/rhsa-2023:6583</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2023-54200</title>
      <link>https://vulnerability.circl.lu/vuln/ubuntu-cve-2023-54200</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 110 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: always release netdev hooks from notifier This reverts &amp;#34;netfilter: nf_tables: skip netdev events generated on netns removal&amp;#34;. The problem is that when a veth device is released, the veth release callback will also queue the peer netns device for removal. Its possible that the peer netns is also slated for removal.  In this case, the device memory is already released before the pre_exit hook of the peer netns runs: BUG: KASAN: slab-use-after-free in nf_hook_entry_head+0x1b8/0x1d0 Read of size 8 at addr ffff88812c0124f0 by task kworker/u8:1/45 Workqueue: netns cleanup_net Call Trace:  nf_hook_entry_head+0x1b8/0x1d0  __nf_unregister_net_hook+0x76/0x510  nft_netdev_unregister_hooks+0xa0/0x220  __nft_release_hook+0x184/0x490  nf_tables_pre_exit_net+0x12f/0x1b0  .. Order is: 1. First netns is released, veth_dellink() queues peer netns device    for removal 2. peer netns is queued for removal 3. peer netns device is released, unreg event is triggered 4. unreg event is ignored because netns is going down 5. pre_exit hook calls nft_netdev_unregister_hooks but device memory    might be free&amp;#39;d already.&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 110 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: always release netdev hooks from notifier This reverts &amp;#34;netfilter: nf_tables: skip netdev events generated on netns removal&amp;#34;. The problem is that when a veth device is released, the veth release callback will also queue the peer netns device for removal. Its possible that the peer netns is also slated for removal.  In this case, the device memory is already released before the pre_exit hook of the peer netns runs: BUG: KASAN: slab-use-after-free in nf_hook_entry_head+0x1b8/0x1d0 Read of size 8 at addr ffff88812c0124f0 by task kworker/u8:1/45 Workqueue: netns cleanup_net Call Trace:  nf_hook_entry_head+0x1b8/0x1d0  __nf_unregister_net_hook+0x76/0x510  nft_netdev_unregister_hooks+0xa0/0x220  __nft_release_hook+0x184/0x490  nf_tables_pre_exit_net+0x12f/0x1b0  .. Order is: 1. First netns is released, veth_dellink() queues peer netns device    for removal 2. peer netns is queued for removal 3. peer netns device is released, unreg event is triggered 4. unreg event is ignored because netns is going down 5. pre_exit hook calls nft_netdev_unregister_hooks but device memory    might be free&amp;#39;d already.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/ubuntu-cve-2023-54200</guid>
    </item>
    <item>
      <title>WID-SEC-W-2025-2941 — Linux Kernel: Mehrere Schwachstellen ermöglichen Denial of Service</title>
      <link>https://vulnerability.circl.lu/vuln/wid-sec-w-2025-2941</link>
      <description>&lt;p&gt;Ein Angreifer kann diese Schwachstellen ausnutzen, um nicht näher spezifizierte Angriffe durchzuführen, die möglicherweise zu Denial‑of‑Service, Speicherbeschädigung oder weiteren nicht definierten Auswirkungen führen.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Ein Angreifer kann diese Schwachstellen ausnutzen, um nicht näher spezifizierte Angriffe durchzuführen, die möglicherweise zu Denial‑of‑Service, Speicherbeschädigung oder weiteren nicht definierten Auswirkungen führen.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/wid-sec-w-2025-2941</guid>
    </item>
  </channel>
</rss>
