<?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://db.gcve.eu</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>Tue, 29 Sep 2026 15:02:52 +0000</lastBuildDate>
    <item>
      <title>bdu:2026-03816</title>
      <link>https://db.gcve.eu/vuln/bdu:2026-03816</link>
      <description>bdu:2026-03816</description>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/bdu:2026-03816</guid>
    </item>
    <item>
      <title>certfr-2025-avi-1009 — De multiples vulnérabilités ont été découvertes dans le noyau Linux de SUSE. Elles permettent à un attaquant de provoqu…</title>
      <link>https://db.gcve.eu/vuln/certfr-2025-avi-1009</link>
      <description>certfr-2025-avi-1009</description>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/certfr-2025-avi-1009</guid>
    </item>
    <item>
      <title>fkie_cve-2023-53647</title>
      <link>https://db.gcve.eu/vuln/fkie_cve-2023-53647</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;Drivers: hv: vmbus: Don&amp;#39;t dereference ACPI root object handle&lt;/p&gt;
&lt;p&gt;Since the commit referenced in the Fixes: tag below the VMBus client driver
is walking the ACPI namespace up from the VMBus ACPI device to the ACPI
namespace root object trying to find Hyper-V MMIO ranges.&lt;/p&gt;
&lt;p&gt;However, if it is not able to find them it ends trying to walk resources of
the ACPI namespace root object itself.
This object has all-ones handle, which causes a NULL pointer dereference
in the ACPI code (from dereferencing this pointer with an offset).&lt;/p&gt;
&lt;p&gt;This in turn causes an oops on boot with VMBus host implementations that do
not provide Hyper-V MMIO ranges in their VMBus ACPI device or its
ancestors.
The QEMU VMBus implementation is an example of such implementation.&lt;/p&gt;
&lt;p&gt;I guess providing these ranges is optional, since all tested Windows
versions seem to be able to use VMBus devices without them.&lt;/p&gt;
&lt;p&gt;Fix this by explicitly terminating the lookup at the ACPI namespace root
object.&lt;/p&gt;
&lt;p&gt;Note that Linux guests under KVM/QEMU do not use the Hyper-V PV interface
by default - they only do so if the KVM PV interface is missing or
disabled.&lt;/p&gt;
&lt;p&gt;Example stack trace of such oops:
[ 3.710827] ? __die+0x1f/0x60
[ 3.715030] ? page_fault_oops+0x159/0x460
[ 3.716008] ? exc_page_fault+0x73/0x170
[ 3.716959] ? asm_exc_page_fault+0x22/0x30
[ 3.717957] ? acpi_ns_lookup+0x7a/0x4b0
[ 3.718898] ? acpi_ns_internalize_name+0x79/0xc0
[ 3.720018] acpi_ns_get_node_unlocked+0x…&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;Drivers: hv: vmbus: Don&amp;#39;t dereference ACPI root object handle&lt;/p&gt;
&lt;p&gt;Since the commit referenced in the Fixes: tag below the VMBus client driver
is walking the ACPI namespace up from the VMBus ACPI device to the ACPI
namespace root object trying to find Hyper-V MMIO ranges.&lt;/p&gt;
&lt;p&gt;However, if it is not able to find them it ends trying to walk resources of
the ACPI namespace root object itself.
This object has all-ones handle, which causes a NULL pointer dereference
in the ACPI code (from dereferencing this pointer with an offset).&lt;/p&gt;
&lt;p&gt;This in turn causes an oops on boot with VMBus host implementations that do
not provide Hyper-V MMIO ranges in their VMBus ACPI device or its
ancestors.
The QEMU VMBus implementation is an example of such implementation.&lt;/p&gt;
&lt;p&gt;I guess providing these ranges is optional, since all tested Windows
versions seem to be able to use VMBus devices without them.&lt;/p&gt;
&lt;p&gt;Fix this by explicitly terminating the lookup at the ACPI namespace root
object.&lt;/p&gt;
&lt;p&gt;Note that Linux guests under KVM/QEMU do not use the Hyper-V PV interface
by default - they only do so if the KVM PV interface is missing or
disabled.&lt;/p&gt;
&lt;p&gt;Example stack trace of such oops:
[ 3.710827] ? __die+0x1f/0x60
[ 3.715030] ? page_fault_oops+0x159/0x460
[ 3.716008] ? exc_page_fault+0x73/0x170
[ 3.716959] ? asm_exc_page_fault+0x22/0x30
[ 3.717957] ? acpi_ns_lookup+0x7a/0x4b0
[ 3.718898] ? acpi_ns_internalize_name+0x79/0xc0
[ 3.720018] acpi_ns_get_node_unlocked+0x…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/fkie_cve-2023-53647</guid>
    </item>
    <item>
      <title>GHSA-c2mm-xf5x-8rpj</title>
      <link>https://db.gcve.eu/vuln/ghsa-c2mm-xf5x-8rpj</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;Drivers: hv: vmbus: Don&amp;#39;t dereference ACPI root object handle&lt;/p&gt;
&lt;p&gt;Since the commit referenced in the Fixes: tag below the VMBus client driver
is walking the ACPI namespace up from the VMBus ACPI device to the ACPI
namespace root object trying to find Hyper-V MMIO ranges.&lt;/p&gt;
&lt;p&gt;However, if it is not able to find them it ends trying to walk resources of
the ACPI namespace root object itself.
This object has all-ones handle, which causes a NULL pointer dereference
in the ACPI code (from dereferencing this pointer with an offset).&lt;/p&gt;
&lt;p&gt;This in turn causes an oops on boot with VMBus host implementations that do
not provide Hyper-V MMIO ranges in their VMBus ACPI device or its
ancestors.
The QEMU VMBus implementation is an example of such implementation.&lt;/p&gt;
&lt;p&gt;I guess providing these ranges is optional, since all tested Windows
versions seem to be able to use VMBus devices without them.&lt;/p&gt;
&lt;p&gt;Fix this by explicitly terminating the lookup at the ACPI namespace root
object.&lt;/p&gt;
&lt;p&gt;Note that Linux guests under KVM/QEMU do not use the Hyper-V PV interface
by default - they only do so if the KVM PV interface is missing or
disabled.&lt;/p&gt;
&lt;p&gt;Example stack trace of such oops:
[ 3.710827] ? __die+0x1f/0x60
[ 3.715030] ? page_fault_oops+0x159/0x460
[ 3.716008] ? exc_page_fault+0x73/0x170
[ 3.716959] ? asm_exc_page_fault+0x22/0x30
[ 3.717957] ? acpi_ns_lookup+0x7a/0x4b0
[ 3.718898] ? acpi_ns_internalize_name+0x79/0xc0
[ 3.720018] acpi_ns_get_node_unlocked+0x…&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;Drivers: hv: vmbus: Don&amp;#39;t dereference ACPI root object handle&lt;/p&gt;
&lt;p&gt;Since the commit referenced in the Fixes: tag below the VMBus client driver
is walking the ACPI namespace up from the VMBus ACPI device to the ACPI
namespace root object trying to find Hyper-V MMIO ranges.&lt;/p&gt;
&lt;p&gt;However, if it is not able to find them it ends trying to walk resources of
the ACPI namespace root object itself.
This object has all-ones handle, which causes a NULL pointer dereference
in the ACPI code (from dereferencing this pointer with an offset).&lt;/p&gt;
&lt;p&gt;This in turn causes an oops on boot with VMBus host implementations that do
not provide Hyper-V MMIO ranges in their VMBus ACPI device or its
ancestors.
The QEMU VMBus implementation is an example of such implementation.&lt;/p&gt;
&lt;p&gt;I guess providing these ranges is optional, since all tested Windows
versions seem to be able to use VMBus devices without them.&lt;/p&gt;
&lt;p&gt;Fix this by explicitly terminating the lookup at the ACPI namespace root
object.&lt;/p&gt;
&lt;p&gt;Note that Linux guests under KVM/QEMU do not use the Hyper-V PV interface
by default - they only do so if the KVM PV interface is missing or
disabled.&lt;/p&gt;
&lt;p&gt;Example stack trace of such oops:
[ 3.710827] ? __die+0x1f/0x60
[ 3.715030] ? page_fault_oops+0x159/0x460
[ 3.716008] ? exc_page_fault+0x73/0x170
[ 3.716959] ? asm_exc_page_fault+0x22/0x30
[ 3.717957] ? acpi_ns_lookup+0x7a/0x4b0
[ 3.718898] ? acpi_ns_internalize_name+0x79/0xc0
[ 3.720018] acpi_ns_get_node_unlocked+0x…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/ghsa-c2mm-xf5x-8rpj</guid>
    </item>
    <item>
      <title>RHSA-2024:2394 — Red Hat Security Advisory: kernel security, bug fix, and enhancement update</title>
      <link>https://db.gcve.eu/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://db.gcve.eu/vuln/rhsa-2024:2394</guid>
    </item>
    <item>
      <title>SUSE-SU-2025:21040-1 — Security update for the Linux Kernel</title>
      <link>https://db.gcve.eu/vuln/suse-su-2025:21040-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://db.gcve.eu/vuln/suse-su-2025:21040-1</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2023-53647</title>
      <link>https://db.gcve.eu/vuln/ubuntu-cve-2023-53647</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 168 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: Drivers: hv: vmbus: Don&amp;#39;t dereference ACPI root object handle Since the commit referenced in the Fixes: tag below the VMBus client driver is walking the ACPI namespace up from the VMBus ACPI device to the ACPI namespace root object trying to find Hyper-V MMIO ranges. However, if it is not able to find them it ends trying to walk resources of the ACPI namespace root object itself. This object has all-ones handle, which causes a NULL pointer dereference in the ACPI code (from dereferencing this pointer with an offset). This in turn causes an oops on boot with VMBus host implementations that do not provide Hyper-V MMIO ranges in their VMBus ACPI device or its ancestors. The QEMU VMBus implementation is an example of such implementation. I guess providing these ranges is optional, since all tested Windows versions seem to be able to use VMBus devices without them. Fix this by explicitly terminating the lookup at the ACPI namespace root object. Note that Linux guests under KVM/QEMU do not use the Hyper-V PV interface by default - they only do so if the KVM PV interface is missing or disabled. Example stack trace of such oops: [ 3.710827] ? __die+0x1f/0x60 [ 3.715030] ? page_fault_oops+0x159/0x460 [ 3.716008] ? exc_page_fault+0x73/0x170 [ 3.716959] ? asm_exc_page_fault+0x22/0x30 [ 3.717957] ? acpi_ns_lookup+0x7a/0x4b0 [ 3.718898] ? acpi_ns_internalize_name+0x79/0xc0 [ 3.720018] acpi_ns_get_node_unlocked+0xb5/0xe0…&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 168 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: Drivers: hv: vmbus: Don&amp;#39;t dereference ACPI root object handle Since the commit referenced in the Fixes: tag below the VMBus client driver is walking the ACPI namespace up from the VMBus ACPI device to the ACPI namespace root object trying to find Hyper-V MMIO ranges. However, if it is not able to find them it ends trying to walk resources of the ACPI namespace root object itself. This object has all-ones handle, which causes a NULL pointer dereference in the ACPI code (from dereferencing this pointer with an offset). This in turn causes an oops on boot with VMBus host implementations that do not provide Hyper-V MMIO ranges in their VMBus ACPI device or its ancestors. The QEMU VMBus implementation is an example of such implementation. I guess providing these ranges is optional, since all tested Windows versions seem to be able to use VMBus devices without them. Fix this by explicitly terminating the lookup at the ACPI namespace root object. Note that Linux guests under KVM/QEMU do not use the Hyper-V PV interface by default - they only do so if the KVM PV interface is missing or disabled. Example stack trace of such oops: [ 3.710827] ? __die+0x1f/0x60 [ 3.715030] ? page_fault_oops+0x159/0x460 [ 3.716008] ? exc_page_fault+0x73/0x170 [ 3.716959] ? asm_exc_page_fault+0x22/0x30 [ 3.717957] ? acpi_ns_lookup+0x7a/0x4b0 [ 3.718898] ? acpi_ns_internalize_name+0x79/0xc0 [ 3.720018] acpi_ns_get_node_unlocked+0xb5/0xe0…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/ubuntu-cve-2023-53647</guid>
    </item>
    <item>
      <title>WID-SEC-W-2025-2229 — Linux Kernel: Mehrere Schwachstellen</title>
      <link>https://db.gcve.eu/vuln/wid-sec-w-2025-2229</link>
      <description>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen Denial of Service Angriff durchzuführen und andere nicht näher spezifizierte Angriffe durchzuführen.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen Denial of Service Angriff durchzuführen und andere nicht näher spezifizierte Angriffe durchzuführen.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/wid-sec-w-2025-2229</guid>
    </item>
  </channel>
</rss>
