CVE-2026-43232

What it actually does

This vulnerability is a use-after-free race condition in the Linux kernel FarSync T-series WAN card driver. During device removal, the driver frees the fst_card_info structure in fst_remove_one() while transmit or interrupt tasklets, such as fst_tx_task or fst_int_task, may still be queued or executing. If those tasklets later run and dereference the freed card structure in fst_process_tx_work_q(), fst_process_int_work_q(), or do_bottom_half_tx(), kernel memory that has already been released can be accessed. Depending on timing, allocator state, kernel hardening, and attacker control over subsequent allocations, this can cause a kernel crash, memory corruption, information disclosure, or potentially privilege escalation/code execution in kernel context.

Why it matters to the business

Systems using the affected Linux kernel driver for FarSync T-series WAN cards may be exposed to crashes or kernel-level compromise during device detach, hotplug, driver unload, or related hardware lifecycle events. The most likely operational impact is denial of service through a kernel panic or unstable networking on systems using this specialized WAN hardware; in a worst case, successful exploitation could allow an attacker to gain full control of the affected host. Although the EPSS score is low and there is no known CISA KEV listing or public exploit maturity reported, the high CVSS score reflects the severity of kernel memory corruption if the vulnerable code path is reachable.

How an attack unfolds

An attacker needs a way to trigger activity in the FarSync WAN driver while the device is being removed, detached, disabled, hot-unplugged, or the driver is being unloaded. The vulnerable sequence occurs when transmit or interrupt work is scheduled through tasklets and, before that deferred work finishes, the driver cleanup path unregisters the HDLC device and frees the fst_card_info object. If the pending tasklet then runs, it dereferences the stale pointer to the freed object. An attacker who can repeatedly cause transmit activity and device teardown may be able to win the race and cause a kernel use-after-free. In the simplest case, this produces a crash or KASAN report; with favorable heap grooming and reliable control over replacement allocations, the same primitive could potentially be developed into kernel memory corruption leading to privilege escalation or arbitrary code execution. Practical exploitation is constrained by the need for the affected driver and relevant hardware or emulated/hotplug-capable device paths, and no mature public exploit is currently indicated.

How to fix it

Upgrade to a Linux kernel build from the relevant distribution or vendor that includes the FarSync driver fix for unfinished tasklets during device detach. No exact fixed package versions were provided in the input, so remediation should use the vendor advisory, stable kernel changelog, or distribution security tracker for the deployed kernel branch. Where immediate patching is not possible, reduce exposure by disabling or removing the FarSync driver if it is not required, preventing the fst module from loading, disabling unused FarSync/HDLC WAN hardware, and restricting administrative or physical/virtual hardware hotplug operations. For systems that require the hardware, schedule a controlled maintenance window to update the kernel and reboot into the fixed version.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel version is a vendor-fixed build, not merely that an updated package is installed on disk. Check the active kernel with uname -r and compare it with the distribution advisory or kernel changelog containing the FarSync tasklet cleanup fix. Confirm whether the vulnerable driver is present or loaded using lsmod, modinfo, or kernel configuration checks for the FarSync driver. On systems where the driver is not needed, validate that it cannot be loaded automatically through module blacklist policy and that no FarSync PCI hardware is present. For deeper validation in test environments, reproduce controlled attach/detach or module unload scenarios with kernel sanitizers or crash monitoring enabled and confirm that no KASAN use-after-free, softirq, tasklet, or do_bottom_half_tx traces occur.

Typical attack path

1. Identify a Linux system running an affected kernel with the FarSync T-series WAN driver present and reachable through configured hardware, hotplug, module loading, or virtualized PCI paths.
2. Generate or trigger network transmit/interrupt activity through the FarSync driver so that fst_tx_task or fst_int_task is scheduled.
3. Trigger device removal, driver unload, PCI hot-unplug, slot disablement, or another path that reaches fst_remove_one().
4. Race the cleanup path so fst_card_info is freed while the previously scheduled tasklet is still pending or executing.
5. Allow the tasklet handler to run after free and dereference the stale card pointer in fst_process_tx_work_q(), fst_process_int_work_q(), or do_bottom_half_tx().
6. Use the resulting memory corruption to crash the kernel, disclose data, or attempt kernel-level privilege escalation depending on exploit reliability and memory layout control.

How to detect it

Investigate kernel logs, persistent journal entries, crash dumps, oops reports, KASAN reports, and endpoint telemetry for evidence of kernel memory corruption in the FarSync driver. Relevant log sources include dmesg, /var/log/kern.log, /var/log/messages, journalctl -k, kdump/vmcore analysis, hypervisor hardware hotplug logs, and change records for driver unloads or PCI device detach events. Look for slab-use-after-free reports involving do_bottom_half_tx, fst_process_tx_work_q, fst_process_int_work_q, fst_remove_one, tasklet_action_common, ksoftirqd, or acpiphp hotplug paths. Correlate any crash or warning with WAN/HDLC interface activity, FarSync device removal, PCI slot disable/eject events, module unloads, or repeated hardware reset operations. Because this vulnerability does not inherently create a stable user-space artifact, strong evidence is likely to appear as kernel crash telemetry rather than files, registry keys, or persistent network indicators.

• BUG: KASAN: slab-use-after-free in do_bottom_half_tx
• slab-use-after-free in do_bottom_half_tx
• fst_process_tx_work_q
• fst_process_int_work_q
• fst_remove_one
• do_bottom_half_tx
• tasklet_action_common
• ksoftirqd
• unregister_hdlc_device
• pci_stop_and_remove_bus_device
• acpiphp_disable_and_eject_slot
• acpiphp_hotplug_notify
• acpi_device_hotplug
• disable_slot
• enable_slot
• kfree+0x135
• KASAN: bad access detected
• Read of size 4 at addr
• freed 1024-byte region
• kmalloc-1k
• farsync
• fst_tx_task
• fst_int_task

What your security team should do

• Prioritize patching systems that use FarSync T-series WAN hardware, HDLC/WAN interfaces, PCI hotplug, or environments where device attach/detach can be triggered by less-trusted users or virtualization control planes.
• Inventory Linux hosts for the FarSync driver by checking loaded modules, kernel configuration, PCI devices, and WAN/HDLC interface usage.
• If the FarSync driver is not business-critical, disable or blacklist the module and remove unused hardware exposure until kernel updates are deployed.
• Monitor kernel logs for KASAN, slab-use-after-free, fst_remove_one, fst_process_tx_work_q, fst_process_int_work_q, do_bottom_half_tx, tasklet, and ksoftirqd crash indicators.
• Treat unexplained kernel panics or KASAN reports involving the FarSync driver as potentially security-relevant, especially if they coincide with device removal, PCI hotplug, or WAN interface activity.
• Because no KEV listing, ransomware use, or mature public exploit is currently reported, prioritize based on actual driver exposure rather than internet-wide urgency, while still addressing the high-impact kernel memory corruption risk.
• After patching, reboot systems into the fixed kernel and verify the vulnerable kernel is no longer running.