CVE-2026-89437

What it actually does

A resource-management flaw in the Linux kernel platform/x86 int1092 SAR driver can leak kernel memory during device probe. Memory allocated for device_mode_info in parse_package() (reached via sar_get_data()) is not released on some sar_probe() error paths. Repeated failed probes can accumulate unreclaimed kernel allocations and pressure or exhaust memory, producing a local denial-of-service condition rather than code execution, data disclosure, or privilege escalation.

Why it matters to the business

Operational risk is low for most organizations. EPSS is about 0.002 and has been unchanged over 30 days, exploit maturity is none, the issue is not in CISA KEV, and it is not tied to ransomware. Only Linux systems that actually load the int1092 platform driver (typically certain x86 laptops with SAR/RF-related ACPI/platform support) are in scope. If a leak were driven hard enough, the host could slow, kill processes, or become unavailable, causing a local availability incident. Normal kernel patch cycles are appropriate; emergency out-of-band response is generally not justified by current threat data (published about 31 days ago, no named campaigns).

How an attack unfolds

This is a local initialization-time memory leak, not a remote or memory-corruption primitive. On a machine that binds the int1092 driver, an operator or local attacker who can repeatedly force sar_probe() through the leaky error paths causes device_mode_info allocations to be abandoned. Over many repetitions, kernel memory shrinks until the OOM killer runs or the system becomes unresponsive. There is no public exploit, no KEV listing, no ransomware use, and no named threat-actor activity. Abuse requires local influence over this specific platform driver and a way to hit those error paths repeatedly, which makes opportunistic or remote mass exploitation unlikely.

How to fix it

Install a Linux kernel from the OS or hardware vendor that includes the int1092 sar_probe() fix, which switches the leaky allocations to device-managed (devm) allocations so they are released automatically on probe failure and detach. Track distribution advisories for CVE-2026-89437 or the platform/x86 int1092 change; this record does not list per-package fixed versions. Reboot onto the patched kernel. If the SAR/int1092 driver is not required, temporarily blacklist or avoid loading that platform module until the patched kernel is deployed.

How to confirm the fix worked

Map installed kernel packages to vendor changelogs or CVE trackers for CVE-2026-89437, or confirm in the int1092 driver that device_mode_info is obtained with device-managed allocations in the sar_probe()/sar_get_data() path. Inventory exposure by checking whether the int1092 platform driver is present and bound. After upgrade and reboot, confirm a clean probe (or that the device is absent) and that kernel logs are not filling with repeated int1092 probe errors. Unpatched systems that never load this driver are not practically exposed.

Typical attack path

1. Identify a Linux host that loads the platform/x86 int1092 SAR driver.
2. Obtain local ability to influence driver probe or induce sar_probe() failure paths (not a network-facing service).
3. Cause the probe path that allocates device_mode_info and then returns without freeing it.
4. Repeat until leaked kernel allocations reduce free memory.
5. Availability impact appears as memory pressure, OOM-killed workloads, or an unresponsive host.

How to detect it

There is no known in-the-wild exploitation, no KEV activity, and no actor-specific playbook. Historical compromise would look like local availability stress, not a distinct implant. Review kernel logs (journald/dmesg/persistent kernel ring buffer) around int1092 or SAR platform probe failures; correlate with unexplained kmalloc/slab growth, meminfo anomalies, and OOM-killer events on the same host. Check whether the int1092 platform driver was loaded and whether probe was retried or the device was rebound repeatedly. Absent repeated probe errors plus kernel memory exhaustion, treat as unexploited. Network telemetry will not show this flaw.

What your security team should do

• Treat as a low-urgency local DoS kernel fix: fold into the next planned Linux kernel update; do not prioritize ahead of remotely exploitable or KEV issues.
• Inventory Linux x86 endpoints and images for the int1092/SAR platform driver and kernel versions lacking the sar_probe() leak fix.
• Patch and reboot onto vendor kernels that contain the device-managed allocation change; blacklist the unused driver only as a short-term exception.
• Do not expect in-the-wild mass exploitation; EPSS is ~0.002 and flat, exploit maturity is none, and the CVE is not in KEV.
• Watch distribution security trackers until exact fixed kernel package versions are published for each distro.