CVE-2026-64376

What it actually does

This is a Linux kernel resource-management flaw in the firmware loader upload path. If firmware_upload_register() successfully creates a firmware sysfs device instance but a later allocation step fails, the error path frees the object directly instead of dropping the device-core reference with put_device(). That leaves the embedded struct device reference count unbalanced and can leak kernel resources. The most plausible technical consequence is local denial of service through gradual resource exhaustion in scenarios where the vulnerable registration path can be triggered repeatedly and allocation failures can be induced or naturally occur. There is no indication from the provided data that this enables remote code execution, privilege escalation, or direct data disclosure.

Why it matters to the business

The likely operational risk is reduced system stability on Linux hosts that use affected kernel firmware upload functionality, especially embedded, appliance, hardware-management, or driver-heavy systems where firmware upload registration may occur. Repeated triggering could contribute to memory/resource pressure, failed device registration, degraded hardware management functions, or host instability. Current urgency appears low because EPSS is very low, the issue is not in CISA KEV, it is not known to be used in ransomware campaigns, and no public exploit maturity is reported; however, kernel fixes should still be included in normal maintenance cycles because resource leaks can become reliability issues in production.

How an attack unfolds

An attacker would need a way to cause the vulnerable kernel firmware upload registration path to execute, typically through local interaction with a driver or subsystem that registers firmware upload support. The attacker would also need the registration flow to hit the specific failure condition after fw_create_instance() succeeds and alloc_lookup_fw_priv() fails, such as under memory pressure or repeated registration attempts. When this happens, the kernel takes the faulty cleanup path and leaks the device reference instead of releasing it through the device core. By repeating the condition, an attacker could potentially accumulate leaked kernel resources and contribute to denial of service. This is a constrained exploitation scenario and is more likely to be abused by a local actor or triggered accidentally under stress than exploited remotely over the network.

How to fix it

Apply the vendor-provided Linux kernel update that includes the firmware_loader fix changing the failure path to call put_device(fw_dev) and allow fw_dev_release() to perform cleanup. Because no exact affected products or fixed package versions were provided, track fixes through the relevant Linux distribution, appliance vendor, or kernel-stable advisory for the deployed kernel branch. Prioritize systems that expose firmware upload functionality, support field firmware updates, run custom drivers, or are sensitive to availability issues. If immediate patching is not possible, reduce exposure by limiting local administrative access, disabling unnecessary firmware upload or device-management features where operationally feasible, avoiding untrusted kernel modules/drivers, and monitoring for resource pressure or repeated firmware/device registration failures.

How to confirm the fix worked

Confirm remediation by verifying the running kernel build includes the upstream fix for firmware_loader: firmware_upload_register() error handling. Where source or vendor patches are available, validate that the failure path after alloc_lookup_fw_priv() failure uses put_device(fw_dev) rather than directly freeing the firmware sysfs object. On packaged systems, confirm the installed and running kernel version matches a vendor advisory that contains the fix, then reboot into the updated kernel if required. For exposure assessment, inventory Linux systems using firmware upload-capable drivers or hardware management features and confirm whether their kernel branch contains the vulnerable firmware_loader implementation. Functional validation can include stress or fault-injection testing in a non-production environment to ensure repeated firmware upload registration failures do not leak device references or increase unreclaimed kernel memory over time.

Typical attack path

1. Obtain local ability to interact with hardware, drivers, modules, or interfaces that can cause firmware upload registration to occur.
2. Identify a driver or platform path that calls the vulnerable firmware_upload_register() routine.
3. Create or wait for memory pressure so the later allocation step fails after the firmware sysfs device instance has been initialized.
4. Repeat the registration/failure sequence to accumulate leaked kernel device references.
5. Cause progressive resource exhaustion, failed firmware upload registration, degraded device behavior, or host instability.

How to detect it

There are no known public exploit indicators, named threat actors, KEV activity, or ransomware use associated with this issue in the provided intelligence. Detection should focus on signs of attempted or accidental triggering rather than definitive compromise. Review kernel logs, system journals, and hardware-management service logs for repeated firmware upload registration failures, firmware sysfs/device creation errors, allocation failures, memory pressure, OOM events, failed module or driver initialization, and unexplained device-management instability. Useful sources include dmesg, journalctl -k, /var/log/kern.log, /var/log/messages, audit logs for module loading or privileged hardware-management commands, and EDR telemetry showing repeated driver/module reloads. In deeper forensic or lab analysis, compare kernel memory/resource usage over repeated firmware upload registration failures and look for unreleased device objects or steadily increasing slab allocations related to device and firmware subsystems. Because the failure produces a resource leak rather than a unique payload or file artifact, absence of obvious logs does not prove absence of triggering.

What your security team should do

• Track and apply the relevant Linux kernel or distribution update during the next scheduled patch cycle; escalate priority for systems where availability is critical or firmware upload features are actively used.
• Inventory Linux hosts, appliances, and embedded systems that rely on firmware upload, hardware lifecycle management, or custom kernel drivers.
• Confirm that production systems are booted into the patched kernel after updates; merely installing a kernel package is insufficient until the host is restarted or live-patched if supported.
• Restrict local shell, sudo, module-loading, and hardware-management access to trusted administrators because practical exploitation requires local or privileged interaction with kernel-adjacent functionality.
• Monitor for abnormal kernel memory growth, repeated device registration failures, firmware upload errors, OOM activity, or instability on systems that cannot be patched promptly.
• Do not treat this as an internet-facing emergency based on current intelligence: EPSS is low, no KEV listing is present, no ransomware use is reported, and exploit maturity is listed as none.