CVE-2025-21948: Linux HID appleir NULL Pointer DoS Patch and Mitigations

A NULL-pointer bug in the Linux HID appleir driver has been assigned CVE-2025-21948 and patched by kernel maintainers after Syzkaller surfaced a crash path that can be triggered by malformed HID reports; the issue can produce a local denial-of-service (availability) condition and has already been rolled into vendor security advisories — administrators should treat this as a medium-severity DoS risk, apply vendor kernel updates, or temporarily disable the appleir driver where that is feasible.

Background / Overview​

The Human Interface Device (HID) stack in the Linux kernel handles input from mice, keyboards, remotes and many other devices. The appleir driver specifically supports Apple infrared remote receivers and has existed in the kernel for years as the interface layer between HID reports and Linux input subsystem events.
In early 2025 a null-pointer dereference was reported by the Linux Verification Center using Syzkaller. The crash occurs when a malformed HID report causes a code path to call into the input-event machinery without a valid input device context. The kernel ends up dereferencing a NULL or uninitialized pointer inside input_event(), which can be observed in KASAN-enabled debug traces and results in a kernel crash or other availability disruption.
Kernel maintainers accepted a patch to check the relevant pointers and prevent the raw-event handler from calling input-event functions when the input device is not properly configured. Multiple distributions packaged the fix in security updates and published advisories within weeks of the public disclosure.

---

What exactly went wrong (technical root cause)​

The vulnerability is a classic NULL pointer dereference in the intersection of the HID appleir driver and the Linux input subsystem. The crash trace reported by Syzkaller shows the flow arriving at input_event() and failing an internal test that assumes a valid input device structure, which then triggers KASAN (KernelAddressSANitizer) null-ptr-deref reporting.
Broken down:

• The appleir driver registers a raw-event callback (appleir_raw_event) that receives HID reports from the device layer.
• In normal operation the appleir driver pairs itself with an input_dev via appleir_input_configured (the typical HID -> hidinput -> input device connection flow).
• Under some malformed-report conditions — the test harness and reports indicate report list entries with no fields — the hidinput connect/configure sequence may fail silently (hidinput connect fails to add a working input device), yet the appleir probe itself can still succeed.
• Because the probe succeeded, appleir_raw_event can be invoked later by the HID core when the device sends data. The raw-event handler assumes appleir->input_dev (or related structures) exist and proceeds to call input_report_key/input_event path (via key_down/key_up helpers).
• Those input_* helpers call into input_event(), which performs tests on the input device; with a missing input_dev pointer this becomes a NULL dereference.
• The net result is a kernel-level crash (or panic), or at minimum an unrecoverable driver fault until a reboot clears the condition.

This is a memory-safety bug in kernel space with the impact focused on availability rather than confidentiality or privilege escalation.

---

Proofpoint and discovery​

• The bug was found by automated fuzzing/verification (Syzkaller), evidenced by an attached KASAN backtrace that pinpoints input_event() and the call chain from appleir_raw_event through key_down and input_report_key.
• The crash is reproducible in environments where the HID reporting sequence is under attacker control — including emulator-driven inputs, USB device emulation, or malicious USB devices that present malformed report descriptors or report payloads.
• No widely published public exploit code is known at this time (the public advisories that shipped with the fix describe the crash and recommend patching). Vendors classified the impact as a local/low-privilege DoS (CVSS 3.1 base 5.5 in many advisories), consistent with a NULL dereference that requires local or adjacent access to trigger.

---

Impact: who and what is affected​

• Affected component: Linux kernel — specifically the HID appleir driver and its interactions with the input subsystem.
• Attack vector: Local. The attacker must be able to cause the kernel to process crafted HID reports. This typically means physical or virtual proximity (e.g., plugging in a malicious USB device, USB device redirection to a VM, or guest-to-host device emulation in some virtualization setups).
• Privileges required: Low privileges on the local host in the typical CVSS modeling — an authenticated local user or an attacker able to present a HID device to the kernel.
• Consequence: Availability impact — the CVSS and vendor advisories emphasize high Availability impact while Confidentiality and Integrity remain unchanged. That maps to a Denial-of-Service condition where the kernel may oops/kdump/reboot because of the NULL dereference.
• Scale: Systems that load the appleir module or contain the appleir code path are exposed. Many desktop and server kernels include the appleir driver by default as part of the HID tree, so exposure depends on the kernel configuration and runtime module loading policy.

Important contextual note: although the bug is local, modern infrastructure increases exposure compared with years past. USB device passthrough, USB over IP, remote desktop redirection, and virtual devices in cloud environments can allow attackers to present crafted HID data remotely or from another VM. Those scenarios require configuration-specific access, but they materially increase the attack surface beyond “person at the keyboard.”

---

Which distributions and kernels were patched​

Multiple downstream vendors incorporated the fix into their stable kernels and issued security advisories:

• Ubuntu published fixes as part of a broader kernel security update; package lists in distro advisories identify the patched linux-image package versions for LTS releases. Administrators using Ubuntu kernels should install the kernel updates described in the relevant USN advisory and then reboot.
• Amazon Linux (ALAS) added the CVE to its advisory set and released kernel updates for supported branches.
• Debian, Oracle Linux, SUSE and other major distributions also listed the CVE and released respective kernels or backported patches.
• The upstream kernel received a patch to check or guard against the missing input_dev path in the raw event handler, and that commit was included in the stable kernel maintenance stream.

Because distributions backport fixes to their shipped kernel versions differently, the exact package versions that include the remedy vary by vendor and by release — the right course of action is to follow your distribution’s security notice and apply the vendor-provided kernel update rather than relying on kernel-tree version numbers alone.

---

Mitigation and short-term workarounds​

If you cannot immediately apply vendor kernel updates, these practical mitigations can reduce exposure.

• Update and reboot (recommended)
• The only fully reliable mitigation is to install your distributor’s kernel updates that include the appleir fix, then reboot into the updated kernel. That removes the vulnerable code path altogether.
• Unload or blacklist the appleir module (temporary workaround)
• If the appleir driver is loaded as a module on your system, you can remove it until you can patch:
• As root: modprobe -r appleir
• To prevent the module from loading on boot, create a file under /etc/modprobe.d (e.g., blacklist-appleir.conf) containing:
• blacklist appleir
• Note: on systems that have the driver built into the kernel image (not modular), modprobe -r will not work. In that case, a vendor kernel update or booting with a different kernel is necessary.
• Restrict USB/physical device injection
• Harden device attachment points: restrict USB access where practical in sensitive environments.
• On servers, consider disabling (or configuring policies to restrict) hot-plugging or use host-based device-control solutions that block untrusted devices.
• Virtualized environments: be cautious with device passthrough and redirection
• Block or harden USB passthrough from untrusted tenants or VMs.
• Review hypervisor settings for device emulation and consider disabling unnecessary USB redirection features.
• Monitor and detect
• Watch kernel logs (dmesg, journald) for KASAN oops messages or input-subsystem faults mentioning input_event or related call stacks. A symptomatic log line includes KASAN null-ptr-deref and references the input subsystem and appleir call chain.
• If you see frequent input-subsystem errors correlated with HID device activity, treat that as an indicator to unload appleir and schedule patching.

Caveats: Blacklisting/removing appleir removes Apple infrared remote support. Assess operational impact before applying the workaround in production environments where Apple IR is required.

---

Detection and hunting guidance​

System administrators and SOC teams should look for the following signals:

• Kernel oops or KASAN traces in dmesg or journalctl that include keywords such as “KASAN: null-ptr-deref”, “input_event”, “appleir_raw_event”, or references to drivers/hid/hid-appleir.c in the stack trace.
• Sudden, reproducible kernel oops when a specific USB/HID device is plugged or upon certain device redirections.
• Repeated syslog entries tied to hid-core or hiddev subsystems indicating malformed HID reports being processed.
• In virtualized environments, correlate guest activity that triggers USB passthrough with host kernel logs.

Hunting checklist:

• Search current and historical kernel logs for the KASAN signature and the specific call chain (input_event -> is_event_supported -> appleir_raw_event) — these strings are distinctive and indicate the same class of bug.
• Check loaded modules: lsmod | grep appleir. If appleir is present and not required, stage the temporary unload.
• Inventory systems with HID subsystems exposed to untrusted device attachment vectors (e.g., desktops, thin clients, cloud VMs with USB redirection).

---

Exploitability and attacker scenarios (threat modeling)​

• Direct local attacker with a malicious USB device: An attacker who can physically insert a prepared USB HID device into a machine can potentially trigger the crash. This is the canonical local attack vector and applies to endpoints with open USB ports.
• Unprivileged local user delivering crafted HID input: In some contexts, unprivileged users can access gadget/emulation interfaces that allow them to present HID reports — that could enable local DoS without inserting physical hardware.
• Virtualization and passthrough: An attacker in a guest that can request USB redirection or pass through a virtualized device may induce the host (or another guest) to process malformed reports. The specific feasibility depends on hypervisor configuration — this is an area where local-only vulnerabilities gain practical remote-like reach.
• Remote exploitation via software: In general, a user-space program on a remote system cannot produce host HID events without some local bridge; hence remote, unauthenticated exploitation is unlikely. However, the chain of trust around device emulation and remoting features means administrators should not assume absolute safety for cloud and virtualized workloads.

Assessment: the bug is easier to exploit as a local DoS than to weaponize for privilege escalation or data theft. That is why vendors classify it primarily as an availability impact with medium CVSS scores. Still, for high-availability systems (e.g., kiosks, network appliances, thin clients) even local DoS can have serious business impact.

---

Why this class of bug still matters​

• The HID/input and USB subsystems are a large kernel attack surface: they accept complex descriptor languages and binary data from devices and emulators. Even small logic errors in handling corner-case reports can cause serious kernel failures.
• Automation and fuzzing (Syzkaller) continue to find these corner cases in actively maintained drivers; that is a feature of modern verification but also a reminder that legacy drivers (appleir dates back many years) can still harbor latent defects.
• Real-world exposure is increased by the ubiquity of USB, remote device redirection, and virtualization features in both enterprise and consumer environments.

---

Recommended immediate action list (for operators)​

• Inventory: Identify systems that load or may load the appleir driver. Typical commands:
• Check running modules: lsmod | grep appleir
• Check kernel config or package lists if uncertain whether the driver is built-in
• Patch: Coordinate with your change control to install vendor kernel security updates that include the CVE fix and reboot the machines into the patched kernel.
• Short-term mitigation: For systems where rebooting is impractical, unload the appleir module where it is modular: modprobe -r appleir; blacklist the module to prevent reload.
• Hardening: Restrict USB device usage; limit USB passthrough and disable unneeded device redirection features.
• Monitoring: Add alerting on journalctl/dmesg patterns that show KASAN/null dereference traces referring to input_event, hid-appleir, or appleir_raw_event.
• Test: In lab environments, attempt to reproduce the crash conditions only under controlled circumstances; do not attempt in production. Use the presence or absence of the kernel oops to validate mitigations.

---

Developer and maintainer notes (what the patch did)​

The upstream patch guards the raw-event handler against calling into the input subsystem when the appleir input device has not been configured or claimed. The change is conservative: if the expected input_dev context is missing the handler returns early and defers handling to hidraw/hiddev or ignores the malformed report, thus preventing the NULL pointer invocation of input_event().
This pattern — validate state before using pointers that may be NULL due to partial initialization or failed configuration — is the canonical fix for such races between probe/connect and raw-event invocation in driver code that relies on separate subsystems to complete setup.

---

Limitations and lingering questions​

• Exploit code: There is no widely published exploit demonstrating remote or privilege-escalation use of this issue; publicly available advisories indicate local DoS. That said, the absence of proof-of-concept code does not imply the attack is impractical in hostile environments where an attacker controls USB input or device emulation.
• Scope in embedded appliances and IoT: Devices that accept HID input from untrusted sources (e.g., kiosks or embedded systems that accept USB sticks) are at risk — in many deployments updating kernels is nontrivial and long-lived devices may ship with older vulnerable kernels. Operators should weigh device replacement or hardening options.
• Virtualization nuance: Whether a guest-to-host or guest-to-guest attack is feasible depends heavily on hypervisor configuration; organizations should evaluate USB passthrough and remote device features in their environment.

If any of these specifics are critical to your environment’s threat model, prioritize testing patches in a staging environment and confirm that your virtualization settings do not permit untrusted device injection.

---

Final assessment​

CVE-2025-21948 is a medium-severity, high-availability impact flaw in the HID appleir driver that can cause local Denial-of-Service through a NULL-pointer dereference in the input-event path. The root cause is well-understood — a raw-event handler can run without a properly configured input device — and maintainers applied a straightforward guard fix.
For most environments the correct operational response is simple and urgent: apply vendor kernel patches and reboot. Where that is not immediately possible, temporarily removing or blacklisting the appleir driver module and hardening device-attachment policies will materially reduce risk.
This CVE is another reminder that device-facing kernel code remains ripe territory for stability and security failures. Keep kernel updates on your maintenance radar, favor strong controls around device redirection and USB passthrough, and instrument kernel logging in production so that anomalous HID-related faults trigger immediate investigation.

---

Conclusion
The appleir NULL dereference is not a remote, wormable exploit — it’s a local-path DoS that nevertheless deserves quick remediation because of how easily malicious or malformed device data can be introduced in modern IT environments. Apply the official patches from your distribution, follow the short-term mitigations if you cannot patch immediately, and add targeted monitoring to catch any related kernel faults.

---

Source: MSRC Security Update Guide - Microsoft Security Response Center