In the Linux kernel, the following vulnerability has been resolved: KVM: x86: Ignore -EBUSY when checking nested events from vcpu_block() Ignore -EBUSY when checking nested events after exiting a blocking state while L2 is active, as exiting to userspace will generate a spurious userspace exit, usually with KVM_EXIT_UNKNOWN, and likely lead to the VM's demise. Continuing with the wakeup isn't perfect either, as *something* has gone sideways if a vCPU is awakened in L2 with an injected event (or worse, a nested run pending), but continuing on gives the VM a decent chance of surviving without any major side effects. As explained in the Fixes commits, it _should_ be impossible for a vCPU to be put into a blocking state with an already-injected event (exception, IRQ, or NMI). Unfortunately, userspace can stuff MP_STATE and/or injected events, and thus put the vCPU into what should be an impossible state. Don't bother trying to preserve the WARN, e.g. with an anti-syzkaller Kconfig, as WARNs can (hopefully) be added in paths where _KVM_ would be violating x86 architecture, e.g. by WARNing if KVM attempts to inject an exception or interrupt while the vCPU isn't running.

The Linux/Unix host has one or more packages installed that are impacted by a vulnerability without a vendor supplied patch available.

  - KVM: x86: Ignore -EBUSY when checking nested events from vcpu_block() Ignore -EBUSY when checking nested     events after exiting a blocking state while L2 is active, as exiting to userspace will generate a spurious     userspace exit, usually with KVM_EXIT_UNKNOWN, and likely lead to the VM's demise. Continuing with the     wakeup isn't perfect either, as *something* has gone sideways if a vCPU is awakened in L2 with an injected     event (or worse, a nested run pending), but continuing on gives the VM a decent chance of surviving     without any major side effects. As explained in the Fixes commits, it _should_ be impossible for a vCPU to     be put into a blocking state with an already-injected event (exception, IRQ, or NMI). Unfortunately,     userspace can stuff MP_STATE and/or injected events, and thus put the vCPU into what should be an     impossible state. Don't bother trying to preserve the WARN, e.g. with an anti-syzkaller Kconfig, as WARNs     can (hopefully) be added in paths where _KVM_ would be violating x86 architecture, e.g. by WARNing if KVM     attempts to inject an exception or interrupt while the vCPU isn't running. (CVE-2026-43265)

Note that Nessus relies on the presence of the package as reported by the vendor.

ID	Name	Product	Family	Severity
319659	SUSE SLES16 Security Update : kernel (SUSE-SU-2026:21845-1)	Nessus	SuSE Local Security Checks	high
318240	SUSE SLES16 Security Update : kernel (SUSE-SU-2026:21860-1)	Nessus	SuSE Local Security Checks	high
318102	openSUSE 16 Security Update : kernel (openSUSE-SU-2026:20826-1)	Nessus	SuSE Local Security Checks	high
313522	Amazon Linux 2023 : bpftool, kernel, kernel-devel (ALAS2023-2026-1681)	Nessus	Amazon Linux Local Security Checks	high
312927	Linux Distros Unpatched Vulnerability : CVE-2026-43265	Nessus	Misc.	medium
311340	Amazon Linux 2023 : bpftool6.18, kernel6.18, kernel6.18-devel (ALAS2023-2026-1596)	Nessus	Amazon Linux Local Security Checks	high
305231	Amazon Linux 2023 : bpftool6.12, kernel6.12, kernel6.12-devel (ALAS2023-2026-1543)	Nessus	Amazon Linux Local Security Checks	high

Detections

Analytics

CVE-2026-43265

medium

Tenable Plugins

high

high

high

high

medium

high

high