CVE-2026-53055

What it actually does

This vulnerability is a race-condition use-after-free in the Linux kernel HiSilicon SEC2 cryptographic accelerator driver. During packet or cryptographic request transmission under heavy load, the hardware can complete processing and release the request object before the software transmit path has finished using it. Subsequent access to the freed request memory can corrupt kernel memory, trigger a kernel panic, or potentially be shaped into kernel-level code execution or privilege escalation if an attacker can reliably influence memory reuse. Practical exploitability depends on the presence of affected HiSilicon SEC2 hardware, the vulnerable driver being loaded or reachable, and the attacker's ability to generate sufficient cryptographic workload or request timing.

Why it matters to the business

Systems using affected Linux kernels with HiSilicon SEC2 cryptographic acceleration may experience instability, crashes, or service interruption during high cryptographic load. Although this issue is not currently listed in CISA KEV, has no known public exploit maturity, and has a low EPSS score, kernel memory-safety vulnerabilities can become high-impact if exploit techniques mature, especially on shared infrastructure, appliances, or platforms relying on hardware cryptographic acceleration.

How an attack unfolds

An attacker first needs access to a system running a vulnerable Linux kernel where the HiSilicon SEC2 crypto driver is present and usable. The attacker then causes a large volume of cryptographic operations or packet-processing activity that exercises the SEC2 transmit path. Under heavy load, the accelerator may complete a request and the kernel may free the associated request object before the transmit function has finished referencing it. If the freed memory is accessed after being recycled, the most likely result is a kernel crash or oops. A more advanced attacker would attempt to control allocation patterns around the freed request object so that the stale pointer references attacker-influenced kernel memory, potentially enabling privilege escalation or arbitrary kernel memory corruption. There is no indication from the provided data that this vulnerability is currently exploited in the wild or used by ransomware campaigns.

How to fix it

Upgrade to a Linux kernel build that includes the upstream fix for the HiSilicon SEC2 driver use-after-free, where the transmit path uses request-lifetime-safe context memory instead of the freed request object. Because no exact fixed package versions were provided, track and apply the relevant security update from the Linux distribution, appliance vendor, cloud image provider, or kernel branch maintainer. If immediate patching is not possible, reduce exposure by disabling or unloading the HiSilicon SEC2 driver where operationally safe, disabling hardware crypto offload for affected workloads, limiting local shell access, and restricting untrusted workloads from reaching kernel crypto APIs on systems with the affected hardware.

How to confirm the fix worked

Confirm the running kernel version includes the vendor or upstream patch for the HiSilicon SEC2 driver. Verify that package inventories, kernel images, and booted kernels match the patched version, not only that an updated package is installed. Check whether the affected driver is present or loaded using module and kernel configuration inspection, such as looking for HiSilicon SEC2-related modules or crypto accelerator configuration. After remediation, reboot into the patched kernel and run representative cryptographic workloads while monitoring kernel logs for SEC2, KASAN, use-after-free, general protection fault, oops, panic, or hardware crypto accelerator errors. For hosts where the driver was disabled as a mitigation, validate that it is not loaded after reboot and that cryptographic workloads fall back to an unaffected path.

Typical attack path

1. Identify a Linux system using an affected kernel with the HiSilicon SEC2 cryptographic accelerator driver available or loaded.
2. Obtain local execution or another path that can generate cryptographic operations handled by the vulnerable driver.
3. Create sustained high-load cryptographic traffic or request volume to exercise the SEC2 packet transmission path.
4. Trigger the timing window where hardware completion frees the request object before the software transmit path finishes using it.
5. Cause a kernel use-after-free condition, resulting in a crash, denial of service, or potentially controlled kernel memory corruption.
6. If exploit development is advanced, manipulate heap reuse to convert the bug into privilege escalation or kernel-level code execution.

How to detect it

To assess possible prior exploitation, review kernel logs, persistent journal entries, crash dumps, and monitoring telemetry for evidence of kernel memory corruption or crashes involving the HiSilicon SEC2 crypto driver. Useful sources include syslog, journald, dmesg captures, kdump/vmcore analysis, kernel oops reports, EDR telemetry for unexpected reboots, and workload metrics showing abnormal spikes in cryptographic operations before a crash. Look for KASAN use-after-free reports, kernel BUG or Oops messages referencing SEC2, HiSilicon crypto, hisi_sec, DMA completion, queue-pair contexts, or crypto accelerator transmit paths. Because successful kernel exploitation may leave limited application-level traces, absence of logs does not prove absence of exploitation. Correlate driver-related crashes with local user activity, container workload starts, stress-test tools, crypto benchmarking utilities, or unexplained high-volume TLS/IPsec/storage-encryption operations. No public threat actors, ransomware campaigns, or confirmed exploitation are indicated in the provided data.

• hisi_sec2
• hisi_sec
• hisi_sec2.ko
• hisilicon/sec2
• crypto: hisilicon/sec2
• use-after-free
• KASAN: use-after-free
• BUG: KASAN
• kernel BUG
• Oops:
• general protection fault
• kernel panic
• Unable to handle kernel NULL pointer dereference
• SEC2
• HiSilicon SEC
• hpre_sec
• qm
• queue pair
• qp_ctx
• req used-after-free

What your security team should do

• Prioritize patching Linux systems that use HiSilicon SEC2 hardware acceleration, especially production appliances, multi-user systems, and hosts running untrusted or tenant-supplied workloads.
• Inventory kernels and loaded modules to determine where the HiSilicon SEC2 driver is present and active.
• Apply vendor kernel updates that include the fix; ensure systems are rebooted into the patched kernel.
• If patching is delayed, disable the HiSilicon SEC2 driver or crypto offload where feasible and monitor for performance or application impact.
• Increase monitoring for kernel crashes, oops events, KASAN reports, and unexpected reboots on systems using this hardware.
• Treat repeated kernel faults involving hisilicon/sec2 or hisi_sec components as potentially suspicious, particularly if correlated with unusual cryptographic workload spikes.
• Continue tracking vendor advisories because exact fixed versions may vary by distribution and kernel branch.