CVE-2026-46075

What it actually does

This is a local Linux kernel use-after-free and memory-leak flaw in the Atmel SHA204A hardware random number generator driver removal path. During device teardown, queued I2C workqueue callbacks and hwrng read operations could continue after associated driver state has been freed, creating a race condition that may allow a local privileged or low-privileged user with access to trigger device removal or driver unbind behavior to crash the kernel or potentially gain elevated privileges through controlled kernel memory corruption. The fix unregisters the hwrng, flushes pending work before teardown, and ensures sysfs entries and private hwrng state are consistently freed.

Why it matters to the business

Successful exploitation could cause affected Linux systems using the Atmel SHA204A driver to crash or, in a worst case, allow local privilege escalation to kernel-level access. Operational risk is highest for embedded, appliance, IoT, industrial, or hardware-backed Linux platforms that include this driver and expose device unbind/removal paths to local users or management software. The vulnerability is not known to be in the CISA KEV catalog, is not currently associated with ransomware use, has low EPSS, and has no public exploit maturity reported, so prioritization should be driven by whether the affected driver is present and reachable on production systems.

How an attack unfolds

An attacker first needs local execution on an affected Linux system. They identify that the Atmel SHA204A hwrng driver is loaded or the device is present, then attempt to race device removal, driver unbind, or teardown operations against hwrng read activity or queued I2C workqueue callbacks. If teardown frees driver-private memory while a pending callback or read path still references it, the attacker may trigger a use-after-free condition. In the simplest case this results in a kernel oops or system crash; with additional heap-shaping and reliable control of freed kernel memory reuse, the condition could potentially be developed into local privilege escalation.

How to fix it

Upgrade to a Linux kernel build that includes the upstream fix for the Atmel SHA204A driver removal path. If vendor fixed versions are not yet available, obtain patched kernel packages from the Linux distribution, appliance vendor, embedded platform vendor, or kernel maintainer for the affected branch. Where immediate patching is not possible, reduce exposure by disabling or blacklisting the atmel-sha204a driver if not required, preventing untrusted users from loading/unloading kernel modules or interacting with device unbind paths, restricting access to relevant sysfs driver controls, and limiting local shell access to trusted administrators only. Reboot systems after kernel updates to ensure the patched kernel is running.

How to confirm the fix worked

Confirm the running kernel includes the fix, not only that patched packages are installed. Validate with `uname -a`, distribution package metadata, vendor advisories, or source inspection showing the hwrng unregister, workqueue flush, and cleanup changes in the Atmel SHA204A driver. Check whether the driver is present or loaded using module listings, kernel configuration, device tree/I2C enumeration, and `/sys/bus/i2c/drivers/`. If the driver is not used, verify it is disabled or blacklisted and cannot be auto-loaded. After remediation, perform controlled functional testing of hardware RNG availability and device removal/unbind behavior on non-production systems and monitor for absence of kernel oops, KASAN reports, or hwrng/atmel-sha204a teardown errors.

Typical attack path

1. Obtain local code execution on an affected Linux system.
2. Confirm the Atmel SHA204A driver or device is present, for example via loaded modules, kernel logs, sysfs, or device tree/I2C enumeration.
3. Generate hwrng read activity or otherwise exercise the driver while repeatedly triggering device removal, unbind, module unload, or teardown behavior.
4. Race queued I2C workqueue callbacks against driver cleanup so freed driver-private state is referenced after teardown.
5. Cause a kernel crash or attempt to shape kernel heap reuse to convert the use-after-free into privilege escalation.

How to detect it

Look for evidence of prior local exploitation by reviewing kernel logs, persistent journal logs, crash dumps, audit logs, and EDR telemetry for kernel oopses, use-after-free reports, KASAN/KFENCE warnings, or crashes involving the Atmel SHA204A driver, hwrng subsystem, I2C workqueues, device unbind operations, or module unload activity. Useful sources include `/var/log/kern.log`, `/var/log/messages`, `/var/log/syslog`, `journalctl -k`, `dmesg`, pstore/ramoops, kdump/vmcore analysis, auditd records for writes under `/sys/bus/i2c/drivers/`, and shell/process telemetry showing repeated unbind, rmmod, modprobe, or hwrng access attempts. Because no public exploit-specific payload indicators are known, detection should focus on behavioral evidence: repeated driver removal attempts, kernel crashes around hardware RNG activity, unexpected access to sysfs driver bind/unbind files, and local processes manipulating I2C or hwrng interfaces shortly before a crash.

• atmel-sha204a
• atmel_sha204a
• hwrng
• /sys/bus/i2c/drivers/atmel-sha204a/unbind
• /sys/bus/i2c/drivers/atmel-sha204a/bind
• /dev/hwrng
• BUG: KASAN: use-after-free
• BUG: kernel NULL pointer dereference
• kernel BUG at
• general protection fault
• Unable to handle kernel paging request
• workqueue
• i2c
• rmmod atmel-sha204a
• modprobe -r atmel-sha204a

What your security team should do

• Inventory Linux systems, especially embedded and hardware-backed platforms, for presence of the Atmel SHA204A driver or compatible I2C device.
• Prioritize patching systems where the driver is loaded, local users can execute code, or management workflows can trigger device unbind/removal.
• Apply vendor kernel updates and reboot into the patched kernel; track exceptions where patched kernels are unavailable.
• If the hardware RNG is not required, disable or blacklist the affected driver as a compensating control.
• Restrict local administrative capabilities, kernel module loading, debug interfaces, and write access to sysfs driver bind/unbind controls.
• Enable and review kernel telemetry such as auditd, journald, dmesg collection, kernel oops capture, and EDR telemetry for signs of repeated driver teardown, module unload, or kernel crashes.
• Treat suspicious kernel oopses involving atmel-sha204a, hwrng, I2C callbacks, or use-after-free reports as potential exploitation attempts, especially when preceded by local user activity.