CVE-2026-23229: crypto: virtio - Add spinlock protection with virtqueue notification
In the Linux kernel, the following vulnerability has been resolved:
crypto: virtio - Add spinlock protection with virtqueue notification
When VM boots with one virtio-crypto PCI device and builtin backend,
run openssl benchmark command with multiple processes, such as
openssl speed -evp aes-128-cbc -engine afalg -seconds 10 -multi 32
openssl processes will hangup and there is error reported like this:
virtio_crypto virtio0: dataq.0:id 3 is not a head!
It seems that the data virtqueue need protection when it is handled
for virtio done notification. If the spinlock protection is added
in virtcrypto_done_task(), openssl benchmark with multiple processes
works well.
Security readout for executives and security teams
Plain-English summary
This Linux kernel flaw affects systems using virtio-crypto, mainly virtualized environments. Under concurrent cryptographic workload, the crypto queue can be handled without proper locking, causing processes to hang. The public evidence points to reliability and availability impact, not confirmed compromise or data theft.
Executive priority
Treat this as a targeted availability risk for virtualized Linux systems using virtio-crypto. Prioritize cloud, appliance, and virtualization estates where crypto acceleration is enabled, but do not treat it as confirmed active exploitation from the supplied evidence.
Technical view
The issue is in the Linux virtio crypto driver. During virtqueue done notification handling, the data virtqueue lacked spinlock protection. Concurrent AF_ALG/OpenSSL activity can trigger queue inconsistency and hung workloads. Kernel stable commits add locking around virtcrypto_done_task handling.
Likely exposure
Exposure is most likely on Linux VMs or appliances with virtio-crypto PCI devices enabled and workloads using kernel-backed crypto through that path. Systems without virtio-crypto use are unlikely to be exposed based on the source bundle.
Exploitation context
No CISA KEV listing is provided, and the bundle does not cite active exploitation. The described trigger is a local or workload-driven concurrency condition causing hangs during multi-process crypto benchmarking, not a publicly confirmed remote attack path.
Researcher notes
The strongest evidence is the kernel fix description: concurrent crypto operations can corrupt virtqueue handling without spinlock protection. Affected version metadata in the bundle is uneven, so validation should rely on distro or vendor kernel backport status rather than raw upstream version strings alone.
Mitigation direction
Identify systems using Linux virtio-crypto devices or kernel-backed crypto workloads.
Review vendor kernel advisories and apply stable kernel updates containing the referenced fixes.
For appliances, follow the vendor advisory before changing kernel or virtualization configuration.
If patching is delayed, assess whether virtio-crypto can be disabled safely.
Validation and detection
Check whether affected hosts expose or load the virtio crypto driver.
Inventory kernel versions against vendor advisories and referenced Linux stable commits.
Review logs for virtio_crypto queue errors or unexplained crypto workload hangs.
Retest representative crypto workloads after applying vendor-approved updates.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2026-23229 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
0CVSS vectors
3Timeline events
1ADP providers
10Source links
Vulnerability timeline
Timeline events are normalized from CVE metadata, CNA source timelines, ADP timelines, and KEV metadata when present.
CVE reservedCVE Program
The CVE ID was reserved by the assigning CNA.
CVE publishedCVE Program
The CVE record was published.
Feb 18, 2026, 14:53 UTC (UTC+00:00)
CVE updatedCVE Program
The CVE record metadata indicates this as the latest update time.