CVE-2026-98967 in Linux
Summary
by MITRE • 10/23/2026
In the Linux kernel, the following vulnerability has been resolved:
cxgb4/ch_ktls: disable softirqs around tid_list erases
chcr_ktls_cpl_act_open_rpl() inserts into tid_list from the receive path using xa_insert_bh(). The array is shared by the adapter's connections and initialized with XA_FLAGS_LOCK_BH. However, chcr_ktls_dev_del() and the chcr_ktls_dev_add() error path use xa_erase(), which takes the XArray lock without disabling softirqs.
When cleanup runs with softirqs enabled, a receive softirq for another connection on the same CPU can interrupt the erase and spin on the lock held by the interrupted task. Use xa_erase_bh() at both sites to match the insertion path.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/24/2026
The Linux kernel vulnerability identified in the cxgb4/ch_ktls subsystem involves a concurrency flaw related to the synchronization of data structures during connection management operations. Specifically, the issue arises from an inconsistency in how locks are managed when accessing the tid_list array, which is shared across adapter connections and initialized with XA_FLAGS_LOCK_BH flags to indicate that bottom-half context protection is required for safe access. The function chcr_ktls_cpl_act_open_rpl correctly inserts elements into this list using xa_insert_bh(), a variant of the xarray insertion operation designed to be called from softirq contexts by automatically disabling local interrupts or holding appropriate locks. However, during device deletion in chcr_ktls_dev_del() and within the error handling path of chcr_ktls_dev_add(), the code incorrectly uses xa_erase(). This standard erase function does not disable softirqs, creating a race condition where the lock acquisition mechanism is mismatched with the execution context.
The operational impact of this flaw manifests when cleanup routines execute while soft interrupts are enabled on the same CPU core handling network receive processing. If a receive soft interrupt for another connection triggers during the execution of xa_erase(), it may attempt to access or modify the same tid_list structure. Since the initial task holds the XArray lock without having disabled bottom-half processing, the incoming softirq will spin indefinitely waiting for the lock that is held by an interrupted context that cannot be preempted in a way that allows progress. This scenario leads to a deadlock condition where system responsiveness degrades significantly or hangs entirely, effectively causing a denial of service for network operations handled by this specific hardware driver on affected systems.
This vulnerability aligns with CWE-362, which describes concurrent execution using shared resources with improper synchronization mechanisms. The root cause is the failure to maintain consistent locking semantics across all code paths that modify the shared data structure. By mixing functions designed for process context or general interrupt contexts with those required for bottom-half safe operations, the kernel exposes itself to race conditions inherent in multiprocessor and high-throughput network environments. Proper synchronization requires ensuring that any access to a resource marked as requiring BH-safe locking is performed exclusively through APIs that enforce this constraint, thereby preventing interleaving of critical sections by softirq handlers.
To mitigate this vulnerability, developers must replace the standard xa_erase calls with xa_erase_bh in both chcr_ktls_dev_del() and the error path of chcr_ktls_dev_add(). This change ensures that all modifications to the tid_list are performed under conditions consistent with its initialization flags, effectively disabling local softirqs during the critical section. This patch restores atomicity to the list operations and prevents the deadlock scenario described. From a broader security perspective, this issue highlights the importance of adhering strictly to kernel API contracts regarding interrupt context safety. Security auditors should review similar patterns in network drivers where shared data structures are accessed from both process and softirq contexts to identify potential synchronization gaps that could lead to system instability or denial of service conditions.