deardaniel/secdata-raw huggingface dataset:
CVE: CVE-2025-37936
Published: 2025-05-20
Description: In the Linux kernel, the following vulnerability has been resolved:

perf/x86/intel: KVM: Mask PEBS_ENABLE loaded for guest with vCPU's value.

When generating the MSR_IA32_PEBS_ENABLE value that will be loaded on
VM-Entry to a KVM guest, mask the value with the vCPU's desired PEBS_ENABLE
value.  Consulting only the host kernel's host vs. guest masks results in
running the guest with PEBS enabled even when the guest doesn't want to use
PEBS.  Because KVM uses perf events to proxy the guest virtual PMU, simply
looking at exclude_host can't differentiate between events created by host
userspace, and events created by KVM on behalf of the guest.

Running the guest with PEBS unexpectedly enabled typically manifests as
crashes due to a near-infinite stream of #PFs.  E.g. if the guest hasn't
written MSR_IA32_DS_AREA, the CPU will hit page faults on address '0' when
trying to record PEBS events.

The issue is most easily reproduced by running `perf kvm top` from before
commit 7b100989b4f6 ("perf evlist: Remove __evlist__add_default") (after
which, `perf kvm top` effectively stopped using PEBS).	The userspace side
of perf creates a guest-only PEBS event, which intel_guest_get_msrs()
misconstrues a guest-*owned* PEBS event.

Arguably, this is a userspace bug, as enabling PEBS on guest-only events
simply cannot work, and userspace can kill VMs in many other ways (there
is no danger to the host).  However, even if this is considered to be bad
userspace behavior, there's zero downside to perf/KVM restricting PEBS to
guest-owned events.

Note, commit 854250329c02 ("KVM: x86/pmu: Disable guest PEBS temporarily
in two rare situations") fixed the case where host userspace is profiling
KVM *and* userspace, but missed the case where userspace is profiling only
KVM.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/160153cf9e4aa875ad086cc094ce34aac8e13d63; https://git.kernel.org/stable/c/34b6fa11431aef71045ae5a00d90a7d630597eda; https://git.kernel.org/stable/c/44ee0afc9d1e7a7c1932698de01362ed80cfc4b5
CVE: CVE-2025-37937
Published: 2025-05-20
Description: In the Linux kernel, the following vulnerability has been resolved:

objtool, media: dib8000: Prevent divide-by-zero in dib8000_set_dds()

If dib8000_set_dds()'s call to dib8000_read32() returns zero, the result
is a divide-by-zero.  Prevent that from happening.

Fixes the following warning with an UBSAN kernel:

  drivers/media/dvb-frontends/dib8000.o: warning: objtool: dib8000_tune() falls through to next function dib8096p_cfg_DibRx()
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-369
References: https://git.kernel.org/stable/c/536f7f3595ef8187cfa9ea50d7d24fcf4e84e166; https://git.kernel.org/stable/c/6cfe46036b163e5a0f07c6b705b518148e1a8b2f; https://git.kernel.org/stable/c/75b42dfe87657ede3da3f279bd6b1b16d69af954
CVE: CVE-2025-37938
Published: 2025-05-20
Description: In the Linux kernel, the following vulnerability has been resolved:

tracing: Verify event formats that have "%*p.."

The trace event verifier checks the formats of trace events to make sure
that they do not point at memory that is not in the trace event itself or
in data that will never be freed. If an event references data that was
allocated when the event triggered and that same data is freed before the
event is read, then the kernel can crash by reading freed memory.

The verifier runs at boot up (or module load) and scans the print formats
of the events and checks their arguments to make sure that dereferenced
pointers are safe. If the format uses "%*p.." the verifier will ignore it,
and that could be dangerous. Cover this case as well.

Also add to the sample code a use case of "%*pbl".
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/[PII_REDACTED]7508d076073b020d3070990fd6a958; https://git.kernel.org/stable/c/04b80d45ecfaf780981d6582899e3ab205e4aa08; https://git.kernel.org/stable/c/4d11fac941d83509be4e6a21038281d6d96da50c
CVE: CVE-2025-37939
Published: 2025-05-20
Description: In the Linux kernel, the following vulnerability has been resolved:

libbpf: Fix accessing BTF.ext core_relo header

Update btf_ext_parse_info() to ensure the core_relo header is present
before reading its fields. This avoids a potential buffer read overflow
reported by the OSS Fuzz project.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-120
References: https://git.kernel.org/stable/c/0a7c2a84359612e54328aa52030eb202093da6e2; https://git.kernel.org/stable/c/3a67f60f0a8be10cea7a884a1a00e9feb6645657; https://git.kernel.org/stable/c/d529411ec44535308c5d59cbeff74be6fe14b479
CVE: CVE-2025-37940
Published: 2025-05-20
Description: In the Linux kernel, the following vulnerability has been resolved:

ftrace: Add cond_resched() to ftrace_graph_set_hash()

When the kernel contains a large number of functions that can be traced,
the loop in ftrace_graph_set_hash() may take a lot of time to execute.
This may trigger the softlockup watchdog.

Add cond_resched() within the loop to allow the kernel to remain
responsive even when processing a large number of functions.

This matches the cond_resched() that is used in other locations of the
code that iterates over all functions that can be traced.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-667
References: https://git.kernel.org/stable/c/1fce9574b9d515bcb8a75379a8053e18602424e3; https://git.kernel.org/stable/c/42ea22e754ba4f2b86f8760ca27f6f71da2d982c; https://git.kernel.org/stable/c/4429535acab750d963fdc3dfcc9e0eee42f4d599
CVE: CVE-2025-37941
Published: 2025-05-20
Description: In the Linux kernel, the following vulnerability has been resolved:

ASoC: codecs: wcd937x: fix a potential memory leak in wcd937x_soc_codec_probe()

When snd_soc_dapm_new_controls() or snd_soc_dapm_add_routes() fails,
wcd937x_soc_codec_probe() returns without releasing 'wcd937x->clsh_info',
which is allocated by wcd_clsh_ctrl_alloc. Add wcd_clsh_ctrl_free()
to prevent potential memory leak.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/3e330acf4efd63876d673c046cd073a1d4ed57a8; https://git.kernel.org/stable/c/aafb5325aca3e806b3ea[PII_REDACTED]263473d257; https://git.kernel.org/stable/c/acadb2e2b3c5b9977a843a3a94fece9bdcf6aea1
CVE: CVE-2025-37942
Published: 2025-05-20
Description: Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
CVE: CVE-2025-37943
Published: 2025-05-20
Description: In the Linux kernel, the following vulnerability has been resolved:

wifi: ath12k: Fix invalid data access in ath12k_dp_rx_h_undecap_nwifi

In certain cases, hardware might provide packets with a
length greater than the maximum native Wi-Fi header length.
This can lead to accessing and modifying fields in the header
within the ath12k_dp_rx_h_undecap_nwifi function for
DP_RX_DECAP_TYPE_NATIVE_WIFI decap type and
potentially resulting in invalid data access and memory corruption.

Add a sanity check before processing the SKB to prevent invalid
data access in the undecap native Wi-Fi function for the
DP_RX_DECAP_TYPE_NATIVE_WIFI decap type.

Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1
CVSS Score: 7.8 (HIGH)
CWE: CWE-787
References: https://git.kernel.org/stable/c/3abe15e756481c45f6acba3d476cb3ca4afc3b61; https://git.kernel.org/stable/c/50be1fb76556e80af9f5da80f28168b6c71bce58; https://git.kernel.org/stable/c/6ee653194ddb83674913fd2727b8ecfae0597ade
CVE: CVE-2025-37944
Published: 2025-05-20
Description: In the Linux kernel, the following vulnerability has been resolved:

wifi: ath12k: Fix invalid entry fetch in ath12k_dp_mon_srng_process

Currently, ath12k_dp_mon_srng_process uses ath12k_hal_srng_src_get_next_entry
to fetch the next entry from the destination ring. This is incorrect because
ath12k_hal_srng_src_get_next_entry is intended for source rings, not destination
rings. This leads to invalid entry fetches, causing potential data corruption or
crashes due to accessing incorrect memory locations. This happens because the
source ring and destination ring have different handling mechanisms and using
the wrong function results in incorrect pointer arithmetic and ring management.

To fix this issue, replace the call to ath12k_hal_srng_src_get_next_entry with
ath12k_hal_srng_dst_get_next_entry in ath12k_dp_mon_srng_process. This ensures
that the correct function is used for fetching entries from the destination
ring, preventing invalid memory accesses.

Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1
Tested-on: WCN7850 hw2.0 WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3
CVSS Score: 7.8 (HIGH)
CWE: CWE-787
References: https://git.kernel.org/stable/c/298f0aea5cb32b5038f991f5db201a0fcbb9a31b; https://git.kernel.org/stable/c/2c512f2eadabb1e[PII_REDACTED]4ffaf7d802a944e; https://git.kernel.org/stable/c/63fdc4509bcf483e79548de6bc08bf3c8e504bb3
CVE: CVE-2025-37946
Published: 2025-05-20
Description: In the Linux kernel, the following vulnerability has been resolved:

s390/pci: Fix duplicate pci_dev_put() in disable_slot() when PF has child VFs

With commit bcb5d6c76903 ("s390/pci: introduce lock to synchronize state
of zpci_dev's") the code to ignore power off of a PF that has child VFs
was changed from a direct return to a goto to the unlock and
pci_dev_put() section. The change however left the existing pci_dev_put()
untouched resulting in a doubple put. This can subsequently cause a use
after free if the struct pci_dev is released in an unexpected state.
Fix this by removing the extra pci_dev_put().
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/05a2538f2b48500cf4e8a0a0ce76623cc5bafcf1; https://git.kernel.org/stable/c/957529baef142d95e0d1b1bea786675bd47dbe53; https://git.kernel.org/stable/c/c488f8b53e156d6dcc0514ef0afa3a33376b8f9e
CVE: CVE-2025-37947
Published: 2025-05-20
Description: In the Linux kernel, the following vulnerability has been resolved:

ksmbd: prevent out-of-bounds stream writes by validating *pos

ksmbd_vfs_stream_write() did not validate whether the write offset
(*pos) was within the bounds of the existing stream data length (v_len).
If *pos was greater than or equal to v_len, this could lead to an
out-of-bounds memory write.

This patch adds a check to ensure *pos is less than v_len before
proceeding. If the condition fails, -EINVAL is returned.
CVSS Score: 7.8 (HIGH)
CWE: CWE-787, CWE-787
References: https://git.kernel.org/stable/c/04c8a38c60346bb5a7c49b276de7233f703ce9cb; https://git.kernel.org/stable/c/0ca6df4f40cf4c32487944aaf48319cb6c25accc; https://git.kernel.org/stable/c/7f61da79df86fd140c7768e668ad846bfa7ec8e1
CVE: CVE-2025-37948
Published: 2025-05-20
Description: In the Linux kernel, the following vulnerability has been resolved:

arm64: bpf: Add BHB mitigation to the epilogue for cBPF programs

A malicious BPF program may manipulate the branch history to influence
what the hardware speculates will happen next.

On exit from a BPF program, emit the BHB mititgation sequence.

This is only applied for 'classic' cBPF programs that are loaded by
seccomp.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/0dfefc2ea2f29ced2416017d7e5b1253a54c2735; https://git.kernel.org/stable/c/38c345fd54afd9d6ed8d3fcddf3f6ea23887bf78; https://git.kernel.org/stable/c/42a20cf51011788f04cf2adbcd7681f02bdb6c27
CVE: CVE-2025-37949
Published: 2025-05-20
Description: In the Linux kernel, the following vulnerability has been resolved:

xenbus: Use kref to track req lifetime

Marek reported seeing a NULL pointer fault in the xenbus_thread
callstack:
BUG: kernel NULL pointer dereference, address: [PII_REDACTED]
RIP: e030:__wake_up_common+0x4c/0x180
Call Trace:
 <TASK>
 __wake_up_common_lock+0x82/0xd0
 process_msg+0x18e/0x2f0
 xenbus_thread+0x165/0x1c0

process_msg+0x18e is req->cb(req).  req->cb is set to xs_wake_up(), a
thin wrapper around wake_up(), or xenbus_dev_queue_reply().  It seems
like it was xs_wake_up() in this case.

It seems like req may have woken up the xs_wait_for_reply(), which
kfree()ed the req.  When xenbus_thread resumes, it faults on the zero-ed
data.

Linux Device Drivers 2nd edition states:
"Normally, a wake_up call can cause an immediate reschedule to happen,
meaning that other processes might run before wake_up returns."
... which would match the behaviour observed.

Change to keeping two krefs on each request.  One for the caller, and
one for xenbus_thread.  Each will kref_put() when finished, and the last
will free it.

This use of kref matches the description in
Documentation/core-api/kref.rst
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/0e94a246bb6d9538010b6c02d2b1d4717a97b2e5; https://git.kernel.org/stable/c/1f0304dfd9d217c2f8b04a9ef4b3258a66eedd27; https://git.kernel.org/stable/c/2466b0f66795c3c426cacc8998499f38031dbb59
CVE: CVE-2025-37950
Published: 2025-05-20
Description: In the Linux kernel, the following vulnerability has been resolved:

ocfs2: fix panic in failed foilio allocation

commit 7e119cff9d0a ("ocfs2: convert w_pages to w_folios") and commit
9a5e08652dc4b ("ocfs2: use an array of folios instead of an array of
pages") save -ENOMEM in the folio array upon allocation failure and call
the folio array free code.

The folio array free code expects either valid folio pointers or NULL. 
Finding the -ENOMEM will result in a panic.  Fix by NULLing the error
folio entry.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/31d4cd4eb2f8d9b87ebfa6a5e443a59e3b3d7b8c; https://git.kernel.org/stable/c/80d18f060d5bdf2c5eb3d1d00dcb744d6a879222
CVE: CVE-2025-37951
Published: 2025-05-20
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/v3d: Add job to pending list if the reset was skipped

When a CL/CSD job times out, we check if the GPU has made any progress
since the last timeout. If so, instead of resetting the hardware, we skip
the reset and let the timer get rearmed. This gives long-running jobs a
chance to complete.

However, when `timedout_job()` is called, the job in question is removed
from the pending list, which means it won't be automatically freed through
`free_job()`. Consequently, when we skip the reset and keep the job
running, the job won't be freed when it finally completes.

This situation leads to a memory leak, as exposed in [1] and [2].

Similarly to commit 704d3d60fec4 ("drm/etnaviv: don't block scheduler when
GPU is still active"), this patch ensures the job is put back on the
pending list when extending the timeout.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/12125f7d9c15e6d8ac91d10373b2db2f17dcf767; https://git.kernel.org/stable/c/35e4079bf1a2570abffce6ababa631afcf8ea0e5; https://git.kernel.org/stable/c/422a8b10ba42097a704d6909ada2956f880246f2
CVE: CVE-2025-37952
Published: 2025-05-20
Description: In the Linux kernel, the following vulnerability has been resolved:

ksmbd: Fix UAF in __close_file_table_ids

A use-after-free is possible if one thread destroys the file
via __ksmbd_close_fd while another thread holds a reference to
it. The existing checks on fp->refcount are not sufficient to
prevent this.

The fix takes ft->lock around the section which removes the
file from the file table. This prevents two threads acquiring the
same file pointer via __close_file_table_ids, as well as the other
functions which retrieve a file from the IDR and which already use
this same lock.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/16727e442568a46d9cca69fe2595896de86e120d; https://git.kernel.org/stable/c/36991c1ccde2d5a521577c448ffe07fcccfe104d; https://git.kernel.org/stable/c/9e9841e232b51171ddf3bc4ee517d5d28dc8cad6
CVE: CVE-2025-37953
Published: 2025-05-20
Description: In the Linux kernel, the following vulnerability has been resolved:

sch_htb: make htb_deactivate() idempotent

Alan reported a NULL pointer dereference in htb_next_rb_node()
after we made htb_qlen_notify() idempotent.

It turns out in the following case it introduced some regression:

htb_dequeue_tree():
  |-> fq_codel_dequeue()
    |-> qdisc_tree_reduce_backlog()
      |-> htb_qlen_notify()
        |-> htb_deactivate()
  |-> htb_next_rb_node()
  |-> htb_deactivate()

For htb_next_rb_node(), after calling the 1st htb_deactivate(), the
clprio[prio]->ptr could be already set to  NULL, which means
htb_next_rb_node() is vulnerable here.

For htb_deactivate(), although we checked qlen before calling it, in
case of qlen==0 after qdisc_tree_reduce_backlog(), we may call it again
which triggers the warning inside.

To fix the issues here, we need to:

1) Make htb_deactivate() idempotent, that is, simply return if we
   already call it before.
2) Make htb_next_rb_node() safe against ptr==NULL.

Many thanks to Alan for testing and for the reproducer.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/31ff70ad39485698cf779f2078132d80b57f6c07; https://git.kernel.org/stable/c/[PII_REDACTED]135e82b262640252d90f6efb05be71; https://git.kernel.org/stable/c/98cd7ed92753090a714f0802d[PII_REDACTED]fe61d
CVE: CVE-2025-37954
Published: 2025-05-20
Description: In the Linux kernel, the following vulnerability has been resolved:

smb: client: Avoid race in open_cached_dir with lease breaks

A pre-existing valid cfid returned from find_or_create_cached_dir might
race with a lease break, meaning open_cached_dir doesn't consider it
valid, and thinks it's newly-constructed. This leaks a dentry reference
if the allocation occurs before the queued lease break work runs.

Avoid the race by extending holding the cfid_list_lock across
find_or_create_cached_dir and when the result is checked.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/2407265dc32bc8cc45b62a612c2a214ba9038e8b; https://git.kernel.org/stable/c/2ed98e89ebc2e1bc73534dc3c18cb7843a889ff9; https://git.kernel.org/stable/c/3ca02e63edccb78ef3659bebc68579c7224a6ca2
CVE: CVE-2025-37955
Published: 2025-05-20
Description: In the Linux kernel, the following vulnerability has been resolved:

virtio-net: free xsk_buffs on error in virtnet_xsk_pool_enable()

The selftests added to our CI by Bui Quang Minh recently reveals
that there is a mem leak on the error path of virtnet_xsk_pool_enable():

unreferenced object 0xffff88800a68a000 (size 2048):
  comm "xdp_helper", pid 318, jiffies[PII_REDACTED]
  hex dump (first 32 bytes):
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
  backtrace (crc 0):
    __kvmalloc_node_noprof+0x402/0x570
    virtnet_xsk_pool_enable+0x293/0x6a0 (drivers/net/virtio_net.c:5882)
    xp_assign_dev+0x369/0x670 (net/xdp/xsk_buff_pool.c:226)
    xsk_bind+0x6a5/0x1ae0
    __sys_bind+0x15e/0x230
    __x64_sys_bind+0x72/0xb0
    do_syscall_64+0xc1/0x1d0
    entry_SYSCALL_64_after_hwframe+0x77/0x7f
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/4397684a292a71fbc1e815c3e283f7490ddce5ae; https://git.kernel.org/stable/c/94a6f6c204abb2b2dcd2ce287536cc924469cfb5; https://git.kernel.org/stable/c/ba6917810bb4a5a32661fa[PII_REDACTED]52b3f0d9
CVE: CVE-2025-37956
Published: 2025-05-20
Description: In the Linux kernel, the following vulnerability has been resolved:

ksmbd: prevent rename with empty string

Client can send empty newname string to ksmbd server.
It will cause a kernel oops from d_alloc.
This patch return the error when attempting to rename
a file or directory with an empty new name string.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/53e3e5babc0963a92d856a5ec0ce92c59f54bc12; https://git.kernel.org/stable/c/6ee551672c8cf36108b0cfba92ec0c7c28ac3439; https://git.kernel.org/stable/c/c57301e332cc413fe0a7294a90725f4e21e9549d
CVE: CVE-2025-37957
Published: 2025-05-20
Description: In the Linux kernel, the following vulnerability has been resolved:

KVM: SVM: Forcibly leave SMM mode on SHUTDOWN interception

Previously, commit ed129ec9057f ("KVM: x86: forcibly leave nested mode
on vCPU reset") addressed an issue where a triple fault occurring in
nested mode could lead to use-after-free scenarios. However, the commit
did not handle the analogous situation for System Management Mode (SMM).

This omission results in triggering a WARN when KVM forces a vCPU INIT
after SHUTDOWN interception while the vCPU is in SMM. This situation was
reprodused using Syzkaller by:

  1) Creating a KVM VM and vCPU
  2) Sending a KVM_SMI ioctl to explicitly enter SMM
  3) Executing invalid instructions causing consecutive exceptions and
     eventually a triple fault

The issue manifests as follows:

  WARNING: CPU: 0 PID: 25506 at arch/x86/kvm/x86.c:12112
  kvm_vcpu_reset+0x1d2/0x1530 arch/x86/kvm/x86.c:12112
  Modules linked in:
  CPU: 0 PID: 25506 Comm: syz-executor.0 Not tainted
  6.1.130-syzkaller-00157-g164fe5dde9b6 #0
  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
  BIOS 1.12.0-1 04/01/2014
  RIP: 0010:kvm_vcpu_reset+0x1d2/0x1530 arch/x86/kvm/x86.c:12112
  Call Trace:
   <TASK>
   shutdown_interception+0x66/0xb0 arch/x86/kvm/svm/svm.c:2136
   svm_invoke_exit_handler+0x110/0x530 arch/x86/kvm/svm/svm.c:3395
   svm_handle_exit+0x424/0x920 arch/x86/kvm/svm/svm.c:3457
   vcpu_enter_guest arch/x86/kvm/x86.c:10959 [inline]
   vcpu_run+0x2c43/0x5a90 arch/x86/kvm/x86.c:11062
   kvm_arch_vcpu_ioctl_run+0x50f/0x1cf0 arch/x86/kvm/x86.c:11283
   kvm_vcpu_ioctl+0x570/0xf00 arch/x86/kvm/../../../virt/kvm/kvm_main.c:4122
   vfs_ioctl fs/ioctl.c:51 [inline]
   __do_sys_ioctl fs/ioctl.c:870 [inline]
   __se_sys_ioctl fs/ioctl.c:856 [inline]
   __x64_sys_ioctl+0x19a/0x210 fs/ioctl.c:856
   do_syscall_x64 arch/x86/entry/common.c:51 [inline]
   do_syscall_64+0x35/0x80 arch/x86/entry/common.c:81
   entry_SYSCALL_64_after_hwframe+0x6e/0xd8

Architecturally, INIT is blocked when the CPU is in SMM, hence KVM's WARN()
in kvm_vcpu_reset() to guard against KVM bugs, e.g. to detect improper
emulation of INIT.  SHUTDOWN on SVM is a weird edge case where KVM needs to
do _something_ sane with the VMCB, since it's technically undefined, and
INIT is the least awful choice given KVM's ABI.

So, double down on stuffing INIT on SHUTDOWN, and force the vCPU out of
SMM to avoid any weirdness (and the WARN).

Found by Linux Verification Center (linuxtesting.org) with Syzkaller.

[sean: massage changelog, make it clear this isn't architectural behavior]
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/a2620f8932fa9fdabc3d78ed6efb004ca409019f; https://git.kernel.org/stable/c/d362b21fefcef7eda8f1cd78a5925735d2b3287c; https://git.kernel.org/stable/c/e9b28bc65fd3a56755ba[PII_REDACTED]08292b4ab1