CVE-2026-31520

What it actually does

CVE-2026-31520 is a local denial-of-service vulnerability in the Linux kernel HID Apple driver. The vulnerable apple_report_fixup() path allocates a copied HID report descriptor with kmemdup() and returns it without transferring ownership or freeing it, causing a kernel memory leak when the fixup routine is triggered. Repeated triggering can consume kernel memory over time, potentially degrading system performance or causing instability, service disruption, or a crash. The CVSS vector indicates local access with low complexity and low privileges, no user interaction, and high availability impact, with no direct confidentiality or integrity impact.

Why it matters to the business

Systems using affected Linux kernel versions may be vulnerable to local resource-exhaustion attacks that can make endpoints, servers, or embedded Linux devices unstable or unavailable. The practical risk is lower than remotely exploitable flaws because an attacker needs local low-privileged access and there is no evidence of public exploitation, KEV listing, or ransomware use; however, availability-sensitive environments should still prioritize kernel updates because kernel memory exhaustion can cause outages, failed workloads, or device reboots.

How an attack unfolds

An attacker who already has local access to an affected Linux system identifies that the Apple HID driver path can be reached, typically through interaction with a supported Apple HID device or a way to cause the kernel to parse relevant HID report descriptors. The attacker repeatedly triggers the apple_report_fixup() routine. Each invocation leaks a kmemdup()-allocated buffer because the returned pointer is not owned and freed by the caller. Over time, the leaked kernel memory accumulates. If repeated enough, the system may experience memory pressure, degraded performance, failed allocations, process disruption, or a kernel-level availability failure. There is currently no known public exploit maturity and EPSS is very low and stable, suggesting opportunistic exploitation is unlikely at this time.

How to fix it

Upgrade to a Linux kernel version that includes the upstream fix for the HID Apple apple_report_fixup() memory leak. Because no fixed version list was provided, use the affected distribution or vendor kernel advisory to identify the corrected package version for each platform. Reboot systems after applying kernel updates so the fixed kernel is running. Where immediate patching is not possible, reduce exposure by limiting local shell access, restricting untrusted users, disabling or blacklisting the Apple HID driver if it is not required, and controlling physical or virtual USB/HID device attachment. Mitigations should be treated as temporary because the root cause is in kernel code.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel, not only the installed package, contains the fix. Check the active kernel with uname -r and compare it against the distribution vendor’s advisory or changelog for the HID Apple memory-leak fix. Review package changelogs for references to apple_report_fixup(), HID: apple, memory leak, or this vulnerability. Validate that systems have been rebooted after patching. For exposure checks, identify systems with the hid_apple module loaded or available and affected kernel builds installed. If the driver was disabled as a mitigation, confirm the module is not loaded and cannot be auto-loaded through normal device attachment.

Typical attack path

1. Obtain low-privileged local access to a Linux system running an affected kernel.
2. Determine whether the Apple HID driver code path is present and reachable.
3. Connect, emulate, or otherwise interact with an Apple HID device/report descriptor path that invokes apple_report_fixup().
4. Repeatedly trigger HID report descriptor processing to leak kernel memory.
5. Continue triggering the leak until kernel memory pressure causes degraded performance, service failures, hangs, or system crash/reboot.

How to detect it

To assess possible prior exploitation, review host telemetry and kernel logs for signs of repeated Apple HID device initialization or report descriptor processing followed by increasing kernel memory pressure. Relevant sources include dmesg, journald, /var/log/kern.log, /var/log/messages, audit logs for local user activity, USB device attach/detach logs, EDR process and device-control telemetry, and memory/OOM monitoring. Look for unexplained out-of-memory killer events, kernel allocation failures, repeated hid_apple or Apple HID messages, rapid USB/HID device churn, and timing correlation between local user sessions or scripts and system instability. Because the vulnerability is a memory leak rather than code execution, there may be no durable file artifact or unique exploit string; detection should focus on behavioral evidence of repeated trigger attempts and resource exhaustion on affected kernels.

• hid_apple
• apple_report_fixup
• HID: apple
• Apple HID
• Out of memory
• oom-killer
• invoked oom-killer
• page allocation failure
• Memory allocation failure
• usbcore: registered new interface driver hid_apple
• /var/log/kern.log
• /var/log/messages
• /var/log/syslog
• /dev/hidraw

What your security team should do

• Inventory Linux systems running affected kernel versions, especially endpoints, developer workstations, servers with local multi-user access, and embedded/USB-capable systems.
• Prioritize patching on systems where untrusted users have local access or where USB/HID device attachment is possible.
• Apply vendor-provided kernel updates and reboot into the fixed kernel.
• If patching is delayed, restrict local access and untrusted device attachment, and consider disabling the hid_apple driver where operationally safe.
• Monitor for unexplained kernel memory pressure, out-of-memory events, HID device churn, or repeated hid_apple activity on unpatched systems.
• Track vendor advisories for exact fixed kernel package versions because fixed versions were not provided in the input.
• Treat the vulnerability as moderate urgency: low EPSS, no KEV status, and no known exploit maturity reduce immediate internet-scale risk, but kernel availability impact still warrants normal patch-cycle remediation.