CVE-2024-39478: Linux StarFive RSA driver stack memory bug fixed upstream

A subtle memory-management bug in the Linux kernel's StarFive crypto driver has been tracked as CVE-2024-39478 and fixed upstream — the flaw arises when code calls kfree on a variable-length buffer that was allocated on the stack, producing undefined behavior that can crash or destabilize systems that expose the vulnerable code path.

Background​

The Linux kernel contains a family of drivers for StarFive SoCs (for example, the JH7110 series used in VisionFive boards and other RISC-V platforms). One of those drivers implements RSA operations in drivers/crypto/starfive and, until patched, used a variable-length buffer for RSA textual data that lived on the stack. Calling kfree on a pointer into that stack storage is incorrect and leads to undefined behavior in the kernel — an availability-impacting defect mapped to CVE-2024-39478. Multiple mainstream trackers (NVD and several Linux distribution advisories) record the issue and characterize it primarily as an availability/DoS risk caused by memory corruption in the StarFive RSA implementation. The upstream Git history and vendor advisories indicate the bug was introduced and later corrected in stable kernel trees; distributors have issued kernel package updates to carry the fix into released images.

---

What happened: the technical summary​

The bug, in plain terms​

• The vulnerable code accepted RSA text data of variable length and used a stack-based buffer to hold that data.
• At certain code paths the implementation freed that buffer with kfree, which is intended to release heap-allocated memory — not stack memory.
• Freeing stack memory produces undefined behavior inside the kernel: control structures, return addresses, and other critical state can be corrupted or the allocator bookkeeping can be confused, leading to crashes, kernel panics, or other instability.

Where it sits in the codebase​

• The flaw was associated with the StarFive RSA implementation, specifically the function identified in public advisories as starfive_rsa_enc_core and the file drivers/crypto/starfive/jh7110-rsa.c in upstream kernel trees. Distribution advisories and vulnerability databases reference those symbols and files.

How the fix was implemented (high level)​

• Upstream maintainers patched the driver to avoid calling kfree on stack memory — instead ensuring temporary buffers are allocated and freed correctly (or using properly-sized heap allocations and bounds checks), and adjusting the implementation so pointers passed to kfree point only to heap-allocated objects.
• The change set appears in the stable kernel trees and has been ported into distribution kernel updates; OSV and repo diffs reference the commits that close the vulnerable window.

---

Impact assessment​

Affected platforms and likely exposure​

• The driver is specific to StarFive SoCs (for example, JH7110-based platforms). That narrows the population at risk: typical x86/AMD64 servers and desktops are not affected unless they run kernels that include the StarFive crypto driver for some special reason. Most commonly affected targets are RISC‑V boards and embedded systems that enable this crypto driver in their kernel builds.
• Distribution advisories indicate vulnerable kernel ranges and list the fixed package versions that distributors shipped to remediate the issue. Administrators running distribution kernels should treat those package updates as authoritative for their platforms.

Attack vector and severity​

• Public trackers consistently classify the vector as local (AV:L) with low complexity. In short: an attacker with local access — or with the ability to execute code or supply crafted inputs on a host that triggers the StarFive RSA path — can cause instability or a denial‑of‑service. Several advisories show CVSS v3.1 vector strings that reflect local attack with low privileges required.
• The principal impact is availability (crash or DoS). There is no authoritative public evidence that this specific bug leads to reliable privilege escalation or remote code execution — while memory corruption in the kernel can sometimes be escalated by skilled exploit developers, no public PoC or reports of active exploitation tied to CVE-2024-39478 have been published as of the latest advisories. Treat claims that the bug yields remote code execution as unverified unless a confirmed exploit or technical write-up appears.

Likelihood and real‑world risk​

• The risk is moderate for devices that enable the StarFive RSA driver and expose the vulnerable path; for general-purpose servers the practical attack surface is small.
• Many distribution notices emphasize the need to patch because even local, low‑complexity DoS bugs can become highly disruptive on embedded gateways, edge devices, or systems carrying critical workloads where a kernel crash equates to operational downtime.

---

Verified facts and cross-checks​

Key claims below have been confirmed against multiple independent sources:

• The defect is recorded as CVE‑2024‑39478 in public vulnerability trackers (NVD/CVE databases).
• Description: the StarFive crypto RSA code freed a stack buffer with kfree, producing undefined behavior. This description appears in NVD and multiple distro advisories.
• The vulnerability affects StarFive JH7110 crypto driver code in drivers/crypto/starfive/jh7110-rsa.c; public distro advisories and vulnerability feeds reference that file and the starfive_rsa_enc_core function.
• The exposure is primarily a local denial-of-service with a medium severity score used by distributions (CVSS ~5.5; ratings vary slightly by distributor’s assessment).

Where claims could not be independently verified:

• There are no public, authoritative exploit demonstrations showing escalation from this bug to reliable arbitrary code execution. Claims that such an escalation is trivial should be treated with caution pending a public proof or researcher disclosure. Public advisories emphasize availability impact rather than confirmed code execution.

---

Who should care — prioritized guidance​

If you manage systems or devices that might include StarFive drivers, follow this prioritized checklist.

1. Inventory first (high priority)​

• Confirm whether your kernels include the StarFive crypto driver: look for drivers/crypto/starfive in your kernel config, the presence of the jh7110-rsa module, or kernel build flags that enable StarFive crypto.
• On distribution kernels, match your running kernel version against your vendor’s advisory and the fixed package versions they published. Many distributors listed kernel package updates tied to the fix (for example, Ubuntu and SUSE advisories describe affected kernels and update numbers).

2. Patch (immediate)​

• Apply vendor-supplied kernel updates that include the fix for CVE‑2024‑39478. Distributors have released patched kernel packages and security advisories listing the exact package names and versions to install. If you build your own kernels from source, update to the upstream commit that fixes the issue or pick the first stable kernel release that carries the repair and rebuild your images.

3. Mitigate when patching is delayed​

• If you cannot patch immediately:
• Restrict local access to devices that may contain the vulnerable driver (network segmentation, host-based firewall rules, console access controls).
• Disable or blacklist the StarFive RSA module if permissible for your workload: unloading or blacklisting drivers that you do not use reduces exposure. Test the impact of removing the module; some embedded devices may rely on on‑chip crypto drivers for normal operation, so this may not be viable everywhere.
• Harden local user access controls: enforce least privilege, require strong authentication to consoles, and minimize untrusted local code execution.

4. Monitor and detect​

• Look for unexplained kernel panics, OOPS messages, or crashes on affected devices and cross-check kernel logs for traces that implicate drivers/crypto/starfive or RSA operations.
• For managed fleets, use configuration management or vulnerability scanners to flag hosts that match the vulnerable package/kernel versions listed in your distribution’s advisory.

---

Technical analysis: why this class of bug matters​

Stack vs heap — the core mistake​

Freeing memory with kfree expects the pointer to reference heap-managed memory obtained from kmalloc or related allocation APIs. Stack memory is not heap-managed and should never be freed with kfree. Doing so leads to allocator corruption and can break assumptions across the entire kernel memory management subsystem.
This is a category of memory-safety error: while it may appear minor at the driver level, a kernel-mode memory management error can have system-wide ramifications. In practice, this style of bug tends to cause:

• immediate kernel instability and crashes (availability impact),
• unpredictable behavior that complicates debugging, and
• in some cases, exploitable memory corruption sequences if additional primitives or information leaks exist in the environment.

Why crypto drivers are sensitive​

Cryptographic drivers often run with privileged kernel context, are exercised by stack-sensitive code paths, and may handle input from userspace or firmware. Mistakes in crypto drivers are high-impact because they touch security-critical code paths and run at the highest privilege level. Although this specific defect maps to DoS/availability, the category remains worrisome in the broader threat model.

---

Distribution response and patch status (practical snapshot)​

• Ubuntu and several other mainstream distributions published advisories mapping CVE‑2024‑39478 to fixed kernel package versions; Ubuntu’s CVE page lists the published advisory and the CVSS assessment used by Canonical’s security team. Administrators should follow their vendor’s USNs and OS-specific update instructions.
• SUSE marked the issue resolved in its tracking and provided its assessment of the severity; SUSE and other distributor trackers may list slightly different CVSS calculations but agree on the remediation path: install the fixed kernel packages.
• OSV and kernel repo diffs identify the commits that introduced and later corrected the bug, which is useful for custom-kernel builders who need to locate the exact upstream change to include in backports or internal kernel builds.

---

Detection checklist and forensic indicators​

• Kernel logs with OOPS or backtraces referencing drivers/crypto/starfive, jh7110-rsa.c, or similar crypto stack traces.
• Recurrent crashes during RSA operations or when userspace software calls into kernel crypto APIs (for example, during signing/verification workloads on devices that use on-chip RSA acceleration).
• Discrepancies between kernel builds: compare your running kernel’s commit hash or version string to the affected ranges listed in OSV and distributor advisories to determine whether you need to patch or rebuild.

---

Risk trade-offs for embedded and IoT vendors​

• Embedded vendors who supply firmware or devices based on StarFive SoCs must treat this as a priority. Devices with on-chip crypto offload are often in constrained update channels and may remain exposed until vendors release firmware or kernel updates.
• For those with long device lifecycles, the practical steps include issuing firmware/kernel updates, coordinating with customers, and, where updates are impossible, documenting the risk and applying network-level compensations (isolation, restricted management access).
• For data centers and cloud operators: the bug’s real-world impact is limited if StarFive drivers are not present in your images; however, cloud marketplaces and third‑party image consumers should validate the presence of the driver in custom images and treat any image that includes the vulnerable driver as in-scope for patching.

---

Final analysis — strengths, residual risks, and recommendations​

Notable strengths in the ecosystem response​

• The issue has been tracked with a CVE and appeared in major vulnerability databases (NVD/OSV), meaning there is a public record and remediation tracking for administrators.
• Distributors quickly integrated upstream fixes into kernel package updates and published advisories with precise package names and versions to install, enabling administrators to remediate without reworking kernel trees from scratch.
• The upstream fix is focused and surgical: correct allocation/freeing semantics without broad behavioral changes to the driver, reducing regression risk for backport patches. Repository diffs reflect small, targeted fixes in the starfive driver files.

Residual risks and caveats​

• The vulnerability's footprint is narrow (StarFive-specific crypto driver), but affected devices often operate in critical edge or embedded roles where even a local DoS is operationally acute.
• Patching embedded devices remains the largest operational hurdle — many deployed devices take months or longer to receive vendor firmware/kernel updates.
• While current advisories do not document remote exploitation or widespread in‑the‑wild attacks, memory-corruption bugs in the kernel have historically been escalated by skilled attackers when combined with other primitives; defenders should not dismiss the risk entirely. Treat claims of code execution or privilege escalation originating from this CVE as unverified until demonstrable proof appears.

---

Practical next steps (for administrators and vendors)​

• Inventory: detect any kernel builds that include drivers/crypto/starfive or the jh7110-rsa module. Use package inventories, kernel config checks, and image scans.
• Patch: apply vendor-supplied kernel updates or upstream patches; for custom kernels, merge the upstream fix and rebuild. Prioritize devices that perform RSA operations or serve as management gateways.
• Isolate: for unpatched systems, apply network isolation, minimize local access, and disable the driver where feasible.
• Monitor: add kernel crash/OOPS detection for diagnostic telemetry and track vendor advisories for follow-ups or related fixes.
• Vendor coordination: if you ship devices with StarFive SoCs, prepare coordinated update channels and advisories for customers; long-lived devices should include contingency plans for kernel security backports.

---

Conclusion​

CVE‑2024‑39478 is a clear example of how a seemingly small memory-management mistake — freeing stack memory with kfree — becomes a kernel-level availability issue with real operational consequences on affected platforms. The vulnerability is well-documented in public tracking systems, has an upstream correction in the Linux kernel tree, and has been integrated into distributor kernel updates; the practical mitigation is straightforward: identify affected systems and apply the supplied kernel patches or vendor updates. Because the defect affects a hardware-specific crypto driver, the immediate population at risk is limited, but for embedded, edge, and RISC‑V deployments this remains a priority patch. Defenders should patch promptly, monitor for kernel instability, and treat any unverified claims of remote exploitation with caution until a public proof is disclosed.

---

Source: MSRC Security Update Guide - Microsoft Security Response Center