https://db.gcve.eu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Tue, 27 Oct 2026 16:38:54 +0000 https://db.gcve.eu/vuln/fkie_cve-2026-99065 <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>cgroup/cpuset: Handle cpu hotplug race in guarantee_active_cpus()</p> <p>With commit 2125c0034c5d (&#34;cgroup/cpuset: Make cpuset hotplug processing synchronous&#34;), the cpuset hotplug operation becomes synchronous. That commit also removes the code that handles race between cpuset_hotplug_work and cpu hotplug notifier with the assumption that race is now gone. Later commit 7a0aabd9ce69 (&#34;cgroup/cpuset: Always use cpu_active_mask&#34;) updates the cpuset code to always use cpu_active_mask instead of cpu_online_mask in some places including guarantee_online_cpus() which is renamed to guarantee_active_cpus() in that commit.</p> <p>In the case of CPU offline operation, cpu_active_mask is updated first in sched_cpu_deactivate() to remove the offline CPU before cpuset_handle_hotplug() is called to update the effective_cpus of the affected cpusets. The cpu_online_mask is updated after that near the end of the offline operation to remove the offline CPU. As a result, the race comes back and the top cpuset may not have any active CPU leading to NULL pointer dereference during the race window when guarantee_active_cpus() is called after cpu_active_mask is updated to remove the CPU to be torn down but before cpuset_handle_hotplug() is able to properly update the effective_cpus of the top cpuset.</p> <p>Fix this by adding back the NULL cs check to avoid this problem.</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>cgroup/cpuset: Handle cpu hotplug race in guarantee_active_cpus()</p> <p>With commit 2125c0034c5d (&#34;cgroup/cpuset: Make cpuset hotplug processing synchronous&#34;), the cpuset hotplug operation becomes synchronous. That commit also removes the code that handles race between cpuset_hotplug_work and cpu hotplug notifier with the assumption that race is now gone. Later commit 7a0aabd9ce69 (&#34;cgroup/cpuset: Always use cpu_active_mask&#34;) updates the cpuset code to always use cpu_active_mask instead of cpu_online_mask in some places including guarantee_online_cpus() which is renamed to guarantee_active_cpus() in that commit.</p> <p>In the case of CPU offline operation, cpu_active_mask is updated first in sched_cpu_deactivate() to remove the offline CPU before cpuset_handle_hotplug() is called to update the effective_cpus of the affected cpusets. The cpu_online_mask is updated after that near the end of the offline operation to remove the offline CPU. As a result, the race comes back and the top cpuset may not have any active CPU leading to NULL pointer dereference during the race window when guarantee_active_cpus() is called after cpu_active_mask is updated to remove the CPU to be torn down but before cpuset_handle_hotplug() is able to properly update the effective_cpus of the top cpuset.</p> <p>Fix this by adding back the NULL cs check to avoid this problem.</p> https://db.gcve.eu/vuln/fkie_cve-2026-99065 https://db.gcve.eu/vuln/ghsa-px5v-f8qg-w5f8 <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>cgroup/cpuset: Handle cpu hotplug race in guarantee_active_cpus()</p> <p>With commit 2125c0034c5d (&#34;cgroup/cpuset: Make cpuset hotplug processing synchronous&#34;), the cpuset hotplug operation becomes synchronous. That commit also removes the code that handles race between cpuset_hotplug_work and cpu hotplug notifier with the assumption that race is now gone. Later commit 7a0aabd9ce69 (&#34;cgroup/cpuset: Always use cpu_active_mask&#34;) updates the cpuset code to always use cpu_active_mask instead of cpu_online_mask in some places including guarantee_online_cpus() which is renamed to guarantee_active_cpus() in that commit.</p> <p>In the case of CPU offline operation, cpu_active_mask is updated first in sched_cpu_deactivate() to remove the offline CPU before cpuset_handle_hotplug() is called to update the effective_cpus of the affected cpusets. The cpu_online_mask is updated after that near the end of the offline operation to remove the offline CPU. As a result, the race comes back and the top cpuset may not have any active CPU leading to NULL pointer dereference during the race window when guarantee_active_cpus() is called after cpu_active_mask is updated to remove the CPU to be torn down but before cpuset_handle_hotplug() is able to properly update the effective_cpus of the top cpuset.</p> <p>Fix this by adding back the NULL cs check to avoid this problem.</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>cgroup/cpuset: Handle cpu hotplug race in guarantee_active_cpus()</p> <p>With commit 2125c0034c5d (&#34;cgroup/cpuset: Make cpuset hotplug processing synchronous&#34;), the cpuset hotplug operation becomes synchronous. That commit also removes the code that handles race between cpuset_hotplug_work and cpu hotplug notifier with the assumption that race is now gone. Later commit 7a0aabd9ce69 (&#34;cgroup/cpuset: Always use cpu_active_mask&#34;) updates the cpuset code to always use cpu_active_mask instead of cpu_online_mask in some places including guarantee_online_cpus() which is renamed to guarantee_active_cpus() in that commit.</p> <p>In the case of CPU offline operation, cpu_active_mask is updated first in sched_cpu_deactivate() to remove the offline CPU before cpuset_handle_hotplug() is called to update the effective_cpus of the affected cpusets. The cpu_online_mask is updated after that near the end of the offline operation to remove the offline CPU. As a result, the race comes back and the top cpuset may not have any active CPU leading to NULL pointer dereference during the race window when guarantee_active_cpus() is called after cpu_active_mask is updated to remove the CPU to be torn down but before cpuset_handle_hotplug() is able to properly update the effective_cpus of the top cpuset.</p> <p>Fix this by adding back the NULL cs check to avoid this problem.</p> https://db.gcve.eu/vuln/ghsa-px5v-f8qg-w5f8 https://db.gcve.eu/vuln/msrc_cve-2026-99065 msrc_CVE-2026-99065 https://db.gcve.eu/vuln/msrc_cve-2026-99065 https://db.gcve.eu/vuln/ubuntu-cve-2026-99065 <p><strong>Affected:</strong> 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 257 more</p> <p>In the Linux kernel, the following vulnerability has been resolved: cgroup/cpuset: Handle cpu hotplug race in guarantee_active_cpus() With commit 2125c0034c5d (&#34;cgroup/cpuset: Make cpuset hotplug processing synchronous&#34;), the cpuset hotplug operation becomes synchronous. That commit also removes the code that handles race between cpuset_hotplug_work and cpu hotplug notifier with the assumption that race is now gone. Later commit 7a0aabd9ce69 (&#34;cgroup/cpuset: Always use cpu_active_mask&#34;) updates the cpuset code to always use cpu_active_mask instead of cpu_online_mask in some places including guarantee_online_cpus() which is renamed to guarantee_active_cpus() in that commit. In the case of CPU offline operation, cpu_active_mask is updated first in sched_cpu_deactivate() to remove the offline CPU before cpuset_handle_hotplug() is called to update the effective_cpus of the affected cpusets. The cpu_online_mask is updated after that near the end of the offline operation to remove the offline CPU. As a result, the race comes back and the top cpuset may not have any active CPU leading to NULL pointer dereference during the race window when guarantee_active_cpus() is called after cpu_active_mask is updated to remove the CPU to be torn down but before cpuset_handle_hotplug() is able to properly update the effective_cpus of the top cpuset. Fix this by adding back the NULL cs check to avoid this problem.</p> <p><strong>Affected:</strong> 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 257 more</p> <p>In the Linux kernel, the following vulnerability has been resolved: cgroup/cpuset: Handle cpu hotplug race in guarantee_active_cpus() With commit 2125c0034c5d (&#34;cgroup/cpuset: Make cpuset hotplug processing synchronous&#34;), the cpuset hotplug operation becomes synchronous. That commit also removes the code that handles race between cpuset_hotplug_work and cpu hotplug notifier with the assumption that race is now gone. Later commit 7a0aabd9ce69 (&#34;cgroup/cpuset: Always use cpu_active_mask&#34;) updates the cpuset code to always use cpu_active_mask instead of cpu_online_mask in some places including guarantee_online_cpus() which is renamed to guarantee_active_cpus() in that commit. In the case of CPU offline operation, cpu_active_mask is updated first in sched_cpu_deactivate() to remove the offline CPU before cpuset_handle_hotplug() is called to update the effective_cpus of the affected cpusets. The cpu_online_mask is updated after that near the end of the offline operation to remove the offline CPU. As a result, the race comes back and the top cpuset may not have any active CPU leading to NULL pointer dereference during the race window when guarantee_active_cpus() is called after cpu_active_mask is updated to remove the CPU to be torn down but before cpuset_handle_hotplug() is able to properly update the effective_cpus of the top cpuset. Fix this by adding back the NULL cs check to avoid this problem.</p> https://db.gcve.eu/vuln/ubuntu-cve-2026-99065