CVE-2026-43175

What it actually does

This is a local Linux kernel memory-corruption flaw in the rs9 clock driver for the 9FGV0841 device. The driver registers eight clock hardware pointers for a chip with eight outputs, but the backing array was too small, causing out-of-bounds writes to adjacent fields in the driver data structure. The corruption can remain latent, but it is expected to crash the kernel during driver unbind or system suspend. The primary technical impact is local denial of service through kernel panic or unstable kernel behavior; no direct confidentiality or data-integrity impact is indicated by the published details.

Why it matters to the business

Systems running affected Linux kernels with the vulnerable rs9 clock driver and supported hardware may experience unexpected crashes, especially during suspend, resume, driver unbind, or hardware-management operations. This can interrupt production workloads, cause appliance or embedded-device downtime, and require manual recovery. The issue is not listed in CISA KEV, has no known mature public exploit, and has a very low, flat EPSS score, so broad internet-scale exploitation is unlikely; however, affected fleet segments that rely on this hardware should still be patched to prevent reliability incidents and local denial-of-service abuse.

How an attack unfolds

An attacker first needs local access to a system running a vulnerable Linux kernel where the rs9 clock driver is present and the 9FGV0841 device is used or can be bound to the driver. The attacker then causes the driver to initialize, reinitialize, unbind, or participate in a suspend/resume path. During device registration, the driver stores clock hardware pointers for outputs 4 through 7 past the end of the allocated array, corrupting adjacent kernel driver data. The corrupted state may not crash immediately, but later lifecycle operations such as unbinding the driver or suspending the system can dereference or free corrupted state and trigger a kernel oops or panic, producing a local denial of service.

How to fix it

Upgrade to a Linux kernel build that includes the upstream fix increasing the rs9 driver clock hardware pointer array to the maximum supported output count for 9FGV0841. Because no exact fixed package versions were provided in the input, obtain the corrected kernel from the relevant Linux distribution, appliance vendor, or kernel stable branch advisory. Where immediate patching is not possible, reduce exposure by disabling or blacklisting the affected rs9 clock driver if it is not required, avoiding unnecessary driver bind/unbind operations, limiting local administrative access to sysfs driver controls, and postponing nonessential suspend/resume workflows on affected systems until patched. Test mitigations carefully on embedded or hardware-dependent systems, because disabling a clock driver can affect device functionality.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel package or source tree contains the rs9 driver change that reserves eight struct clk_hw pointer slots for 9FGV0841. On managed Linux distributions, validate that the installed kernel version is at or above the vendor-advised fixed release and that the system has rebooted into that kernel. For source-based validation, inspect the rs9 clock driver and confirm the clk_hw pointer array is sized for the maximum 9FGV0841 output count. For exposure validation, inventory hosts for affected kernels, presence of the rs9 driver, and 9FGV0841-compatible hardware. After patching, perform controlled suspend/resume and driver lifecycle tests on representative hardware while monitoring kernel logs for oops, panic, slab corruption, or rs9-related errors.

Typical attack path

1. Gain local authenticated access to a Linux system running an affected kernel.
2. Confirm the rs9 clock driver and 9FGV0841-compatible hardware are present or that the vulnerable driver can be exercised.
3. Trigger driver probe, reprobe, unbind, or suspend/resume behavior through available local interfaces or administrative workflows.
4. Cause the driver to write clock hardware pointers beyond the allocated array bounds.
5. Wait for or trigger a lifecycle operation such as unbind or suspend that uses the corrupted driver state.
6. Crash the kernel or destabilize the host, causing denial of service.

How to detect it

To determine whether this was already exploited or triggered, review kernel logs, persistent journal entries, crash dumps, and uptime/reboot telemetry for crashes associated with the rs9 clock driver, 9FGV0841 devices, suspend/resume, or driver unbind events. Useful sources include /var/log/kern.log, /var/log/messages, /var/log/syslog, journalctl -k output, pstore/ramoops records, kdump vmcores, and audit logs for writes to sysfs driver bind/unbind controls. Look for kernel oops, panic, general protection fault, use-after-corruption symptoms, or slab corruption occurring shortly after local user activity, suspend/resume, or driver lifecycle operations. Because this vulnerability has no known mature exploit and is not in KEV, the most likely evidence will resemble reliability crashes rather than a distinctive intrusion signature; correlate crash timing with local logins, sudo activity, system sleep events, and sysfs driver-management actions.

• 9FGV0841
• rs9
• clk: rs9
• clk_dif
• /sys/bus/i2c/drivers/rs9/bind
• /sys/bus/i2c/drivers/rs9/unbind
• /sys/bus/platform/drivers/rs9/bind
• /sys/bus/platform/drivers/rs9/unbind
• BUG: kernel NULL pointer dereference
• general protection fault
• Oops:
• kernel panic - not syncing
• Unable to handle kernel paging request
• suspend entry
• PM: suspend entry
• PM: suspend exit

What your security team should do

• Prioritize patching systems that combine an affected Linux kernel, the rs9 clock driver, and 9FGV0841-compatible hardware, especially embedded, appliance, or high-availability systems where local crashes have operational impact.
• Obtain fixed kernel packages from the operating system or device vendor and reboot into the corrected kernel; do not rely only on package installation status.
• If patching is delayed, restrict local shell access and administrative permissions that can trigger driver unbind, bind, or power-management operations.
• Consider temporarily disabling or blacklisting the rs9 driver only where hardware owners confirm it is not required for safe operation.
• Add monitoring for kernel oops, panic, suspend/resume failures, and rs9 or 9FGV0841-related log entries on potentially affected systems.
• Treat repeated unexplained crashes around driver unbind or suspend/resume as suspicious until hardware fault, kernel bug, and local abuse are ruled out.
• Track vendor advisories for exact fixed kernel versions because the supplied vulnerability data does not include per-package fixed versions.