CVE-2026-43156

What it actually does

This is a Linux kernel denial-of-service vulnerability in the Pegasus USB Ethernet driver. During device probing, the driver historically assumed that USB endpoint 1 was bulk-in, endpoint 2 was bulk-out, and endpoint 3 was interrupt-in without first validating the endpoint descriptors exposed by the attached USB device. A malformed or malicious USB device can advertise endpoints whose transfer types do not match those assumptions, causing the driver to use incorrect URB pipes and potentially trigger a kernel assertion, warning, oops, or crash. The practical impact is local availability loss of the affected Linux system when the malformed USB network device is attached and the vulnerable driver probes it.

Why it matters to the business

An attacker with local ability to connect or emulate a USB device can crash affected Linux systems that load the Pegasus USB Ethernet driver, causing workstation, server, appliance, kiosk, lab, or embedded-device downtime. The impact is most relevant for systems with exposed USB ports, OT/edge devices, shared workstations, and environments where untrusted peripherals may be connected. There is no indication from the provided intelligence that this is remotely exploitable, used in ransomware campaigns, listed in CISA KEV, or currently associated with public exploit maturity; EPSS is very low and flat, so broad internet-scale exploitation is unlikely. However, operational risk can still be meaningful where physical access controls are weak or USB device emulation is feasible.

How an attack unfolds

An attacker prepares a malicious USB device, USB gadget, or emulation platform that presents itself in a way that causes the Linux Pegasus USB Ethernet driver to bind, but with endpoint descriptors whose transfer types differ from what the vulnerable driver expects. When the device is connected to an affected Linux system, the kernel enumerates the USB device and invokes the pegasus driver probe path. Because vulnerable versions do not verify that the expected endpoints are actually bulk or interrupt endpoints before constructing URBs, the driver may submit or initialize URBs using incompatible endpoint assumptions. This can trigger a kernel assertion or fault in the USB/network driver path, resulting in a kernel oops, panic, or loss of system availability. Exploitation requires local physical access or a trusted path to attach/emulate a USB peripheral; it is not a typical network-delivered attack.

How to fix it

Apply a Linux kernel update from the operating system or device vendor that includes the Pegasus USB Ethernet endpoint validation fix. The corrected implementation validates expected bulk and interrupt endpoints during pegasus_probe() using endpoint checking before resource allocation and rejects malformed devices at probe time. Because no exact fixed package versions were provided, use the latest vendor-supported kernel for the affected distribution, appliance, or embedded platform and confirm that the vendor advisory includes the fix for this issue. Where immediate patching is not possible, reduce exposure by disabling or blacklisting the pegasus driver if Pegasus USB Ethernet adapters are not required, restricting physical access to USB ports, disabling unused USB ports in firmware or operating system policy, using USB device control/allowlisting, and avoiding untrusted USB peripherals.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel version is at or above the vendor-fixed release that includes endpoint validation for the Pegasus USB Ethernet driver. Review vendor changelogs or kernel source to confirm the pegasus driver performs basic endpoint checks before allocating resources or submitting URBs. On Linux systems, check loaded modules with tools such as lsmod and modinfo for pegasus, and verify whether the driver is still needed. If the driver has been disabled as a mitigation, confirm that modprobe cannot load it and that Pegasus USB Ethernet devices no longer bind. For exposure testing in a controlled lab only, attach a malformed test USB device with mismatched endpoint descriptors and confirm that the fixed kernel rejects the device cleanly at probe time without a kernel oops, BUG, panic, or reboot.

Typical attack path

1. Gain local physical access to an affected Linux system, or compromise a path that can emulate or attach USB devices to it.
2. Prepare a malformed USB device that is likely to bind to the Pegasus USB Ethernet driver but advertises mismatched endpoint transfer types.
3. Connect the device to the target system or trigger USB enumeration through an emulation platform.
4. Allow the Linux kernel to load or invoke the pegasus USB network driver during device probing.
5. Trigger the vulnerable probe behavior where endpoint types are assumed rather than validated.
6. Cause a kernel assertion, oops, panic, or crash, resulting in denial of service.

How to detect it

Look for evidence of USB device insertion and kernel instability involving the Pegasus USB Ethernet driver. Relevant sources include system journal logs, /var/log/kern.log, /var/log/messages, dmesg output, audit logs for module loading if enabled, crash dump records such as kdump/vmcore, system reboot records, and endpoint-management telemetry for USB insertions. Investigate sequences where a USB device is enumerated, the pegasus driver is loaded or probed, and the system soon records a kernel BUG, WARNING, oops, panic, watchdog reset, or unexpected reboot. Because exploitation is local and device-triggered, strong indicators are temporal correlation between a new USB peripheral and a kernel crash, especially where the USB device identifies as or causes binding to a Pegasus-compatible USB Ethernet adapter. If crash dumps are available, examine kernel stack traces for pegasus, usbnet, URB submission, USB endpoint handling, or probe-time failures. There are no known network indicators, ransomware indicators, or named threat-actor artifacts from the provided intelligence.

• pegasus
• pegasus_probe
• usbcore: registered new interface driver pegasus
• USB Pegasus/Pegasus II Ethernet
• kernel BUG
• kernel Oops
• Oops:
• Kernel panic
• WARNING: CPU
• usb_submit_urb
• urb
• new high-speed USB device
• new full-speed USB device
• /var/log/kern.log
• /var/log/messages
• /var/crash
• /proc/modules

What your security team should do

• Prioritize patching systems where untrusted users can physically access USB ports, including shared workstations, kiosks, labs, field devices, edge systems, and embedded Linux appliances.
• Inventory Linux systems that have the pegasus USB Ethernet driver present, loaded, or autoloadable, and determine whether Pegasus USB Ethernet adapters are actually used.
• Update affected systems to a vendor kernel release that includes the endpoint validation fix; where fixed versions are unclear, track the distribution or device-vendor advisory until a corrected kernel is available.
• If the driver is not required, blacklist or remove the pegasus module and validate that it cannot be automatically loaded by USB device insertion.
• Apply physical and policy controls for USB exposure, including port locks, BIOS/UEFI USB restrictions, endpoint device control, and allowlisting of approved USB peripherals.
• Monitor kernel logs for USB enumeration followed by pegasus driver faults, kernel oops, BUG, panic, or unexpected reboots, especially on systems with public or semi-public physical access.
• Treat unexplained crashes immediately following USB insertion as a potential local denial-of-service event and preserve kernel logs, crash dumps, and connected-device details for investigation.