https://vulnerability.circl.lu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Wed, 30 Sep 2026 01:29:21 +0000 https://vulnerability.circl.lu/vuln/cve-2024-46864 <p><strong>Affected:</strong> Linux</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>x86/hyperv: fix kexec crash due to VP assist page corruption</p> <p>commit 9636be85cc5b (&#34;x86/hyperv: Fix hyperv_pcpu_input_arg handling when CPUs go online/offline&#34;) introduces a new cpuhp state for hyperv initialization.</p> <p>cpuhp_setup_state() returns the state number if state is CPUHP_AP_ONLINE_DYN or CPUHP_BP_PREPARE_DYN and 0 for all other states. For the hyperv case, since a new cpuhp state was introduced it would return 0. However, in hv_machine_shutdown(), the cpuhp_remove_state() call is conditioned upon &#34;hyperv_init_cpuhp &gt; 0&#34;. This will never be true and so hv_cpu_die() won&#39;t be called on all CPUs. This means the VP assist page won&#39;t be reset. When the kexec kernel tries to setup the VP assist page again, the hypervisor corrupts the memory region of the old VP assist page causing a panic in case the kexec kernel is using that memory elsewhere. This was originally fixed in commit dfe94d4086e4 (&#34;x86/hyperv: Fix kexec panic/hang issues&#34;).</p> <p>Get rid of hyperv_init_cpuhp entirely since we are no longer using a dynamic cpuhp state and use CPUHP_AP_HYPERV_ONLINE directly with cpuhp_remove_state().</p> <p><strong>Affected:</strong> Linux</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>x86/hyperv: fix kexec crash due to VP assist page corruption</p> <p>commit 9636be85cc5b (&#34;x86/hyperv: Fix hyperv_pcpu_input_arg handling when CPUs go online/offline&#34;) introduces a new cpuhp state for hyperv initialization.</p> <p>cpuhp_setup_state() returns the state number if state is CPUHP_AP_ONLINE_DYN or CPUHP_BP_PREPARE_DYN and 0 for all other states. For the hyperv case, since a new cpuhp state was introduced it would return 0. However, in hv_machine_shutdown(), the cpuhp_remove_state() call is conditioned upon &#34;hyperv_init_cpuhp &gt; 0&#34;. This will never be true and so hv_cpu_die() won&#39;t be called on all CPUs. This means the VP assist page won&#39;t be reset. When the kexec kernel tries to setup the VP assist page again, the hypervisor corrupts the memory region of the old VP assist page causing a panic in case the kexec kernel is using that memory elsewhere. This was originally fixed in commit dfe94d4086e4 (&#34;x86/hyperv: Fix kexec panic/hang issues&#34;).</p> <p>Get rid of hyperv_init_cpuhp entirely since we are no longer using a dynamic cpuhp state and use CPUHP_AP_HYPERV_ONLINE directly with cpuhp_remove_state().</p> https://vulnerability.circl.lu/vuln/cve-2024-46864