<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
  <id>https://vulnerability.circl.lu/rss/recent/all/10</id>
  <title>Most recent entries from all</title>
  <updated>2026-09-30T22:13:36.747656+00:00</updated>
  <author>
    <name>Vulnerability-Lookup</name>
    <email>info@circl.lu</email>
  </author>
  <link href="https://vulnerability.circl.lu" rel="alternate"/>
  <generator uri="https://lkiesow.github.io/python-feedgen" version="1.0.0">python-feedgen</generator>
  <subtitle>Contains only the most 10 recent entries.</subtitle>
  <entry>
    <id>https://vulnerability.circl.lu/vuln/cve-2023-53647</id>
    <title>CVE-2023-53647 — Drivers: hv: vmbus: Don't dereference ACPI root object handle</title>
    <updated>2026-09-30T22:13:37.855092+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> Linux</p>
<p>In the Linux kernel, the following vulnerability has been resolved:</p>
<p>Drivers: hv: vmbus: Don't dereference ACPI root object handle</p>
<p>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.</p>
<p>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).</p>
<p>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.</p>
<p>I guess providing these ranges is optional, since all tested Windows
versions seem to be able to use VMBus devices without them.</p>
<p>Fix this by explicitly terminating the lookup at the ACPI namespace root
object.</p>
<p>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.</p>
<p>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…</p></div>
    </content>
    <link href="https://vulnerability.circl.lu/vuln/cve-2023-53647"/>
  </entry>
  <entry>
    <id>https://vulnerability.circl.lu/vuln/rhsa-2024:2394</id>
    <title>RHSA-2024:2394 — Red Hat Security Advisory: kernel security, bug fix, and enhancement update</title>
    <updated>2026-09-30T22:13:37.855237+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p>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-&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'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 &gt;= MAX_ORDER warning due to crafted negative i_size kernel: perf/x86/intel/uncore: F…</p>
      </div>
    </content>
    <link href="https://vulnerability.circl.lu/vuln/rhsa-2024:2394"/>
  </entry>
</feed>
