CVE-2026-43261

What it actually does

This is an ARM64 Linux kernel CPU-side-channel issue affecting systems using TSV110 processors. The processor is vulnerable to Spectre-BHB, where branch history prediction state can be mistrained and then observed through timing differences to infer data across execution contexts. Exploitation requires local code execution, such as a low-privileged user process or code running in a container, and does not require user interaction. The Linux kernel fix adds TSV110 processor identification to the Spectre-BHB software mitigation path so the kernel applies the appropriate branch-history hardening on affected CPUs.

Why it matters to the business

Organizations running Linux on affected TSV110-based ARM64 systems may face risk of sensitive information leakage between processes, users, containers, or workloads sharing the same host. This is most important for multi-tenant, shared compute, container hosting, CI/CD runners, or environments that execute untrusted local code. The issue is not currently listed in CISA KEV, has very low EPSS, and has no reported exploit maturity in the provided data, so broad opportunistic exploitation is unlikely; however, side-channel flaws can be material where workload isolation is a business requirement.

How an attack unfolds

An attacker first obtains the ability to run code locally on an affected ARM64 Linux system using a TSV110 processor. From that foothold, the attacker runs code designed to manipulate the CPU branch history buffer and influence speculative execution behavior. The attacker then induces or waits for victim code to execute in a predictable pattern and uses timing measurements, cache effects, or similar microarchitectural observations to infer information that should not be directly accessible. Successful exploitation depends heavily on co-residency with sensitive workloads, precise timing, CPU behavior, and the absence of the kernel mitigation that enables Spectre-BHB hardening for TSV110.

How to fix it

Update to a Linux kernel build that includes the TSV110 Spectre-BHB mitigation patch. No exact fixed package versions were provided, so use the relevant Linux distribution, appliance vendor, or kernel maintainer advisory to identify the first kernel release containing the fix for TSV110 Spectre-BHB mitigation. After patching, reboot the system so the updated kernel and CPU mitigation logic are active. Where immediate patching is not possible, reduce exposure by avoiding co-location of untrusted and sensitive workloads on affected TSV110 hosts, limiting local shell access, restricting untrusted containers and build jobs, disabling or constraining high-resolution timing where practical, and applying workload isolation or host evacuation for high-sensitivity services.

How to confirm the fix worked

Confirm whether systems use affected ARM64 TSV110 processors and verify the running kernel includes the mitigation. On Linux systems, review CPU model information and kernel vulnerability status files such as /proc/cpuinfo and /sys/devices/system/cpu/vulnerabilities/spectre_bhb where available. A remediated system should report Spectre-BHB as mitigated rather than vulnerable, and the running kernel version should match a vendor release that contains the TSV110 mitigation. Also confirm the system has been rebooted after the kernel update, because installing a fixed kernel package alone does not activate the new kernel.

Typical attack path

1. Gain local code execution on an affected Linux ARM64 system using a TSV110 processor, such as through a user account, container, build job, or untrusted workload execution path.
2. Confirm the host CPU and kernel are affected and that Spectre-BHB mitigation is not active for TSV110.
3. Run a side-channel program that mistrains branch history behavior and collects high-resolution timing observations.
4. Coordinate measurements with victim activity or repeatedly sample shared execution contexts to increase signal quality.
5. Post-process timing data to infer sensitive information from another process, container, or execution context.

How to detect it

There is no reliable generic log event that proves Spectre-BHB exploitation occurred. Detection should focus on exposure assessment and suspicious local execution on affected hosts. Review kernel vulnerability status, CPU model data, kernel version, package history, reboot history, and workload placement records to determine whether sensitive and untrusted workloads shared an unmitigated TSV110 host. For possible exploitation, examine process execution telemetry, auditd, EDR, shell history, container runtime logs, CI job logs, and performance-monitoring activity for unusual locally executed timing or cache-measurement tools. Look for newly compiled binaries, repeated high-resolution timing loops, access to perf events, attempts to read CPU vulnerability files, and unusual co-residency of untrusted workloads with sensitive services. Named threat actors and ransomware use were not provided, and the vulnerability is not listed as KEV in the supplied data.

• /sys/devices/system/cpu/vulnerabilities/spectre_bhb
• spectre_bhb
• Spectre-BHB
• Branch History Buffer
• TSV110
• HISI_TSV110
• Vulnerable: Spectre-BHB
• Mitigation: Spectre-BHB
• /proc/cpuinfo

What your security team should do

• Inventory Linux ARM64 systems and identify hosts using TSV110 processors.
• Prioritize patching shared compute, container hosts, CI/CD runners, research systems, and any environment where untrusted users or workloads can run local code.
• Upgrade to a vendor-supported kernel release that includes the TSV110 Spectre-BHB mitigation and reboot affected systems.
• Temporarily avoid mixing sensitive workloads with untrusted local code on affected hosts until mitigation is confirmed.
• Monitor kernel and distribution advisories for the exact fixed package versions applicable to deployed platforms.
• Use vulnerability status files and configuration management data to verify that Spectre-BHB is reported as mitigated across the fleet.
• Because exploitation is side-channel based and difficult to prove after the fact, treat unexplained suspicious local-code execution on unmitigated shared hosts as higher risk.