https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Sat, 03 Oct 2026 09:09:16 +0000 https://cve.radiocsirt.org/vuln/bdu:2026-11775 bdu:2026-11775 https://cve.radiocsirt.org/vuln/bdu:2026-11775 https://cve.radiocsirt.org/vuln/bell-cve-2026-45914 <p><strong>Affected:</strong> Alpaquita:23: linux-lts, Alpaquita:25: linux-lts</p> <p><strong>Affected:</strong> Alpaquita:23: linux-lts, Alpaquita:25: linux-lts</p> https://cve.radiocsirt.org/vuln/bell-cve-2026-45914 https://cve.radiocsirt.org/vuln/certfr-2026-avi-0696 certfr-2026-avi-0696 https://cve.radiocsirt.org/vuln/certfr-2026-avi-0696 https://cve.radiocsirt.org/vuln/euvd-2026-321827 EUVD-2026-321827 https://cve.radiocsirt.org/vuln/euvd-2026-321827 https://cve.radiocsirt.org/vuln/fkie_cve-2026-45914 <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>Revert &#34;hwmon: (ibmpex) fix use-after-free in high/low store&#34;</p> <p>This reverts commit 6946c726c3f4c36f0f049e6f97e88c510b15f65d.</p> <p>Jean Delvare points out that the patch does not completely fix the reported problem, that it in fact introduces a (new) race condition, and that it may actually not be needed in the first place.</p> <p>Various AI reviews agree. Specific and relevant AI feedback:</p> <p>&#34; This reordering sets the driver data to NULL before removing the sensor attributes in the loop below.</p> <p>ibmpex_show_sensor() retrieves this driver data via dev_get_drvdata() but does not check if it is NULL before dereferencing it to access data-&gt;sensors[].</p> <p>If a userspace process reads a sensor file (like temp1_input) while this delete function is running, could it race with the dev_set_drvdata(..., NULL) call here and crash in ibmpex_show_sensor()?</p> <p>Would it be safer to keep the original order where device_remove_file() is called before clearing the driver data? device_remove_file() should wait for any active sysfs callbacks to complete, which might already prevent the use-after-free this patch intends to fix. &#34;</p> <p>Revert the offending patch. If it can be shown that the originally reported alleged race condition does indeed exist, it can always be re-introduced with a complete fix.</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>Revert &#34;hwmon: (ibmpex) fix use-after-free in high/low store&#34;</p> <p>This reverts commit 6946c726c3f4c36f0f049e6f97e88c510b15f65d.</p> <p>Jean Delvare points out that the patch does not completely fix the reported problem, that it in fact introduces a (new) race condition, and that it may actually not be needed in the first place.</p> <p>Various AI reviews agree. Specific and relevant AI feedback:</p> <p>&#34; This reordering sets the driver data to NULL before removing the sensor attributes in the loop below.</p> <p>ibmpex_show_sensor() retrieves this driver data via dev_get_drvdata() but does not check if it is NULL before dereferencing it to access data-&gt;sensors[].</p> <p>If a userspace process reads a sensor file (like temp1_input) while this delete function is running, could it race with the dev_set_drvdata(..., NULL) call here and crash in ibmpex_show_sensor()?</p> <p>Would it be safer to keep the original order where device_remove_file() is called before clearing the driver data? device_remove_file() should wait for any active sysfs callbacks to complete, which might already prevent the use-after-free this patch intends to fix. &#34;</p> <p>Revert the offending patch. If it can be shown that the originally reported alleged race condition does indeed exist, it can always be re-introduced with a complete fix.</p> https://cve.radiocsirt.org/vuln/fkie_cve-2026-45914 https://cve.radiocsirt.org/vuln/ghsa-wf7m-gffh-f29c <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>Revert &#34;hwmon: (ibmpex) fix use-after-free in high/low store&#34;</p> <p>This reverts commit 6946c726c3f4c36f0f049e6f97e88c510b15f65d.</p> <p>Jean Delvare points out that the patch does not completely fix the reported problem, that it in fact introduces a (new) race condition, and that it may actually not be needed in the first place.</p> <p>Various AI reviews agree. Specific and relevant AI feedback:</p> <p>&#34; This reordering sets the driver data to NULL before removing the sensor attributes in the loop below.</p> <p>ibmpex_show_sensor() retrieves this driver data via dev_get_drvdata() but does not check if it is NULL before dereferencing it to access data-&gt;sensors[].</p> <p>If a userspace process reads a sensor file (like temp1_input) while this delete function is running, could it race with the dev_set_drvdata(..., NULL) call here and crash in ibmpex_show_sensor()?</p> <p>Would it be safer to keep the original order where device_remove_file() is called before clearing the driver data? device_remove_file() should wait for any active sysfs callbacks to complete, which might already prevent the use-after-free this patch intends to fix. &#34;</p> <p>Revert the offending patch. If it can be shown that the originally reported alleged race condition does indeed exist, it can always be re-introduced with a complete fix.</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>Revert &#34;hwmon: (ibmpex) fix use-after-free in high/low store&#34;</p> <p>This reverts commit 6946c726c3f4c36f0f049e6f97e88c510b15f65d.</p> <p>Jean Delvare points out that the patch does not completely fix the reported problem, that it in fact introduces a (new) race condition, and that it may actually not be needed in the first place.</p> <p>Various AI reviews agree. Specific and relevant AI feedback:</p> <p>&#34; This reordering sets the driver data to NULL before removing the sensor attributes in the loop below.</p> <p>ibmpex_show_sensor() retrieves this driver data via dev_get_drvdata() but does not check if it is NULL before dereferencing it to access data-&gt;sensors[].</p> <p>If a userspace process reads a sensor file (like temp1_input) while this delete function is running, could it race with the dev_set_drvdata(..., NULL) call here and crash in ibmpex_show_sensor()?</p> <p>Would it be safer to keep the original order where device_remove_file() is called before clearing the driver data? device_remove_file() should wait for any active sysfs callbacks to complete, which might already prevent the use-after-free this patch intends to fix. &#34;</p> <p>Revert the offending patch. If it can be shown that the originally reported alleged race condition does indeed exist, it can always be re-introduced with a complete fix.</p> https://cve.radiocsirt.org/vuln/ghsa-wf7m-gffh-f29c https://cve.radiocsirt.org/vuln/oesa-2026-2674 <p><strong>Affected:</strong> openEuler:22.03-LTS-SP4: kernel</p> <p>The Linux Kernel, the operating system core itself. Security Fix(es):</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>btrfs: qgroup: fix race between quota disable and quota rescan ioctl</p> <p>There&amp;apos;s a race between a task disabling quotas and another running the rescan ioctl that can result in a use-after-free of qgroup records from the fs_info-&amp;gt;qgroup_tree rbtree.</p> <p>This happens as follows:</p> <p>1) Task A enters btrfs_ioctl_quota_rescan() -&amp;gt; btrfs_qgroup_rescan();</p> <p>2) Task B enters btrfs_quota_disable() and calls btrfs_qgroup_wait_for_completion(), which does nothing because at that point fs_info-&amp;gt;qgroup_rescan_running is false (it wasn&amp;apos;t set yet by task A);</p> <p>3) Task B calls btrfs_free_qgroup_config() which starts freeing qgroups from fs_info-&amp;gt;qgroup_tree without taking the lock fs_info-&amp;gt;qgroup_lock;</p> <p>4) Task A enters qgroup_rescan_zero_tracking() which starts iterating the fs_info-&amp;gt;qgroup_tree tree while holding fs_info-&amp;gt;qgroup_lock, but task B is freeing qgroup records from that tree without holding the lock, resulting in a use-after-free.</p> <p>Fix this by taking fs_info-&amp;gt;qgroup_lock at btrfs_free_qgroup_config(). Also at btrfs_qgroup_rescan() don&amp;apos;t start the rescan worker if quotas were already disabled.(CVE-2025-39759)</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>wifi: wilc1000: avoid buffer overflow in WID string configuration</p> <p>Fix the following copy overflow warning identi…</p> <p><strong>Affected:</strong> openEuler:22.03-LTS-SP4: kernel</p> <p>The Linux Kernel, the operating system core itself. Security Fix(es):</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>btrfs: qgroup: fix race between quota disable and quota rescan ioctl</p> <p>There&amp;apos;s a race between a task disabling quotas and another running the rescan ioctl that can result in a use-after-free of qgroup records from the fs_info-&amp;gt;qgroup_tree rbtree.</p> <p>This happens as follows:</p> <p>1) Task A enters btrfs_ioctl_quota_rescan() -&amp;gt; btrfs_qgroup_rescan();</p> <p>2) Task B enters btrfs_quota_disable() and calls btrfs_qgroup_wait_for_completion(), which does nothing because at that point fs_info-&amp;gt;qgroup_rescan_running is false (it wasn&amp;apos;t set yet by task A);</p> <p>3) Task B calls btrfs_free_qgroup_config() which starts freeing qgroups from fs_info-&amp;gt;qgroup_tree without taking the lock fs_info-&amp;gt;qgroup_lock;</p> <p>4) Task A enters qgroup_rescan_zero_tracking() which starts iterating the fs_info-&amp;gt;qgroup_tree tree while holding fs_info-&amp;gt;qgroup_lock, but task B is freeing qgroup records from that tree without holding the lock, resulting in a use-after-free.</p> <p>Fix this by taking fs_info-&amp;gt;qgroup_lock at btrfs_free_qgroup_config(). Also at btrfs_qgroup_rescan() don&amp;apos;t start the rescan worker if quotas were already disabled.(CVE-2025-39759)</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>wifi: wilc1000: avoid buffer overflow in WID string configuration</p> <p>Fix the following copy overflow warning identi…</p> https://cve.radiocsirt.org/vuln/oesa-2026-2674 https://cve.radiocsirt.org/vuln/suse-su-2026:23193-1 <p>Security update for the Linux Kernel</p> <p>Security update for the Linux Kernel</p> https://cve.radiocsirt.org/vuln/suse-su-2026:23193-1 https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-45914 <p><strong>Affected:</strong> 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 136 more</p> <p>In the Linux kernel, the following vulnerability has been resolved: Revert &#34;hwmon: (ibmpex) fix use-after-free in high/low store&#34; This reverts commit 6946c726c3f4c36f0f049e6f97e88c510b15f65d. Jean Delvare points out that the patch does not completely fix the reported problem, that it in fact introduces a (new) race condition, and that it may actually not be needed in the first place. Various AI reviews agree. Specific and relevant AI feedback: &#34; This reordering sets the driver data to NULL before removing the sensor attributes in the loop below. ibmpex_show_sensor() retrieves this driver data via dev_get_drvdata() but does not check if it is NULL before dereferencing it to access data-&gt;sensors[]. If a userspace process reads a sensor file (like temp1_input) while this delete function is running, could it race with the dev_set_drvdata(..., NULL) call here and crash in ibmpex_show_sensor()? Would it be safer to keep the original order where device_remove_file() is called before clearing the driver data? device_remove_file() should wait for any active sysfs callbacks to complete, which might already prevent the use-after-free this patch intends to fix. &#34; Revert the offending patch. If it can be shown that the originally reported alleged race condition does indeed exist, it can always be re-introduced with a complete fix.</p> <p><strong>Affected:</strong> 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 136 more</p> <p>In the Linux kernel, the following vulnerability has been resolved: Revert &#34;hwmon: (ibmpex) fix use-after-free in high/low store&#34; This reverts commit 6946c726c3f4c36f0f049e6f97e88c510b15f65d. Jean Delvare points out that the patch does not completely fix the reported problem, that it in fact introduces a (new) race condition, and that it may actually not be needed in the first place. Various AI reviews agree. Specific and relevant AI feedback: &#34; This reordering sets the driver data to NULL before removing the sensor attributes in the loop below. ibmpex_show_sensor() retrieves this driver data via dev_get_drvdata() but does not check if it is NULL before dereferencing it to access data-&gt;sensors[]. If a userspace process reads a sensor file (like temp1_input) while this delete function is running, could it race with the dev_set_drvdata(..., NULL) call here and crash in ibmpex_show_sensor()? Would it be safer to keep the original order where device_remove_file() is called before clearing the driver data? device_remove_file() should wait for any active sysfs callbacks to complete, which might already prevent the use-after-free this patch intends to fix. &#34; Revert the offending patch. If it can be shown that the originally reported alleged race condition does indeed exist, it can always be re-introduced with a complete fix.</p> https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-45914 https://cve.radiocsirt.org/vuln/wid-sec-w-2026-1700 <p>Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen Denial of Service Angriff durchzuführen oder andere nicht näher spezifizierte Auswirkungen zu erzielen.</p> <p>Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen Denial of Service Angriff durchzuführen oder andere nicht näher spezifizierte Auswirkungen zu erzielen.</p> https://cve.radiocsirt.org/vuln/wid-sec-w-2026-1700