CVE-2026-45954

What it actually does

This is a local availability issue in the Linux kernel framebuffer driver for the Au1200 platform. During au1200fb driver probing, an error path in au1200fb_drv_probe() returned immediately when platform_get_irq() failed, skipping required cleanup and leaking allocated memory. Repeated triggering of the failing probe path could consume kernel memory over time and degrade or crash the system. The flaw does not provide confidentiality or integrity impact by itself and is not known to enable privilege escalation.

Why it matters to the business

Affected Linux systems that load or probe the vulnerable framebuffer driver may be susceptible to local denial of service through gradual kernel memory exhaustion. In practical terms, exploitation could cause instability, service interruption, or unplanned reboot on systems where an untrusted local user can influence device probing or module loading. Risk is lower for systems that do not include, load, or use the au1200fb framebuffer driver. There is no current CISA KEV listing, no known ransomware association, and no public exploit maturity reported, so remediation should be handled through normal kernel patch cycles unless the driver is present on sensitive or multi-user systems.

How an attack unfolds

An attacker needs local access to a system running a vulnerable Linux kernel with the affected au1200fb framebuffer driver available and a way to cause the driver probe path to execute and fail at IRQ retrieval. The attacker repeatedly triggers the vulnerable probe failure condition. Each failed probe leaks kernel memory because cleanup is skipped. Over time, unreclaimed kernel memory accumulates, potentially causing memory pressure, degraded performance, failed allocations, hung workloads, or a kernel panic. Exploitation is constrained by local access requirements and by whether the affected driver is present and reachable on the target system.

How to fix it

Update the Linux kernel to a vendor release that includes the upstream fix for the au1200fb_drv_probe() cleanup path. Because no exact fixed package versions were provided, use the latest supported kernel from the operating system or appliance vendor and verify that it contains the fbdev au1200fb memory-leak fix. If immediate patching is not possible, reduce exposure by disabling or blacklisting the au1200fb driver where it is not required, removing unnecessary framebuffer support from custom kernels, restricting local shell access, and limiting permissions that allow users to load modules, bind devices, or otherwise trigger platform-driver probing. Systems that do not build, ship, or load the au1200fb driver are unlikely to be exposed to this specific flaw.

How to confirm the fix worked

Confirm remediation by checking that the running kernel version matches a vendor advisory or kernel build containing the au1200fb cleanup fix. On systems with source or debug packages available, verify that au1200fb_drv_probe() uses a cleanup path rather than returning directly after platform_get_irq() failure. Confirm whether the driver is present or loaded using kernel module and configuration checks such as searching for au1200fb in /proc/modules, /lib/modules/$(uname -r), and kernel config files. After patching or mitigation, attempt normal boot and hardware detection workflows and confirm there are no repeated au1200fb probe failures or unexplained kernel memory growth in dmesg, journal logs, or system monitoring.

Typical attack path

1. Gain local access to a Linux system, typically as a low-privileged user.
2. Determine whether the vulnerable kernel includes the au1200fb framebuffer driver or module.
3. Identify a way to trigger au1200fb device or platform-driver probing where platform_get_irq() fails.
4. Repeatedly trigger the failing probe path to leak kernel memory.
5. Continue until kernel memory pressure causes service degradation, failed allocations, system instability, or denial of service.

How to detect it

To determine whether exploitation may have occurred, review kernel logs, system journals, audit logs, and endpoint telemetry for repeated au1200fb driver probe failures, IRQ retrieval errors, module load attempts, device bind or unbind activity, and rising kernel memory usage before instability. Useful sources include dmesg output, /var/log/kern.log, /var/log/messages, systemd journal entries for the kernel, auditd records for init_module/finit_module/delete_module, shell history for privileged users, and monitoring data for slab memory, free memory, OOM killer activity, and unexpected reboots. Because the vulnerability is a memory leak rather than code execution, there may be no unique payload artifact; focus on repeated triggering patterns involving au1200fb, platform IRQ errors, and memory exhaustion symptoms. Also look for unauthorized local users attempting to load framebuffer modules or manipulate platform driver bindings under sysfs.

• au1200fb
• au1200fb_drv_probe
• platform_get_irq
• modprobe au1200fb
• insmod au1200fb
• /lib/modules/$(uname -r)/kernel/drivers/video/fbdev/au1200fb.ko
• /sys/bus/platform/drivers/au1200fb
• init_module
• finit_module
• delete_module
• Out of memory
• oom-killer
• Kernel panic - not syncing
• page allocation failure
• Memory allocation failure

What your security team should do

• Inventory Linux systems and kernel builds to determine whether the au1200fb framebuffer driver is present, built in, or loadable as a module.
• Prioritize patching for multi-user systems, embedded Linux platforms, systems that allow local user access, and systems where framebuffer or platform-device probing can be influenced by non-administrative users.
• Upgrade to the latest vendor-supported kernel containing the upstream fix; if fixed package versions are not published, track the relevant distribution kernel advisory.
• Disable or blacklist the au1200fb driver on systems where it is unnecessary.
• Restrict local access and administrative capabilities that permit module loading, device binding, or driver probing.
• Monitor kernel logs and memory telemetry for repeated au1200fb probe errors, IRQ retrieval failures, slab growth, out-of-memory conditions, or unexplained reboots.
• Treat confirmed exploitation as a denial-of-service incident and preserve kernel logs, audit logs, and command history from the affected time window.