CVE-2024-26789: Linux ARM64 NEON AES Boundary Bug and Patch

A subtle bounds-checking bug in the Linux kernel’s ARM64 NEON crypto path — tracked as CVE-2024-26789 — can cause out-of-bounds memory accesses when processing short AES-CTR inputs; the flaw has been patched upstream by cloning a small but crucial workaround (temporary-buffering of sub‑16‑byte tails) into the bit‑sliced fallback path, and system administrators should treat this as a kernel-level availability and integrity risk that requires prompt, distribution‑specific updates. (nvd.nist.gov)

Background​

The Linux kernel includes highly optimized, architecture-specific cryptographic code for ARM64 that uses NEON SIMD instructions to accelerate AES in counter (AES‑CTR) and other modes. One of those implementations is a bit‑sliced AES routine (often named neonbs in the tree) designed to operate on multiple blocks in parallel for maximum throughput on wide inputs. For performance reasons, that path is optimized for bulk data and processes data in 128‑byte groups; when the input or the remaining “tail” is smaller, the code falls back to a plain NEON assembly helper that handles smaller sizes. (nvd.nist.gov)
The plain NEON helper performs memory accesses in 16‑byte granules — the size of a NEON register. Because inputs smaller than 16 bytes can appear, the helper’s glue code already implements a small defensive measure: it copies sub‑16‑byte in/outputs into a temporary, aligned buffer and operates on that to avoid reading or writing past user buffers. The vulnerability fixed in CVE‑2024‑26789 is that the bit‑sliced implementation’s fallback path did not consistently apply the same defensive copying when delegating to the plain NEON helper, which could lead to out‑of‑bounds reads or writes on very short inputs. (nvd.nist.gov)
This is a classic boundary‑handling bug: high‑performance code that assumes block-aligned inputs neglected a rare edge case, and that omission turned an otherwise safe fallback into a potential kernel memory corruption vector.

---

What exactly went wrong (technical overview)​

Bit‑sliced AES and the tail problem​

• Bit‑sliced AES rearranges data and operations so multiple AES blocks can be computed in parallel using bitwise operations and SIMD lanes; it’s extremely fast on large buffers but expects to work on full groups of input blocks.
• When the overall input size isn’t a multiple of the bit‑sliced group's operating window, the implementation must handle the “tail” — the remaining bytes that don’t fill a full parallel block.
• For tails smaller than the bit‑sliced block window, the implementation falls back to a plain NEON implementation that implements AES on conventional block boundaries. That plain implementation, however, expects to touch memory in 16‑byte NEON-sized chunks. (nvd.nist.gov)

The unsafe transition​

The bug appears when the fallback transition fails to account for inputs smaller than a NEON granule (16 bytes). The plain NEON helper’s glue code already uses a temporary buffer for these cases, but the bit‑sliced fallback did not replicate that temporary‑buffer behavior — so where the plain NEON path would have been protected, the fallback could call the helper directly against the short source/destination and cause reads or writes beyond the intended buffer. The fix simply clones the same short‑input temporary buffer approach into the fallback path so that the helper never operates on an undersized, unbounded region. (nvd.nist.gov)

---

Why this matters: integrity and availability at kernel level​

A kernel‑level out‑of‑bounds memory access is not an academic issue. The practical impacts reported by canonical sources include:

• Integrity impact: memory corruption could allow modification of kernel memory structures or data used by privileged code paths. On affected systems the vulnerability is rated as causing high integrity impact by one assessor. (nvd.nist.gov)
• Availability impact (DoS): kernel panics, oopses, or repeated crashes are a likely immediate consequence when the kernel reads or writes past a buffer boundary. Some vendors score the availability impact as significant and advise prompt patching.

Contextual severity scores vary by authority — for example, CISA’s ADP listing attached a CVSSv3.1 vector with a 7.1 (High) score, while some Linux distribution advisories record a lower operational score reflecting the local‑access attack vector and the narrow exposure of NEON‑accelerated AES‑CTR on ARM64 systems. Read those differences as complementary: the issue is serious at the kernel level but requires local access and specific hardware/crypto usage patterns to trigger. (nvd.nist.gov)

---

Who is affected​

• Any Linux kernel build that includes the ARM64 NEON AES bit‑sliced implementation is potentially affected. That includes many mainstream kernel versions during the affected window (various 5.18–6.x releases as recorded in vendor advisories). (nvd.nist.gov)
• In practice, impact is limited to systems running on ARM64 hardware where the NEON crypto acceleration is enabled and where code paths exercise AES‑CTR in the bit‑sliced mode. This covers:
• Embedded and IoT devices using mainline Linux or vendor kernels with NEON crypto
• ARM64 servers and cloud instances that enable the kernel’s NEON crypto acceleration
• Edge devices and appliances that rely on kernel crypto (for example, some VPN, storage, or encrypted filesystem code paths)
• Systems that do not use NEON crypto, or that run on x86/x86_64, are not affected by this ARM64‑specific bug. (nvd.nist.gov)

---

Patch and vendor response​

Upstream kernel maintainers fixed the bug by adopting the same short‑input temporary buffer approach in the bit‑sliced fallback path; the change is small but important — it eliminates the out‑of‑bounds call pattern by guaranteeing the helper always sees full NEON‑sized data. The fix has been merged into the upstream kernel trees and propagated into stable releases and vendor patches. (nvd.nist.gov)
Major Linux distributors and downstream kernel packagers have issued advisories and updates. For example:

• Amazon’s ALAS reports the vulnerability and shows fixes shipped for Amazon Linux 2023 kernels with specific advisory dates.
• SUSE has classified the issue as resolved in its kernel‑default package and documents its own CVSS assessment for distribution users.

Because kernel packaging and update timing differ by distribution and product, operators must rely on their vendor’s specific security advisories and kernel package versions — do not assume that an upstream fix has automatically arrived on your host. Verify with your distro’s security feed and the kernel package changelog before marking a host as remediated.

---

Exploitability, public proof‑of‑concepts, and real‑world risk​

As of the checks performed for this article, reputable vulnerability trackers and aggregators show no evidence of a public proof‑of‑concept (PoC) or widespread exploitation in the wild for CVE‑2024‑26789. That said, the vulnerability affects kernel memory handling — and such issues are inherently attractive to local attackers and research teams — so the absence of public exploits is not a guarantee that exploitation is impossible or will not appear after patch disclosures.
Operational risk is driven by three factors:

• Local access requirement: the attacker needs a local account or execution context on the target system (AV:L). That means remote, unauthenticated attacks are not viable unless chained with other vulnerabilities.
• Hardware and usage footprint: only ARM64 systems with NEON crypto enabled and running the affected AES‑CTR code paths are relevant.
• Patch availability and timing: unpatched systems remain exposed until a kernel update is installed and a reboot applied.

Given that the exploit vector requires local presence and specific crypto usage, organizations with strong host‑isolation, account controls and rapid update practices will find the practical risk modest. However, embedded systems, appliances, or cloud images that lag patched kernels can present a sustained risk — particularly where untrusted users can be granted shell or container access. (nvd.nist.gov)

---

Detection and forensic indicators​

If you suspect CVE‑2024‑26789 may have been triggered on a host, look for the following signs:

• Kernel oops messages or repeated kernel panics that correlate with cryptographic operations (look in dmesg and journal logs). Unbound memory accesses often show up as data aborts or kernel oops traces mentioning crypto or AES code paths.
• KASAN (Kernel Address Sanitizer) reports in development or specially compiled kernels — KASAN would show out‑of‑bounds or trunk reads/writes if it was enabled when the condition occurred.
• Unexplained service restarts or crashes for components that rely heavily on kernel crypto (VPN daemons, encrypted storage appliances).
• Correlate suspicious local user actions that invoked cryptographic workloads (large file encryption tasks, bulk disk encryption operations) around the time of a kernel trace.

Note: because this is a local‑access issue, system logs might only show ordinary user activity before the crash. Forensic investigation should prioritize kernel logs and any container or sandbox boundaries that might have allowed local code execution. (nvd.nist.gov)

---

Recommended mitigation and remediation steps​

Apply these actions promptly and in order of priority:

• Patch
• Update the Linux kernel to a vendor‑supplied package that includes the CVE‑2024‑26789 fix. Confirm the kernel package changelog or vendor advisory lists the neonbs bit‑sliced AES fix. Reboot hosts after installing the updated kernel.
• Prioritize at‑risk systems
• Identify ARM64 hosts that run cryptographic workloads (VPN gateways, encrypted storage servers, edge appliances). Treat those systems as higher priority for updates.
• Restrict local access
• Harden user account policies: remove unnecessary shell access, enforce least privilege, rotate credentials and keys where possible.
• For multi‑tenant appliances, isolate tenants and limit container escape risk — reduce the number of processes that could exercise kernel crypto in an untrusted context.
• Monitoring and detection
• Monitor kernel logs (dmesg/journal) for oopses and aborts; enable centralized logging to make correlation easier.
• If possible, deploy KASAN or other memory‑sanitizer builds in controlled test environments to validate fixes during patch testing.
• Configuration workarounds (temporary, high‑effort)
• There is no trivial configuration toggle that universally disables the affected path without reducing crypto acceleration or rebuilding kernels. Distribution packagers could offer kernel variants built without the NEON bit‑sliced AES path, but that is a heavy operational choice and not a practical long‑term substitute for patching.

If you operate embedded or appliance devices where immediate kernel updates are slow or impractical, raise the issue with your vendor or OEM and request a coordinated patch/backport schedule. For critical systems, consider compensating controls such as reducing privileged user sets and applying host hardening until updates can be applied.

---

Patching pitfalls and testing guidance​

• Don’t assume an upstream kernel commit equals an immediate, fully‑tested vendor patch. Confirm the vendor kernel package version and the advisory before marking a host remediated. Different distributions may backport the fix into different stable kernel numbers or patch sets.
• Test patches in a staging environment before rolling to production, especially for appliances or drivers that use kernel crypto acceleration. Performance regression or slight behavioral differences in NEON code paths are possible, and heavy crypto workloads should be smoke‑tested.
• On systems that must remain online for high availability, schedule maintenance windows and have rollback plans; kernel updates require reboots and can change driver behavior.

---

What defenders should watch for next​

• Proof‑of‑concept exploit code: the disclosure of a kernel patch often attracts researchers who will experiment with PoC exploits. Track vendor advisories and reputable vulnerability trackers for proof‑of‑concepts and any reports of active exploitation. As of the research for this article, no public PoC was found in major trackers, but that can change. Assume a patch‑disclosure window increases the chance that working exploits will appear.
• Chained attacks: because this bug requires local access, attackers could attempt to chain it with other vulnerabilities (e.g., web server escapes, container escapes, or misconfigured services) to escalate from remote to local privileges. Hardening and privilege separation reduce this risk.
• Backporting gaps: embedded device vendors or older distro kernels may lag significantly; defenders should inventory ARM64 assets and confirm vendor timelines.

---

Quick remediation checklist (for sysadmins)​

• Identify ARM64 hosts and prioritize those that handle crypto workloads.
• Check vendor advisories and kernel package changelogs for a patch that references the neonbs AES fix.
• Install vendor kernel updates and reboot hosts.
• Monitor dmesg/journal for immediately recurring kernel oopses after patching.
• If you cannot patch quickly: restrict local access, rotate credentials for exposed systems, and contact OEM/vendor support for backport or compensating controls.

---

Bottom line​

CVE‑2024‑26789 is an instructive example of how high‑performance, architecture‑specific kernel code can introduce risk when a rare edge case is missed. The fix is small and straightforward — copy short inputs into a temporary buffer in the fallback path — but the consequences of out‑of‑bounds kernel memory access are serious. Operators running ARM64 Linux on systems where NEON‑accelerated AES is used should treat this as an operational priority: verify vendor patches, install them promptly, and use standard hardening and monitoring to reduce the exposure window. (nvd.nist.gov)
As with all kernel vulnerabilities, the best long‑term defense is disciplined patch management and an asset inventory that surfaces non‑standard or embedded images where vendor patching may lag. If you manage such devices, contact your vendor for a definitive remediation timeline and request a secure upgrade path.
Conclusion: the code-level fix for CVE‑2024‑26789 is small, the operational fix is not — it requires coordinated patching and verification across ARM64 fleets. Treat this as a kernel update priority for affected hosts and assume that attackers will continue to probe kernel crypto paths for similar edge cases. (nvd.nist.gov)

---

Source: MSRC Security Update Guide - Microsoft Security Response Center