CVE-2026-74702 in Linux
Summary
by MITRE • 08/22/2026
In the Linux kernel, the following vulnerability has been resolved:
vhost-scsi: reject feature changes after endpoint
vhost_scsi_setup_vq_cmds() runs from VHOST_SCSI_SET_ENDPOINT and allocates each command's protection scatterlist array (prot_sgl) according to the acknowledged VIRTIO_SCSI_F_T10_PI bit. The command pools are not rebuilt when VHOST_SET_FEATURES changes that bit later.
Although virtio feature bits must not change after feature negotiation, vhost_scsi_set_features() currently accepts such a request after the endpoint is active and updates acked_features. Enabling T10-PI after endpoint setup therefore leaves prot_sgl NULL while the I/O path follows the new feature bit.
For a 129-page protection payload, vhost_scsi_mapal() passes the missing first chunk to sg_alloc_table_chained():
sg_alloc_table_chained(table, 129, first_chunk=NULL, nents_first_chunk=inline_sg_cnt)
sg_pool_index() then hits:
BUG_ON(nents > SG_CHUNK_SIZE); /* 129 > 128 */
The kernel reported the following call trace and register state:
Call Trace: <TASK> ? __sg_alloc_table+0x1d8/0x250 ? __pfx_vhost_run_work_list+0x10/0x10 [vhost]
sg_alloc_table_chained+0x59/0xf0 ? __pfx_sg_pool_alloc+0x10/0x10 ? vhost_scsi_calc_sgls.constprop.0+0x43/0x60 [vhost_scsi]
vhost_scsi_handle_vq+0xf02/0x1700 [vhost_scsi]
? __pfx_vhost_scsi_handle_vq+0x10/0x10 [vhost_scsi]
vhost_scsi_handle_kick+0x37/0x50 [vhost_scsi]
vhost_run_work_list+0x8e/0xd0 [vhost]
vhost_task_fn+0xe1/0x210 ret_from_fork+0x348/0x540 </TASK>
RIP: 0010:0x4 CR2 = 0x4 RSP: 0018:ffffc90000dbf940 EFLAGS: 00010202 RAX: ffffffff82396810 RBX: ffff88811dc28b80 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000820 RDI: 0000000000000081
VHOST_F_LOG_ALL is a vhost-specific runtime feature and remains the only exception.
Reject changes to any feature other than VHOST_F_LOG_ALL while the endpoint is active. This preserves the existing runtime log toggle while preventing feature-dependent command resources and data-path state from becoming inconsistent. Userspace must clear the endpoint before changing any other negotiated feature and set the endpoint up again afterward.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 08/22/2026
The vulnerability in question resides within the vhost-scsi subsystem of the Linux kernel, specifically affecting the handling of Virtio SCSI features after an endpoint has been established. The core issue stems from a failure to synchronize command pool resources with changes in negotiated feature bits. During normal operation, when VHOST_SCSI_SET_ENDPOINT is invoked, the function vhost_scsi_setup_vq_cmds() allocates protection scatterlist arrays based on whether the VIRTIO_SCSI_F_T10_PI bit has been acknowledged. This allocation determines how data integrity metadata for T10 Protection Information is managed during I/O operations. However, subsequent calls to vhost_scsi_set_features(), which handle runtime feature modifications, were incorrectly permitted to alter these bits even after the endpoint was active. While Virtio specifications generally prohibit changing feature bits post-negotiation, the kernel code failed to enforce this restriction strictly for all features except VHOST_F_LOG_ALL, leading to a state inconsistency where the logical feature set no longer matched the allocated resources.
This discrepancy creates a critical path for denial of service attacks through local privilege escalation or system instability. When an attacker or misconfigured userspace application enables T10-PI support after the endpoint is already active, the kernel updates its internal acked_features flag to reflect this change but fails to reallocate the necessary command pool structures. Consequently, when I/O requests arrive that require protection information handling, the code attempts to process them using a NULL pointer for the first chunk of the scatterlist array. This null reference triggers a crash within sg_alloc_table_chained(), which expects valid memory addresses to manage the chained scatter-gather list. The specific failure occurs because the function attempts to allocate table entries based on an incorrect count, leading to a BUG_ON condition when the number of entities exceeds SG_CHUNK_SIZE due to the missing initial chunk allocation logic.
The operational impact is severe, resulting in an immediate kernel panic or oops as evidenced by the provided call trace and register state. The crash originates deep within the vhost work processing pipeline, specifically during the handling of virtual queue kicks that trigger I/O processing. The system reports a null pointer dereference at address 0x4, indicating that the code attempted to access memory through an invalid base address derived from the uninitialized or freed scatterlist structures. This vulnerability allows any user with access to the vhost-scsi device node to destabilize the host kernel by toggling features in a specific sequence. It effectively bypasses standard safety checks because the feature negotiation phase is considered complete, leaving the subsystem vulnerable to state corruption that manifests as a crash rather than silent data corruption or security breach.
From a classification perspective, this vulnerability aligns with CWE-672, which pertains to the use of operations after inappropriate states. The system enters an inconsistent operational state where feature flags indicate capabilities that are not supported by the currently allocated memory structures. In terms of attack vectors and techniques, this scenario relates to MITRE ATT&CK technique T1059, Command and Scripting Interpreter, if exploited via automated scripts manipulating vhost controls, or more broadly as a resource exhaustion vector under Denial of Service impacts. The flaw highlights the importance of strict state machine enforcement in virtualization backends, ensuring that runtime configurations cannot alter fundamental data path assumptions once active connections are established.
To mitigate this vulnerability, kernel developers have implemented a check within vhost_scsi_set_features() to reject any feature changes other than VHOST_F_LOG_ALL while the endpoint remains active. This restriction ensures that only logging-related features can be toggled dynamically without disrupting the underlying I/O infrastructure. For administrators and userspace applications relying on T10-PI or similar integrity features, it is now mandatory to clear the vhost-scsi endpoint before modifying any other negotiated feature bits. Once the desired configuration changes are applied in a quiescent state, the endpoint must be re-established to trigger proper resource allocation for the new feature set. This procedural requirement prevents the race condition between feature negotiation and command pool initialization, thereby maintaining system stability and preventing kernel crashes triggered by improper feature toggling sequences.