https://db.gcve.eu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Tue, 03 Nov 2026 22:44:18 +0000 https://db.gcve.eu/vuln/certfr-2026-avi-1375 certfr-2026-avi-1375 https://db.gcve.eu/vuln/certfr-2026-avi-1375 https://db.gcve.eu/vuln/fkie_cve-2026-98826 <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>rtc: ac100: Fix clock provider use-after-free on probe failure</p> <p>ac100_rtc_register_clks() registers the RTC-32k clock with clk_hw_register_fixed_rate() and the clock provider with of_clk_add_hw_provider(). Neither is device managed, and both are released only from ac100_rtc_remove(). The driver core does not call remove() when probe() fails: really_probe() reaches probe_failed below the device_remove() call and goes straight to releasing the device&#39;s managed resources.</p> <p>ac100_rtc_probe() ends with</p> <p>return devm_rtc_register_device(chip-&gt;rtc);</p> <p>so if that fails after the clocks have been registered, the provider is left on the global of_clk_providers list holding chip-&gt;clk_data, which was allocated with devm_kzalloc() and is freed while probe() unwinds. A later lookup on this device tree node then reads freed memory in of_clk_hw_onecell_get(). Consumers that do exactly that exist in tree: the wifi power sequence nodes on sun8i-a83t-bananapi-m3 and sun8i-a83t-cubietruck-plus take &lt;&amp;ac100_rtc 1&gt;, and the sun9i-a80 boards route osc32k through &lt;&amp;ac100_rtc 0&gt;. The window is narrow, as devm_rtc_register_device() can only fail with -ENOMEM here, but the provider is left dangling whenever it does.</p> <p>The RTC-32k clock is leaked on the same path. Since clk_core_lookup() searches a global list that is not scoped per device, __clk_register() rejects the duplicate name with -EEXIST, so the leak also makes a later probe of…</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>rtc: ac100: Fix clock provider use-after-free on probe failure</p> <p>ac100_rtc_register_clks() registers the RTC-32k clock with clk_hw_register_fixed_rate() and the clock provider with of_clk_add_hw_provider(). Neither is device managed, and both are released only from ac100_rtc_remove(). The driver core does not call remove() when probe() fails: really_probe() reaches probe_failed below the device_remove() call and goes straight to releasing the device&#39;s managed resources.</p> <p>ac100_rtc_probe() ends with</p> <p>return devm_rtc_register_device(chip-&gt;rtc);</p> <p>so if that fails after the clocks have been registered, the provider is left on the global of_clk_providers list holding chip-&gt;clk_data, which was allocated with devm_kzalloc() and is freed while probe() unwinds. A later lookup on this device tree node then reads freed memory in of_clk_hw_onecell_get(). Consumers that do exactly that exist in tree: the wifi power sequence nodes on sun8i-a83t-bananapi-m3 and sun8i-a83t-cubietruck-plus take &lt;&amp;ac100_rtc 1&gt;, and the sun9i-a80 boards route osc32k through &lt;&amp;ac100_rtc 0&gt;. The window is narrow, as devm_rtc_register_device() can only fail with -ENOMEM here, but the provider is left dangling whenever it does.</p> <p>The RTC-32k clock is leaked on the same path. Since clk_core_lookup() searches a global list that is not scoped per device, __clk_register() rejects the duplicate name with -EEXIST, so the leak also makes a later probe of…</p> https://db.gcve.eu/vuln/fkie_cve-2026-98826 https://db.gcve.eu/vuln/ghsa-vm74-3mf5-j459 <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>rtc: ac100: Fix clock provider use-after-free on probe failure</p> <p>ac100_rtc_register_clks() registers the RTC-32k clock with clk_hw_register_fixed_rate() and the clock provider with of_clk_add_hw_provider(). Neither is device managed, and both are released only from ac100_rtc_remove(). The driver core does not call remove() when probe() fails: really_probe() reaches probe_failed below the device_remove() call and goes straight to releasing the device&#39;s managed resources.</p> <p>ac100_rtc_probe() ends with</p> <p>return devm_rtc_register_device(chip-&gt;rtc);</p> <p>so if that fails after the clocks have been registered, the provider is left on the global of_clk_providers list holding chip-&gt;clk_data, which was allocated with devm_kzalloc() and is freed while probe() unwinds. A later lookup on this device tree node then reads freed memory in of_clk_hw_onecell_get(). Consumers that do exactly that exist in tree: the wifi power sequence nodes on sun8i-a83t-bananapi-m3 and sun8i-a83t-cubietruck-plus take &lt;&amp;ac100_rtc 1&gt;, and the sun9i-a80 boards route osc32k through &lt;&amp;ac100_rtc 0&gt;. The window is narrow, as devm_rtc_register_device() can only fail with -ENOMEM here, but the provider is left dangling whenever it does.</p> <p>The RTC-32k clock is leaked on the same path. Since clk_core_lookup() searches a global list that is not scoped per device, __clk_register() rejects the duplicate name with -EEXIST, so the leak also makes a later probe of…</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>rtc: ac100: Fix clock provider use-after-free on probe failure</p> <p>ac100_rtc_register_clks() registers the RTC-32k clock with clk_hw_register_fixed_rate() and the clock provider with of_clk_add_hw_provider(). Neither is device managed, and both are released only from ac100_rtc_remove(). The driver core does not call remove() when probe() fails: really_probe() reaches probe_failed below the device_remove() call and goes straight to releasing the device&#39;s managed resources.</p> <p>ac100_rtc_probe() ends with</p> <p>return devm_rtc_register_device(chip-&gt;rtc);</p> <p>so if that fails after the clocks have been registered, the provider is left on the global of_clk_providers list holding chip-&gt;clk_data, which was allocated with devm_kzalloc() and is freed while probe() unwinds. A later lookup on this device tree node then reads freed memory in of_clk_hw_onecell_get(). Consumers that do exactly that exist in tree: the wifi power sequence nodes on sun8i-a83t-bananapi-m3 and sun8i-a83t-cubietruck-plus take &lt;&amp;ac100_rtc 1&gt;, and the sun9i-a80 boards route osc32k through &lt;&amp;ac100_rtc 0&gt;. The window is narrow, as devm_rtc_register_device() can only fail with -ENOMEM here, but the provider is left dangling whenever it does.</p> <p>The RTC-32k clock is leaked on the same path. Since clk_core_lookup() searches a global list that is not scoped per device, __clk_register() rejects the duplicate name with -EEXIST, so the leak also makes a later probe of…</p> https://db.gcve.eu/vuln/ghsa-vm74-3mf5-j459 https://db.gcve.eu/vuln/msrc_cve-2026-98826 msrc_CVE-2026-98826 https://db.gcve.eu/vuln/msrc_cve-2026-98826 https://db.gcve.eu/vuln/ubuntu-cve-2026-98826 <p><strong>Affected:</strong> Ubuntu:Pro:14.04:LTS: linux-azure, 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, Ubuntu:Pro:16.04:LTS: linux-oracle, Ubuntu:Pro:18.04:LTS: linux, Ubuntu:Pro:18.04:LTS: linux-aws, Ubuntu:18.04:LTS: linux-aws-5.0 and 239 more</p> <p>In the Linux kernel, the following vulnerability has been resolved: rtc: ac100: Fix clock provider use-after-free on probe failure ac100_rtc_register_clks() registers the RTC-32k clock with clk_hw_register_fixed_rate() and the clock provider with of_clk_add_hw_provider(). Neither is device managed, and both are released only from ac100_rtc_remove(). The driver core does not call remove() when probe() fails: really_probe() reaches probe_failed below the device_remove() call and goes straight to releasing the device&#39;s managed resources. ac100_rtc_probe() ends with return devm_rtc_register_device(chip-&gt;rtc); so if that fails after the clocks have been registered, the provider is left on the global of_clk_providers list holding chip-&gt;clk_data, which was allocated with devm_kzalloc() and is freed while probe() unwinds. A later lookup on this device tree node then reads freed memory in of_clk_hw_onecell_get(). Consumers that do exactly that exist in tree: the wifi power sequence nodes on sun8i-a83t-bananapi-m3 and sun8i-a83t-cubietruck-plus take &lt;&amp;ac100_rtc 1&gt;, and the sun9i-a80 boards route osc32k through &lt;&amp;ac100_rtc 0&gt;. The window is narrow, as devm_rtc_register_device() can only fail with -ENOMEM here, but the provider is left dangling whenever it does. The RTC-32k clock is leaked on the same path. Since clk_core_lookup() searches a global list that is not scoped per device, __clk_register() rejects the duplicate name with -EEXIST, so the leak also makes a later probe of the s…</p> <p><strong>Affected:</strong> Ubuntu:Pro:14.04:LTS: linux-azure, 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, Ubuntu:Pro:16.04:LTS: linux-oracle, Ubuntu:Pro:18.04:LTS: linux, Ubuntu:Pro:18.04:LTS: linux-aws, Ubuntu:18.04:LTS: linux-aws-5.0 and 239 more</p> <p>In the Linux kernel, the following vulnerability has been resolved: rtc: ac100: Fix clock provider use-after-free on probe failure ac100_rtc_register_clks() registers the RTC-32k clock with clk_hw_register_fixed_rate() and the clock provider with of_clk_add_hw_provider(). Neither is device managed, and both are released only from ac100_rtc_remove(). The driver core does not call remove() when probe() fails: really_probe() reaches probe_failed below the device_remove() call and goes straight to releasing the device&#39;s managed resources. ac100_rtc_probe() ends with return devm_rtc_register_device(chip-&gt;rtc); so if that fails after the clocks have been registered, the provider is left on the global of_clk_providers list holding chip-&gt;clk_data, which was allocated with devm_kzalloc() and is freed while probe() unwinds. A later lookup on this device tree node then reads freed memory in of_clk_hw_onecell_get(). Consumers that do exactly that exist in tree: the wifi power sequence nodes on sun8i-a83t-bananapi-m3 and sun8i-a83t-cubietruck-plus take &lt;&amp;ac100_rtc 1&gt;, and the sun9i-a80 boards route osc32k through &lt;&amp;ac100_rtc 0&gt;. The window is narrow, as devm_rtc_register_device() can only fail with -ENOMEM here, but the provider is left dangling whenever it does. The RTC-32k clock is leaked on the same path. Since clk_core_lookup() searches a global list that is not scoped per device, __clk_register() rejects the duplicate name with -EEXIST, so the leak also makes a later probe of the s…</p> https://db.gcve.eu/vuln/ubuntu-cve-2026-98826 https://db.gcve.eu/vuln/wid-sec-w-2026-4019 <p>Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen nicht näher spezifizierten Angriff durchzuführen, möglicherweise einen Denial-of-Service-Angriff auszulösen, Daten zu manipulieren oder offenzulegen oder Sicherheitsmaßnahmen zu umgehen.</p> <p>Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen nicht näher spezifizierten Angriff durchzuführen, möglicherweise einen Denial-of-Service-Angriff auszulösen, Daten zu manipulieren oder offenzulegen oder Sicherheitsmaßnahmen zu umgehen.</p> https://db.gcve.eu/vuln/wid-sec-w-2026-4019