<?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>Tue, 29 Sep 2026 13:18:40 +0000</lastBuildDate>
    <item>
      <title>bdu:2025-14588</title>
      <link>https://vulnerability.circl.lu/vuln/bdu:2025-14588</link>
      <description>bdu:2025-14588</description>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/bdu:2025-14588</guid>
    </item>
    <item>
      <title>BELL-CVE-2023-52625</title>
      <link>https://vulnerability.circl.lu/vuln/bell-cve-2023-52625</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Alpaquita:23: linux-lts, Alpaquita:25: 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:25: linux-lts, Alpaquita:stream: linux-lts&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/bell-cve-2023-52625</guid>
    </item>
    <item>
      <title>certfr-2026-avi-0316 — De multiples vulnérabilités ont été découvertes dans les produits VMware. Elles permettent à un attaquant de provoquer…</title>
      <link>https://vulnerability.circl.lu/vuln/certfr-2026-avi-0316</link>
      <description>certfr-2026-avi-0316</description>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/certfr-2026-avi-0316</guid>
    </item>
    <item>
      <title>fkie_cve-2023-52625</title>
      <link>https://vulnerability.circl.lu/vuln/fkie_cve-2023-52625</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;drm/amd/display: Refactor DMCUB enter/exit idle interface&lt;/p&gt;
&lt;p&gt;[Why]
We can hang in place trying to send commands when the DMCUB isn&amp;#39;t
powered on.&lt;/p&gt;
&lt;p&gt;[How]
We need to exit out of the idle state prior to sending a command,
but the process that performs the exit also invokes a command itself.&lt;/p&gt;
&lt;p&gt;Fixing this issue involves the following:&lt;/p&gt;
&lt;p&gt;1. Using a software state to track whether or not we need to start
   the process to exit idle or notify idle.&lt;/p&gt;
&lt;p&gt;It&amp;#39;s possible for the hardware to have exited an idle state without
driver knowledge, but entering one is always restricted to a driver
allow - which makes the SW state vs HW state mismatch issue purely one
of optimization, which should seldomly be hit, if at all.&lt;/p&gt;
&lt;p&gt;2. Refactor any instances of exit/notify idle to use a single wrapper
   that maintains this SW state.&lt;/p&gt;
&lt;p&gt;This works simialr to dc_allow_idle_optimizations, but works at the
DMCUB level and makes sure the state is marked prior to any notify/exit
idle so we don&amp;#39;t enter an infinite loop.&lt;/p&gt;
&lt;p&gt;3. Make sure we exit out of idle prior to sending any commands or
   waiting for DMCUB idle.&lt;/p&gt;
&lt;p&gt;This patch takes care of 1/2. A future patch will take care of wrapping
DMCUB command submission with calls to this new interface.&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;drm/amd/display: Refactor DMCUB enter/exit idle interface&lt;/p&gt;
&lt;p&gt;[Why]
We can hang in place trying to send commands when the DMCUB isn&amp;#39;t
powered on.&lt;/p&gt;
&lt;p&gt;[How]
We need to exit out of the idle state prior to sending a command,
but the process that performs the exit also invokes a command itself.&lt;/p&gt;
&lt;p&gt;Fixing this issue involves the following:&lt;/p&gt;
&lt;p&gt;1. Using a software state to track whether or not we need to start
   the process to exit idle or notify idle.&lt;/p&gt;
&lt;p&gt;It&amp;#39;s possible for the hardware to have exited an idle state without
driver knowledge, but entering one is always restricted to a driver
allow - which makes the SW state vs HW state mismatch issue purely one
of optimization, which should seldomly be hit, if at all.&lt;/p&gt;
&lt;p&gt;2. Refactor any instances of exit/notify idle to use a single wrapper
   that maintains this SW state.&lt;/p&gt;
&lt;p&gt;This works simialr to dc_allow_idle_optimizations, but works at the
DMCUB level and makes sure the state is marked prior to any notify/exit
idle so we don&amp;#39;t enter an infinite loop.&lt;/p&gt;
&lt;p&gt;3. Make sure we exit out of idle prior to sending any commands or
   waiting for DMCUB idle.&lt;/p&gt;
&lt;p&gt;This patch takes care of 1/2. A future patch will take care of wrapping
DMCUB command submission with calls to this new interface.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/fkie_cve-2023-52625</guid>
    </item>
    <item>
      <title>GHSA-78r6-645f-335q</title>
      <link>https://vulnerability.circl.lu/vuln/ghsa-78r6-645f-335q</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;drm/amd/display: Refactor DMCUB enter/exit idle interface&lt;/p&gt;
&lt;p&gt;[Why]
We can hang in place trying to send commands when the DMCUB isn&amp;#39;t
powered on.&lt;/p&gt;
&lt;p&gt;[How]
We need to exit out of the idle state prior to sending a command,
but the process that performs the exit also invokes a command itself.&lt;/p&gt;
&lt;p&gt;Fixing this issue involves the following:&lt;/p&gt;
&lt;p&gt;1. Using a software state to track whether or not we need to start
   the process to exit idle or notify idle.&lt;/p&gt;
&lt;p&gt;It&amp;#39;s possible for the hardware to have exited an idle state without
driver knowledge, but entering one is always restricted to a driver
allow - which makes the SW state vs HW state mismatch issue purely one
of optimization, which should seldomly be hit, if at all.&lt;/p&gt;
&lt;p&gt;2. Refactor any instances of exit/notify idle to use a single wrapper
   that maintains this SW state.&lt;/p&gt;
&lt;p&gt;This works simialr to dc_allow_idle_optimizations, but works at the
DMCUB level and makes sure the state is marked prior to any notify/exit
idle so we don&amp;#39;t enter an infinite loop.&lt;/p&gt;
&lt;p&gt;3. Make sure we exit out of idle prior to sending any commands or
   waiting for DMCUB idle.&lt;/p&gt;
&lt;p&gt;This patch takes care of 1/2. A future patch will take care of wrapping
DMCUB command submission with calls to this new interface.&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;drm/amd/display: Refactor DMCUB enter/exit idle interface&lt;/p&gt;
&lt;p&gt;[Why]
We can hang in place trying to send commands when the DMCUB isn&amp;#39;t
powered on.&lt;/p&gt;
&lt;p&gt;[How]
We need to exit out of the idle state prior to sending a command,
but the process that performs the exit also invokes a command itself.&lt;/p&gt;
&lt;p&gt;Fixing this issue involves the following:&lt;/p&gt;
&lt;p&gt;1. Using a software state to track whether or not we need to start
   the process to exit idle or notify idle.&lt;/p&gt;
&lt;p&gt;It&amp;#39;s possible for the hardware to have exited an idle state without
driver knowledge, but entering one is always restricted to a driver
allow - which makes the SW state vs HW state mismatch issue purely one
of optimization, which should seldomly be hit, if at all.&lt;/p&gt;
&lt;p&gt;2. Refactor any instances of exit/notify idle to use a single wrapper
   that maintains this SW state.&lt;/p&gt;
&lt;p&gt;This works simialr to dc_allow_idle_optimizations, but works at the
DMCUB level and makes sure the state is marked prior to any notify/exit
idle so we don&amp;#39;t enter an infinite loop.&lt;/p&gt;
&lt;p&gt;3. Make sure we exit out of idle prior to sending any commands or
   waiting for DMCUB idle.&lt;/p&gt;
&lt;p&gt;This patch takes care of 1/2. A future patch will take care of wrapping
DMCUB command submission with calls to this new interface.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/ghsa-78r6-645f-335q</guid>
    </item>
    <item>
      <title>gsd-2023-52625</title>
      <link>https://vulnerability.circl.lu/vuln/gsd-2023-52625</link>
      <description>gsd-2023-52625</description>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/gsd-2023-52625</guid>
    </item>
    <item>
      <title>msrc_CVE-2023-52625 — drm/amd/display: Refactor DMCUB enter/exit idle interface</title>
      <link>https://vulnerability.circl.lu/vuln/msrc_cve-2023-52625</link>
      <description>msrc_CVE-2023-52625</description>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/msrc_cve-2023-52625</guid>
    </item>
    <item>
      <title>RHSA-2024:9315 — Red Hat Security Advisory: kernel security update</title>
      <link>https://vulnerability.circl.lu/vuln/rhsa-2024:9315</link>
      <description>&lt;p&gt;kernel: use after free in i2c kernel: bluetooth: BR/EDR Bluetooth Impersonation Attacks (BIAS) kernel: hwmon: (lm90) Prevent integer overflow/underflow in hysteresis calculations kernel: asix: fix uninit-value in asix_mdio_read() kernel: tty: tty_buffer: Fix the softlockup issue in flush_to_ldisc kernel: hwmon: (w83793) Fix NULL pointer dereference by removing unnecessary structure field kernel: hwmon: (w83791d) Fix NULL pointer dereference by removing unnecessary structure field kernel: powerpc/64s: fix program check interrupt emergency stack path kernel: powerpc/64s: Fix unrecoverable MCE calling async handler from NMI kernel: lib/generic-radix-tree.c: Don&amp;#39;t overflow in peek() kernel: powerpc/smp: do not decrement idle task preempt count in CPU offline kernel: can: isotp: isotp_sendmsg(): add result check for wait_event_interruptible() kernel: usbnet: sanity check for maxpacket kernel: nvmem: Fix shift-out-of-bound (UBSAN) with byte size cells kernel: aio: fix use-after-free due to missing POLLFREE handling kernel: powerpc/pseries: Fix potential memleak in papr_get_attr() kernel: of: fdt: fix off-by-one error in unflatten_dt_nodes() kernel: thermal/int340x_thermal: handle data_vault when the value is ZERO_SIZE_PTR kernel: vt_ioctl: fix array_index_nospec in vt_setactivate kernel: bpf: Fix crash due to out of bounds access into reg2btf_ids. kernel: lz4: fix LZ4_decompress_safe_partial read out of bound kernel: x86/mce: Work around an erratum on fast string copy instructions…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;kernel: use after free in i2c kernel: bluetooth: BR/EDR Bluetooth Impersonation Attacks (BIAS) kernel: hwmon: (lm90) Prevent integer overflow/underflow in hysteresis calculations kernel: asix: fix uninit-value in asix_mdio_read() kernel: tty: tty_buffer: Fix the softlockup issue in flush_to_ldisc kernel: hwmon: (w83793) Fix NULL pointer dereference by removing unnecessary structure field kernel: hwmon: (w83791d) Fix NULL pointer dereference by removing unnecessary structure field kernel: powerpc/64s: fix program check interrupt emergency stack path kernel: powerpc/64s: Fix unrecoverable MCE calling async handler from NMI kernel: lib/generic-radix-tree.c: Don&amp;#39;t overflow in peek() kernel: powerpc/smp: do not decrement idle task preempt count in CPU offline kernel: can: isotp: isotp_sendmsg(): add result check for wait_event_interruptible() kernel: usbnet: sanity check for maxpacket kernel: nvmem: Fix shift-out-of-bound (UBSAN) with byte size cells kernel: aio: fix use-after-free due to missing POLLFREE handling kernel: powerpc/pseries: Fix potential memleak in papr_get_attr() kernel: of: fdt: fix off-by-one error in unflatten_dt_nodes() kernel: thermal/int340x_thermal: handle data_vault when the value is ZERO_SIZE_PTR kernel: vt_ioctl: fix array_index_nospec in vt_setactivate kernel: bpf: Fix crash due to out of bounds access into reg2btf_ids. kernel: lz4: fix LZ4_decompress_safe_partial read out of bound kernel: x86/mce: Work around an erratum on fast string copy instructions…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/rhsa-2024:9315</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2023-52625</title>
      <link>https://vulnerability.circl.lu/vuln/ubuntu-cve-2023-52625</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 107 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Refactor DMCUB enter/exit idle interface [Why] We can hang in place trying to send commands when the DMCUB isn&amp;#39;t powered on. [How] We need to exit out of the idle state prior to sending a command, but the process that performs the exit also invokes a command itself. Fixing this issue involves the following: 1. Using a software state to track whether or not we need to start    the process to exit idle or notify idle. It&amp;#39;s possible for the hardware to have exited an idle state without driver knowledge, but entering one is always restricted to a driver allow - which makes the SW state vs HW state mismatch issue purely one of optimization, which should seldomly be hit, if at all. 2. Refactor any instances of exit/notify idle to use a single wrapper    that maintains this SW state. This works simialr to dc_allow_idle_optimizations, but works at the DMCUB level and makes sure the state is marked prior to any notify/exit idle so we don&amp;#39;t enter an infinite loop. 3. Make sure we exit out of idle prior to sending any commands or    waiting for DMCUB idle. This patch takes care of 1/2. A future patch will take care of wrapping DMCUB command submission with calls to this new interface.&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 107 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Refactor DMCUB enter/exit idle interface [Why] We can hang in place trying to send commands when the DMCUB isn&amp;#39;t powered on. [How] We need to exit out of the idle state prior to sending a command, but the process that performs the exit also invokes a command itself. Fixing this issue involves the following: 1. Using a software state to track whether or not we need to start    the process to exit idle or notify idle. It&amp;#39;s possible for the hardware to have exited an idle state without driver knowledge, but entering one is always restricted to a driver allow - which makes the SW state vs HW state mismatch issue purely one of optimization, which should seldomly be hit, if at all. 2. Refactor any instances of exit/notify idle to use a single wrapper    that maintains this SW state. This works simialr to dc_allow_idle_optimizations, but works at the DMCUB level and makes sure the state is marked prior to any notify/exit idle so we don&amp;#39;t enter an infinite loop. 3. Make sure we exit out of idle prior to sending any commands or    waiting for DMCUB idle. This patch takes care of 1/2. A future patch will take care of wrapping DMCUB command submission with calls to this new interface.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/ubuntu-cve-2023-52625</guid>
    </item>
    <item>
      <title>WID-SEC-W-2024-0722 — Linux Kernel: Mehrere Schwachstellen</title>
      <link>https://vulnerability.circl.lu/vuln/wid-sec-w-2024-0722</link>
      <description>&lt;p&gt;Ein lokaler Angreifer kann mehrere Schwachstellen im Linux-Kernel ausnutzen, um Dateien zu manipulieren, unbekannte Effekte zu verursachen oder einen Denial-of-Service-Zustand auszulösen.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Ein lokaler Angreifer kann mehrere Schwachstellen im Linux-Kernel ausnutzen, um Dateien zu manipulieren, unbekannte Effekte zu verursachen oder einen Denial-of-Service-Zustand auszulösen.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/wid-sec-w-2024-0722</guid>
    </item>
  </channel>
</rss>
