CVE-2026-43430

What it actually does

This is a Linux kernel race condition in the USB yurex driver during device probing. The driver submits a USB Request Block before initializing the descriptor field that tracks the bbu state. If the URB completion handler runs in the small timing window before initialization is complete, it can set the field and then have that value overwritten by the probe path. The resulting inconsistent driver state can lead to kernel instability or denial of service. Based on the assigned CVSS vector, exploitation is local, requires low privileges, has high complexity, does not require user interaction, and primarily affects availability rather than confidentiality or integrity.

Why it matters to the business

Successful exploitation can crash or destabilize Linux systems that load the vulnerable yurex USB driver, causing service interruption, workload disruption, or host reboots. The practical risk is lower than for remotely exploitable flaws because exploitation appears to require local access and precise timing, and there is no known public exploit or CISA KEV listing. However, systems that permit untrusted USB devices, shared physical access, kiosk use, lab environments, or broadly enabled kernel modules have higher exposure.

How an attack unfolds

An attacker first needs local access to a vulnerable Linux system or the ability to influence USB device attachment so that the yurex driver probes a matching USB device. The attacker then triggers repeated device probe events, likely using a physical or emulated USB device, to hit the race window between URB submission and initialization of the bbu descriptor state. If the URB completion handler runs at the wrong time, valid data retrieved by the completion path can be overwritten by the probe path's uninitialized marker. That inconsistent state can cause the kernel driver to behave incorrectly and may result in a kernel crash, hang, or other availability-impacting failure. There is currently no indication from the supplied data that this is being exploited in the wild, used by ransomware, or associated with named threat actors.

How to fix it

Apply a Linux kernel update from the operating system or distribution vendor that includes the upstream fix for the usb yurex probe race. No exact fixed package versions were provided, so use vendor advisories and kernel changelogs to identify the first fixed kernel for each distribution. After installing the updated kernel, reboot into the fixed kernel and remove or retire older vulnerable kernels where operationally feasible. If immediate patching is not possible and the yurex driver is not required, mitigate by preventing the module from loading, for example by blacklisting the yurex module through the distribution's supported modprobe configuration and rebuilding initramfs if required. Additional compensating controls include restricting physical USB access, disabling unused USB ports where practical, enforcing USB device control policies, and limiting local user access on systems where untrusted users may interact with hardware.

How to confirm the fix worked

Confirm the running kernel is the vendor-fixed version, not merely that the package has been installed. Verify with kernel package inventory, uname output, and distribution security advisory status. Check whether the yurex driver is present or loaded using module inventory tools such as lsmod, modinfo, and filesystem checks under the kernel modules directory. If the module is blacklisted as a mitigation, validate that the blacklist is active after reboot and that the module does not auto-load when a matching USB device is attached. Review vendor kernel changelogs or source package patches for the usb yurex probe race fix. For exposure validation, identify systems where the yurex module exists, is loaded, or where USB device attachment is permitted for untrusted users.

Typical attack path

1. Obtain local access to the Linux host or a path to attach/emulate a USB device that binds to the yurex driver.
2. Ensure the vulnerable yurex kernel driver is present and can be loaded during USB device probing.
3. Repeatedly attach, reset, or emulate the USB device to trigger the probe path.
4. Attempt to win the race between URB submission and descriptor state initialization.
5. Cause inconsistent driver state when the URB completion handler's value is overwritten by the probe logic.
6. Trigger kernel instability, crash, hang, or reboot, resulting in denial of service.

How to detect it

Detecting prior exploitation is difficult because this race condition is timing-dependent and may leave only generic kernel crash evidence. Review kernel logs, system journals, crash dumps, and endpoint telemetry for yurex driver load events followed by USB probe activity, kernel oops messages, hangs, panics, watchdog resets, or unexpected reboots. Useful log sources include dmesg output, journald kernel facility logs, /var/log/kern.log, /var/log/messages, /var/log/syslog, crash dump directories such as /var/crash, kdump/vmcore storage, audit logs showing module loading, and EDR telemetry for modprobe or insmod execution. Correlate suspicious events with physical access logs, USB attach/detach events, or repeated enumeration of the same USB device. A single crash is not proof of exploitation, but repeated crashes involving yurex module load or USB probing should be investigated.

• yurex
• yurex.ko
• modprobe yurex
• insmod yurex.ko
• /sys/bus/usb/drivers/yurex
• /lib/modules/*/kernel/drivers/usb/misc/yurex.ko
• usbcore: registered new interface driver yurex
• registered new interface driver yurex
• usb: yurex
• drivers/usb/misc/yurex.c
• Oops:
• kernel panic
• BUG: unable to handle kernel
• general protection fault
• watchdog: BUG: soft lockup

What your security team should do

• Prioritize patching Linux systems that allow physical USB access, run in shared-user environments, or expose local access to untrusted users.
• Update affected systems to a vendor kernel release that includes the yurex driver race-condition fix and reboot into the fixed kernel.
• If yurex devices are not used, blacklist or disable the yurex kernel module as a near-term mitigation.
• Restrict untrusted USB device attachment through physical controls, BIOS/UEFI settings, endpoint device-control tooling, or operating-system policy.
• Hunt for prior kernel crashes or oops events correlated with yurex driver loading or USB device attach/reset activity.
• Monitor for unexpected loading of the yurex module, especially on servers where USB peripherals are not expected.
• Because EPSS is very low, exploit maturity is listed as none, and the issue is not in CISA KEV, handle as a targeted local denial-of-service risk rather than an internet-scale emergency unless the organization has high-risk physical access scenarios.