<?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>Mon, 28 Sep 2026 20:40:34 +0000</lastBuildDate>
    <item>
      <title>CERTFR-2026-AVI-0108 — 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://vulnerability.circl.lu/vuln/CERTFR-2026-AVI-0108</link>
      <description>CERTFR-2026-AVI-0108</description>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/CERTFR-2026-AVI-0108</guid>
    </item>
    <item>
      <title>BELL-CVE-2023-53847</title>
      <link>https://vulnerability.circl.lu/vuln/bell-cve-2023-53847</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Alpaquita:23: linux-lts, Alpaquita:stream: linux-lts&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Alpaquita:23: linux-lts, Alpaquita:stream: linux-lts&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/bell-cve-2023-53847</guid>
    </item>
    <item>
      <title>fkie_cve-2023-53847</title>
      <link>https://vulnerability.circl.lu/vuln/fkie_cve-2023-53847</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;usb-storage: alauda: Fix uninit-value in alauda_check_media()&lt;/p&gt;
&lt;p&gt;Syzbot got KMSAN to complain about access to an uninitialized value in
the alauda subdriver of usb-storage:&lt;/p&gt;
&lt;p&gt;BUG: KMSAN: uninit-value in alauda_transport+0x462/0x57f0
drivers/usb/storage/alauda.c:1137
CPU: 0 PID: 12279 Comm: usb-storage Not tainted 5.3.0-rc7+ #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
  __dump_stack lib/dump_stack.c:77 [inline]
  dump_stack+0x191/0x1f0 lib/dump_stack.c:113
  kmsan_report+0x13a/0x2b0 mm/kmsan/kmsan_report.c:108
  __msan_warning+0x73/0xe0 mm/kmsan/kmsan_instr.c:250
  alauda_check_media+0x344/0x3310 drivers/usb/storage/alauda.c:460&lt;/p&gt;
&lt;p&gt;The problem is that alauda_check_media() doesn&amp;#39;t verify that its USB
transfer succeeded before trying to use the received data.  What
should happen if the transfer fails isn&amp;#39;t entirely clear, but a
reasonably conservative approach is to pretend that no media is
present.&lt;/p&gt;
&lt;p&gt;A similar problem exists in a usb_stor_dbg() call in
alauda_get_media_status().  In this case, when an error occurs the
call is redundant, because usb_stor_ctrl_transfer() already will print
a debugging message.&lt;/p&gt;
&lt;p&gt;Finally, unrelated to the uninitialized memory access, is the fact
that alauda_check_media() performs DMA to a buffer on the stack.
Fortunately usb-storage provides a general purpose DMA-able buffer for
uses like this.  We&amp;#39;ll use it instead.&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;usb-storage: alauda: Fix uninit-value in alauda_check_media()&lt;/p&gt;
&lt;p&gt;Syzbot got KMSAN to complain about access to an uninitialized value in
the alauda subdriver of usb-storage:&lt;/p&gt;
&lt;p&gt;BUG: KMSAN: uninit-value in alauda_transport+0x462/0x57f0
drivers/usb/storage/alauda.c:1137
CPU: 0 PID: 12279 Comm: usb-storage Not tainted 5.3.0-rc7+ #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
  __dump_stack lib/dump_stack.c:77 [inline]
  dump_stack+0x191/0x1f0 lib/dump_stack.c:113
  kmsan_report+0x13a/0x2b0 mm/kmsan/kmsan_report.c:108
  __msan_warning+0x73/0xe0 mm/kmsan/kmsan_instr.c:250
  alauda_check_media+0x344/0x3310 drivers/usb/storage/alauda.c:460&lt;/p&gt;
&lt;p&gt;The problem is that alauda_check_media() doesn&amp;#39;t verify that its USB
transfer succeeded before trying to use the received data.  What
should happen if the transfer fails isn&amp;#39;t entirely clear, but a
reasonably conservative approach is to pretend that no media is
present.&lt;/p&gt;
&lt;p&gt;A similar problem exists in a usb_stor_dbg() call in
alauda_get_media_status().  In this case, when an error occurs the
call is redundant, because usb_stor_ctrl_transfer() already will print
a debugging message.&lt;/p&gt;
&lt;p&gt;Finally, unrelated to the uninitialized memory access, is the fact
that alauda_check_media() performs DMA to a buffer on the stack.
Fortunately usb-storage provides a general purpose DMA-able buffer for
uses like this.  We&amp;#39;ll use it instead.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/fkie_cve-2023-53847</guid>
    </item>
    <item>
      <title>GHSA-c2v2-h9q2-p64v</title>
      <link>https://vulnerability.circl.lu/vuln/ghsa-c2v2-h9q2-p64v</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;usb-storage: alauda: Fix uninit-value in alauda_check_media()&lt;/p&gt;
&lt;p&gt;Syzbot got KMSAN to complain about access to an uninitialized value in
the alauda subdriver of usb-storage:&lt;/p&gt;
&lt;p&gt;BUG: KMSAN: uninit-value in alauda_transport+0x462/0x57f0
drivers/usb/storage/alauda.c:1137
CPU: 0 PID: 12279 Comm: usb-storage Not tainted 5.3.0-rc7+ #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
  __dump_stack lib/dump_stack.c:77 [inline]
  dump_stack+0x191/0x1f0 lib/dump_stack.c:113
  kmsan_report+0x13a/0x2b0 mm/kmsan/kmsan_report.c:108
  __msan_warning+0x73/0xe0 mm/kmsan/kmsan_instr.c:250
  alauda_check_media+0x344/0x3310 drivers/usb/storage/alauda.c:460&lt;/p&gt;
&lt;p&gt;The problem is that alauda_check_media() doesn&amp;#39;t verify that its USB
transfer succeeded before trying to use the received data.  What
should happen if the transfer fails isn&amp;#39;t entirely clear, but a
reasonably conservative approach is to pretend that no media is
present.&lt;/p&gt;
&lt;p&gt;A similar problem exists in a usb_stor_dbg() call in
alauda_get_media_status().  In this case, when an error occurs the
call is redundant, because usb_stor_ctrl_transfer() already will print
a debugging message.&lt;/p&gt;
&lt;p&gt;Finally, unrelated to the uninitialized memory access, is the fact
that alauda_check_media() performs DMA to a buffer on the stack.
Fortunately usb-storage provides a general purpose DMA-able buffer for
uses like this.  We&amp;#39;ll use it instead.&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;usb-storage: alauda: Fix uninit-value in alauda_check_media()&lt;/p&gt;
&lt;p&gt;Syzbot got KMSAN to complain about access to an uninitialized value in
the alauda subdriver of usb-storage:&lt;/p&gt;
&lt;p&gt;BUG: KMSAN: uninit-value in alauda_transport+0x462/0x57f0
drivers/usb/storage/alauda.c:1137
CPU: 0 PID: 12279 Comm: usb-storage Not tainted 5.3.0-rc7+ #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
  __dump_stack lib/dump_stack.c:77 [inline]
  dump_stack+0x191/0x1f0 lib/dump_stack.c:113
  kmsan_report+0x13a/0x2b0 mm/kmsan/kmsan_report.c:108
  __msan_warning+0x73/0xe0 mm/kmsan/kmsan_instr.c:250
  alauda_check_media+0x344/0x3310 drivers/usb/storage/alauda.c:460&lt;/p&gt;
&lt;p&gt;The problem is that alauda_check_media() doesn&amp;#39;t verify that its USB
transfer succeeded before trying to use the received data.  What
should happen if the transfer fails isn&amp;#39;t entirely clear, but a
reasonably conservative approach is to pretend that no media is
present.&lt;/p&gt;
&lt;p&gt;A similar problem exists in a usb_stor_dbg() call in
alauda_get_media_status().  In this case, when an error occurs the
call is redundant, because usb_stor_ctrl_transfer() already will print
a debugging message.&lt;/p&gt;
&lt;p&gt;Finally, unrelated to the uninitialized memory access, is the fact
that alauda_check_media() performs DMA to a buffer on the stack.
Fortunately usb-storage provides a general purpose DMA-able buffer for
uses like this.  We&amp;#39;ll use it instead.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/ghsa-c2v2-h9q2-p64v</guid>
    </item>
    <item>
      <title>OESA-2026-1306 — kernel security update</title>
      <link>https://vulnerability.circl.lu/vuln/oesa-2026-1306</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;cacheinfo: Fix shared_cpu_map to handle shared caches at different levels&lt;/p&gt;
&lt;p&gt;The cacheinfo sets up the shared_cpu_map by checking whether the caches
with the same index are shared between CPUs. However, this will trigger
slab-out-of-bounds access if the CPUs do not have the same cache hierarchy.
Another problem is the mismatched shared_cpu_map when the shared cache does
not have the same index between CPUs.&lt;/p&gt;
&lt;p&gt;CPU0	I	D	L3
index	0	1	2	x
	^	^	^	^
index	0	1	2	3
CPU1	I	D	L2	L3&lt;/p&gt;
&lt;p&gt;This patch checks each cache is shared with all caches on other CPUs.(CVE-2023-53254)&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;drm/radeon: Fix integer overflow in radeon_cs_parser_init&lt;/p&gt;
&lt;p&gt;The type of size is unsigned, if size is 0x40000000, there will be an
integer overflow, size will be zero after size *= sizeof(uint32_t),
will cause uninitialized memory to be referenced later(CVE-2023-53309)&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;media: v4l2-mem2mem: add lock to protect parameter num_rdy&lt;/p&gt;
&lt;p&gt;Getting below error when using KCSAN to check the driver. Adding lock to
protect parameter num_rdy when getting the value with function:
v4l2_m2m_num_src_bufs_ready/v4l2_m2m_num_dst_bufs_ready.&lt;/p&gt;
&lt;p&gt;kworker/u16:3: [name:report&amp;amp;amp;]BUG: KCSAN: data-race in v4l2_m2m_buf_queue
kworker/u16:3: [name:report&amp;amp;amp;]&lt;/p&gt;
&lt;p&gt;kworker/u16:3: [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;cacheinfo: Fix shared_cpu_map to handle shared caches at different levels&lt;/p&gt;
&lt;p&gt;The cacheinfo sets up the shared_cpu_map by checking whether the caches
with the same index are shared between CPUs. However, this will trigger
slab-out-of-bounds access if the CPUs do not have the same cache hierarchy.
Another problem is the mismatched shared_cpu_map when the shared cache does
not have the same index between CPUs.&lt;/p&gt;
&lt;p&gt;CPU0	I	D	L3
index	0	1	2	x
	^	^	^	^
index	0	1	2	3
CPU1	I	D	L2	L3&lt;/p&gt;
&lt;p&gt;This patch checks each cache is shared with all caches on other CPUs.(CVE-2023-53254)&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;drm/radeon: Fix integer overflow in radeon_cs_parser_init&lt;/p&gt;
&lt;p&gt;The type of size is unsigned, if size is 0x40000000, there will be an
integer overflow, size will be zero after size *= sizeof(uint32_t),
will cause uninitialized memory to be referenced later(CVE-2023-53309)&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;media: v4l2-mem2mem: add lock to protect parameter num_rdy&lt;/p&gt;
&lt;p&gt;Getting below error when using KCSAN to check the driver. Adding lock to
protect parameter num_rdy when getting the value with function:
v4l2_m2m_num_src_bufs_ready/v4l2_m2m_num_dst_bufs_ready.&lt;/p&gt;
&lt;p&gt;kworker/u16:3: [name:report&amp;amp;amp;]BUG: KCSAN: data-race in v4l2_m2m_buf_queue
kworker/u16:3: [name:report&amp;amp;amp;]&lt;/p&gt;
&lt;p&gt;kworker/u16:3: [name…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/oesa-2026-1306</guid>
    </item>
    <item>
      <title>RHSA-2024:2394 — Red Hat Security Advisory: kernel security, bug fix, and enhancement update</title>
      <link>https://vulnerability.circl.lu/vuln/rhsa-2024:2394</link>
      <description>&lt;p&gt;kernel: Bluetooth BR/EDR PIN Pairing procedure is vulnerable to an impersonation attack kernel: ovl: fix warning in ovl_create_real() kernel: memcg does not limit the number of POSIX file locks allowing memory exhaustion kernel: vmwgfx: NULL pointer dereference in vmw_cmd_dx_define_query kernel: integer overflow in l2cap_config_req() in net/bluetooth/l2cap_core.c kernel: i2c: mlxbf: prevent stack overflow in mlxbf_i2c_smbus_start_transaction() kernel: Bluetooth: L2CAP: Fix u8 overflow kernel: hwmon: (coretemp) fix pci device refcount leak in nv1a_ram_new() kernel: tracing: Fix sleeping function called from invalid context on RT kernel kernel: net: mdio: unexport __init-annotated mdio_bus_init() kernel: arm64: ftrace: consistently handle PLTs. kernel: mm/uffd: fix pte marker when fork() without fork event kernel: Bluetooth: Fix a buffer overflow in mgmt_mesh_add() kernel: tty: n_gsm: add sanity check for gsm-&amp;gt;receive in gsm_receive_buf() kernel: ftrace: Fix NULL pointer dereference in is_ftrace_trampoline when ftrace is dead kernel: tee: add overflow check in register_shm_helper() kernel: tty: n_gsm: fix deadlock and link starvation in outgoing data path kernel: PM: hibernate: defer device probing when resuming from hibernation kernel: ext4: don&amp;#39;t allow journal inode to have encrypt flag kernel: ext4: fix delayed allocation bug in ext4_clu_mapped for bigalloc + inline kernel: erofs: fix order &amp;gt;= MAX_ORDER warning due to crafted negative i_size kernel: perf/x86/intel/uncore: F…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;kernel: Bluetooth BR/EDR PIN Pairing procedure is vulnerable to an impersonation attack kernel: ovl: fix warning in ovl_create_real() kernel: memcg does not limit the number of POSIX file locks allowing memory exhaustion kernel: vmwgfx: NULL pointer dereference in vmw_cmd_dx_define_query kernel: integer overflow in l2cap_config_req() in net/bluetooth/l2cap_core.c kernel: i2c: mlxbf: prevent stack overflow in mlxbf_i2c_smbus_start_transaction() kernel: Bluetooth: L2CAP: Fix u8 overflow kernel: hwmon: (coretemp) fix pci device refcount leak in nv1a_ram_new() kernel: tracing: Fix sleeping function called from invalid context on RT kernel kernel: net: mdio: unexport __init-annotated mdio_bus_init() kernel: arm64: ftrace: consistently handle PLTs. kernel: mm/uffd: fix pte marker when fork() without fork event kernel: Bluetooth: Fix a buffer overflow in mgmt_mesh_add() kernel: tty: n_gsm: add sanity check for gsm-&amp;gt;receive in gsm_receive_buf() kernel: ftrace: Fix NULL pointer dereference in is_ftrace_trampoline when ftrace is dead kernel: tee: add overflow check in register_shm_helper() kernel: tty: n_gsm: fix deadlock and link starvation in outgoing data path kernel: PM: hibernate: defer device probing when resuming from hibernation kernel: ext4: don&amp;#39;t allow journal inode to have encrypt flag kernel: ext4: fix delayed allocation bug in ext4_clu_mapped for bigalloc + inline kernel: erofs: fix order &amp;gt;= MAX_ORDER warning due to crafted negative i_size kernel: perf/x86/intel/uncore: F…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/rhsa-2024:2394</guid>
    </item>
    <item>
      <title>SUSE-SU-2026:0263-1 — Security update for the Linux Kernel</title>
      <link>https://vulnerability.circl.lu/vuln/suse-su-2026:0263-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://vulnerability.circl.lu/vuln/suse-su-2026:0263-1</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2023-53847</title>
      <link>https://vulnerability.circl.lu/vuln/ubuntu-cve-2023-53847</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:Pro:14.04:LTS: linux, 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 and 163 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: usb-storage: alauda: Fix uninit-value in alauda_check_media() Syzbot got KMSAN to complain about access to an uninitialized value in the alauda subdriver of usb-storage: BUG: KMSAN: uninit-value in alauda_transport+0x462/0x57f0 drivers/usb/storage/alauda.c:1137 CPU: 0 PID: 12279 Comm: usb-storage Not tainted 5.3.0-rc7+ #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace:   __dump_stack lib/dump_stack.c:77 [inline]   dump_stack+0x191/0x1f0 lib/dump_stack.c:113   kmsan_report+0x13a/0x2b0 mm/kmsan/kmsan_report.c:108   __msan_warning+0x73/0xe0 mm/kmsan/kmsan_instr.c:250   alauda_check_media+0x344/0x3310 drivers/usb/storage/alauda.c:460 The problem is that alauda_check_media() doesn&amp;#39;t verify that its USB transfer succeeded before trying to use the received data.  What should happen if the transfer fails isn&amp;#39;t entirely clear, but a reasonably conservative approach is to pretend that no media is present. A similar problem exists in a usb_stor_dbg() call in alauda_get_media_status().  In this case, when an error occurs the call is redundant, because usb_stor_ctrl_transfer() already will print a debugging message. Finally, unrelated to the uninitialized memory access, is the fact that alauda_check_media() performs DMA to a buffer on the stack. Fortunately usb-storage provides a general purpose DMA-able buffer for uses like this.  We&amp;#39;ll use it instead.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:Pro:14.04:LTS: linux, 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 and 163 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: usb-storage: alauda: Fix uninit-value in alauda_check_media() Syzbot got KMSAN to complain about access to an uninitialized value in the alauda subdriver of usb-storage: BUG: KMSAN: uninit-value in alauda_transport+0x462/0x57f0 drivers/usb/storage/alauda.c:1137 CPU: 0 PID: 12279 Comm: usb-storage Not tainted 5.3.0-rc7+ #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace:   __dump_stack lib/dump_stack.c:77 [inline]   dump_stack+0x191/0x1f0 lib/dump_stack.c:113   kmsan_report+0x13a/0x2b0 mm/kmsan/kmsan_report.c:108   __msan_warning+0x73/0xe0 mm/kmsan/kmsan_instr.c:250   alauda_check_media+0x344/0x3310 drivers/usb/storage/alauda.c:460 The problem is that alauda_check_media() doesn&amp;#39;t verify that its USB transfer succeeded before trying to use the received data.  What should happen if the transfer fails isn&amp;#39;t entirely clear, but a reasonably conservative approach is to pretend that no media is present. A similar problem exists in a usb_stor_dbg() call in alauda_get_media_status().  In this case, when an error occurs the call is redundant, because usb_stor_ctrl_transfer() already will print a debugging message. Finally, unrelated to the uninitialized memory access, is the fact that alauda_check_media() performs DMA to a buffer on the stack. Fortunately usb-storage provides a general purpose DMA-able buffer for uses like this.  We&amp;#39;ll use it instead.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/ubuntu-cve-2023-53847</guid>
    </item>
    <item>
      <title>WID-SEC-W-2025-2765 — Linux Kernel: Mehrere Schwachstellen ermöglichen Denial of Service</title>
      <link>https://vulnerability.circl.lu/vuln/wid-sec-w-2025-2765</link>
      <description>&lt;p&gt;Ein lokaler Angreifer kann mehrere Schwachstellen in Linux Kernel ausnutzen, um einen Denial of Service Angriff durchzuführen.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Ein lokaler Angreifer kann mehrere Schwachstellen in Linux Kernel ausnutzen, um einen Denial of Service Angriff durchzuführen.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/wid-sec-w-2025-2765</guid>
    </item>
  </channel>
</rss>
