<?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 19:20:50 +0000</lastBuildDate>
    <item>
      <title>bdu:2026-08732</title>
      <link>https://db.gcve.eu/vuln/bdu:2026-08732</link>
      <description>bdu:2026-08732</description>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/bdu:2026-08732</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://db.gcve.eu/vuln/certfr-2026-avi-0316</link>
      <description>certfr-2026-avi-0316</description>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/certfr-2026-avi-0316</guid>
    </item>
    <item>
      <title>fkie_cve-2022-50616</title>
      <link>https://db.gcve.eu/vuln/fkie_cve-2022-50616</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;regulator: core: Use different devices for resource allocation and DT lookup&lt;/p&gt;
&lt;p&gt;Following by the below discussion, there&amp;#39;s the potential UAF issue
between regulator and mfd.
https://lore.kernel.org/all/20221128143601.1698148-1-yangyingliang@huawei.com/&lt;/p&gt;
&lt;p&gt;From the analysis of Yingliang&lt;/p&gt;
&lt;p&gt;CPU A				|CPU B
mt6370_probe()			|
  devm_mfd_add_devices()	|
				|mt6370_regulator_probe()
				|  regulator_register()
				|    //allocate init_data and add it to devres
				|    regulator_of_get_init_data()
i2c_unregister_device()		|
  device_del()			|
    devres_release_all()	|
      // init_data is freed	|
      release_nodes()		|
				|  // using init_data causes UAF
				|  regulator_register()&lt;/p&gt;
&lt;p&gt;It&amp;#39;s common to use mfd core to create child device for the regulator.
In order to do the DT lookup for init data, the child that registered
the regulator would pass its parent as the parameter. And this causes
init data resource allocated to its parent, not itself. The issue happen
when parent device is going to release and regulator core is still doing
some operation of init data constraint for the regulator of child device.&lt;/p&gt;
&lt;p&gt;To fix it, this patch expand &amp;#39;regulator_register&amp;#39; API to use the
different devices for init data allocation and DT lookup.&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;regulator: core: Use different devices for resource allocation and DT lookup&lt;/p&gt;
&lt;p&gt;Following by the below discussion, there&amp;#39;s the potential UAF issue
between regulator and mfd.
https://lore.kernel.org/all/20221128143601.1698148-1-yangyingliang@huawei.com/&lt;/p&gt;
&lt;p&gt;From the analysis of Yingliang&lt;/p&gt;
&lt;p&gt;CPU A				|CPU B
mt6370_probe()			|
  devm_mfd_add_devices()	|
				|mt6370_regulator_probe()
				|  regulator_register()
				|    //allocate init_data and add it to devres
				|    regulator_of_get_init_data()
i2c_unregister_device()		|
  device_del()			|
    devres_release_all()	|
      // init_data is freed	|
      release_nodes()		|
				|  // using init_data causes UAF
				|  regulator_register()&lt;/p&gt;
&lt;p&gt;It&amp;#39;s common to use mfd core to create child device for the regulator.
In order to do the DT lookup for init data, the child that registered
the regulator would pass its parent as the parameter. And this causes
init data resource allocated to its parent, not itself. The issue happen
when parent device is going to release and regulator core is still doing
some operation of init data constraint for the regulator of child device.&lt;/p&gt;
&lt;p&gt;To fix it, this patch expand &amp;#39;regulator_register&amp;#39; API to use the
different devices for init data allocation and DT lookup.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/fkie_cve-2022-50616</guid>
    </item>
    <item>
      <title>GHSA-4gcp-hx9q-5r25</title>
      <link>https://db.gcve.eu/vuln/ghsa-4gcp-hx9q-5r25</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;regulator: core: Use different devices for resource allocation and DT lookup&lt;/p&gt;
&lt;p&gt;Following by the below discussion, there&amp;#39;s the potential UAF issue
between regulator and mfd.
https://lore.kernel.org/all/20221128143601.1698148-1-yangyingliang@huawei.com/&lt;/p&gt;
&lt;p&gt;From the analysis of Yingliang&lt;/p&gt;
&lt;p&gt;CPU A				|CPU B
mt6370_probe()			|
  devm_mfd_add_devices()	|
				|mt6370_regulator_probe()
				|  regulator_register()
				|    //allocate init_data and add it to devres
				|    regulator_of_get_init_data()
i2c_unregister_device()		|
  device_del()			|
    devres_release_all()	|
      // init_data is freed	|
      release_nodes()		|
				|  // using init_data causes UAF
				|  regulator_register()&lt;/p&gt;
&lt;p&gt;It&amp;#39;s common to use mfd core to create child device for the regulator.
In order to do the DT lookup for init data, the child that registered
the regulator would pass its parent as the parameter. And this causes
init data resource allocated to its parent, not itself. The issue happen
when parent device is going to release and regulator core is still doing
some operation of init data constraint for the regulator of child device.&lt;/p&gt;
&lt;p&gt;To fix it, this patch expand &amp;#39;regulator_register&amp;#39; API to use the
different devices for init data allocation and DT lookup.&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;regulator: core: Use different devices for resource allocation and DT lookup&lt;/p&gt;
&lt;p&gt;Following by the below discussion, there&amp;#39;s the potential UAF issue
between regulator and mfd.
https://lore.kernel.org/all/20221128143601.1698148-1-yangyingliang@huawei.com/&lt;/p&gt;
&lt;p&gt;From the analysis of Yingliang&lt;/p&gt;
&lt;p&gt;CPU A				|CPU B
mt6370_probe()			|
  devm_mfd_add_devices()	|
				|mt6370_regulator_probe()
				|  regulator_register()
				|    //allocate init_data and add it to devres
				|    regulator_of_get_init_data()
i2c_unregister_device()		|
  device_del()			|
    devres_release_all()	|
      // init_data is freed	|
      release_nodes()		|
				|  // using init_data causes UAF
				|  regulator_register()&lt;/p&gt;
&lt;p&gt;It&amp;#39;s common to use mfd core to create child device for the regulator.
In order to do the DT lookup for init data, the child that registered
the regulator would pass its parent as the parameter. And this causes
init data resource allocated to its parent, not itself. The issue happen
when parent device is going to release and regulator core is still doing
some operation of init data constraint for the regulator of child device.&lt;/p&gt;
&lt;p&gt;To fix it, this patch expand &amp;#39;regulator_register&amp;#39; API to use the
different devices for init data allocation and DT lookup.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/ghsa-4gcp-hx9q-5r25</guid>
    </item>
    <item>
      <title>OESA-2026-1341 — kernel security update</title>
      <link>https://db.gcve.eu/vuln/oesa-2026-1341</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; openEuler:22.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:kernel/resource: fix kfree() of bootmem memory againSince commit ebff7d8f270d ( mem hotunplug: fix kfree() of bootmemmemory ), we could get a resource allocated during boot viaalloc_resource().  And it s required to release the resource usingfree_resource().  Howerver, many people use kfree directly which willresult in kernel BUG.  In order to fix this without fixing every callsite, just leak a couple of bytes in such corner case.(CVE-2022-49190)&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:drivers: staging: rtl8723bs: Fix deadlock in rtw_surveydone_event_callback()There is a deadlock in rtw_surveydone_event_callback(),which is shown below:   (Thread 1)                  |      (Thread 2)                               | _set_timer()rtw_surveydone_event_callback()|  mod_timer() spin_lock_bh() //(1)          |  (wait a time) ...                           | rtw_scan_timeout_handler() del_timer_sync()              |  spin_lock_bh() //(2) (wait timer to stop)          |  ...We hold pmlmepriv-&amp;amp;gt;lock in position (1) of thread 1 and usedel_timer_sync() to wait timer to stop, but timer handleralso need pmlmepriv-&amp;amp;gt;lock in position (2) of thread 2.As a result, rtw_surveydone_event_callback() will block forever.This patch extracts del_timer_sync() from the protection ofspin_lock_bh(), which could let timer handler to obta…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; openEuler:22.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:kernel/resource: fix kfree() of bootmem memory againSince commit ebff7d8f270d ( mem hotunplug: fix kfree() of bootmemmemory ), we could get a resource allocated during boot viaalloc_resource().  And it s required to release the resource usingfree_resource().  Howerver, many people use kfree directly which willresult in kernel BUG.  In order to fix this without fixing every callsite, just leak a couple of bytes in such corner case.(CVE-2022-49190)&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:drivers: staging: rtl8723bs: Fix deadlock in rtw_surveydone_event_callback()There is a deadlock in rtw_surveydone_event_callback(),which is shown below:   (Thread 1)                  |      (Thread 2)                               | _set_timer()rtw_surveydone_event_callback()|  mod_timer() spin_lock_bh() //(1)          |  (wait a time) ...                           | rtw_scan_timeout_handler() del_timer_sync()              |  spin_lock_bh() //(2) (wait timer to stop)          |  ...We hold pmlmepriv-&amp;amp;gt;lock in position (1) of thread 1 and usedel_timer_sync() to wait timer to stop, but timer handleralso need pmlmepriv-&amp;amp;gt;lock in position (2) of thread 2.As a result, rtw_surveydone_event_callback() will block forever.This patch extracts del_timer_sync() from the protection ofspin_lock_bh(), which could let timer handler to obta…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/oesa-2026-1341</guid>
    </item>
    <item>
      <title>RHSA-2023:6583 — Red Hat Security Advisory: kernel security, bug fix, and enhancement update</title>
      <link>https://db.gcve.eu/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://db.gcve.eu/vuln/rhsa-2023:6583</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2022-50616</title>
      <link>https://db.gcve.eu/vuln/ubuntu-cve-2022-50616</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 171 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: regulator: core: Use different devices for resource allocation and DT lookup Following by the below discussion, there&amp;#39;s the potential UAF issue between regulator and mfd. https://lore.kernel.org/all/20221128143601.1698148-1-yangyingliang@huawei.com/ From the analysis of Yingliang CPU A				|CPU B mt6370_probe()			|   devm_mfd_add_devices()	| 				|mt6370_regulator_probe() 				|  regulator_register() 				|    //allocate init_data and add it to devres 				|    regulator_of_get_init_data() i2c_unregister_device()		|   device_del()			|     devres_release_all()	|       // init_data is freed	|       release_nodes()		| 				|  // using init_data causes UAF 				|  regulator_register() It&amp;#39;s common to use mfd core to create child device for the regulator. In order to do the DT lookup for init data, the child that registered the regulator would pass its parent as the parameter. And this causes init data resource allocated to its parent, not itself. The issue happen when parent device is going to release and regulator core is still doing some operation of init data constraint for the regulator of child device. To fix it, this patch expand &amp;#39;regulator_register&amp;#39; API to use the different devices for init data allocation and DT lookup.&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 171 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: regulator: core: Use different devices for resource allocation and DT lookup Following by the below discussion, there&amp;#39;s the potential UAF issue between regulator and mfd. https://lore.kernel.org/all/20221128143601.1698148-1-yangyingliang@huawei.com/ From the analysis of Yingliang CPU A				|CPU B mt6370_probe()			|   devm_mfd_add_devices()	| 				|mt6370_regulator_probe() 				|  regulator_register() 				|    //allocate init_data and add it to devres 				|    regulator_of_get_init_data() i2c_unregister_device()		|   device_del()			|     devres_release_all()	|       // init_data is freed	|       release_nodes()		| 				|  // using init_data causes UAF 				|  regulator_register() It&amp;#39;s common to use mfd core to create child device for the regulator. In order to do the DT lookup for init data, the child that registered the regulator would pass its parent as the parameter. And this causes init data resource allocated to its parent, not itself. The issue happen when parent device is going to release and regulator core is still doing some operation of init data constraint for the regulator of child device. To fix it, this patch expand &amp;#39;regulator_register&amp;#39; API to use the different devices for init data allocation and DT lookup.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/ubuntu-cve-2022-50616</guid>
    </item>
    <item>
      <title>WID-SEC-W-2025-2756 — Linux Kernel: Mehrere Schwachstellen ermöglichen Denial of Service</title>
      <link>https://db.gcve.eu/vuln/wid-sec-w-2025-2756</link>
      <description>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen Denial-of-Service-Zustand zu erzeugen oder weitere, nicht spezifizierte Auswirkungen zu erlangen.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen Denial-of-Service-Zustand zu erzeugen oder weitere, nicht spezifizierte Auswirkungen zu erlangen.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/wid-sec-w-2025-2756</guid>
    </item>
  </channel>
</rss>
