CVE-2026-43223

What it actually does

This is a local availability vulnerability in the Linux kernel pvrusb2 media USB driver. In pvr2_send_request_ex(), if the driver successfully submits a write USB Request Block (URB) but then fails to submit the corresponding read URB, it returns without unlinking or waiting for the write URB to finish. Because the same URB structure is later reused, a subsequent request can attempt to submit an already-active URB, triggering kernel warnings and potentially destabilizing the driver or host. The impact is denial of service rather than data disclosure or privilege escalation.

Why it matters to the business

Systems using affected Linux kernels with the pvrusb2 driver and compatible USB media hardware may be susceptible to local crashes, hangs, or device/driver instability. The risk is narrower than remotely exploitable kernel vulnerabilities because exploitation requires local access and a relevant driver/device path, and current EPSS is very low with no known KEV listing or public exploit maturity. However, for appliances, workstations, capture systems, or embedded Linux deployments relying on USB media devices, a crash can interrupt recording, monitoring, broadcast, or operational workflows.

How an attack unfolds

An attacker with local access first identifies that the affected kernel includes the pvrusb2 driver and that the driver can be exercised through a connected or emulated compatible USB media device. The attacker repeatedly triggers driver request paths that call pvr2_send_request_ex(), while inducing or racing a failure in read URB submission, such as through resource pressure or USB/device behavior that causes allocation or submission failure. In the vulnerable path, the write URB remains active when the function returns. The attacker then triggers another request, causing the driver to resubmit the same still-active URB. The kernel USB subsystem detects this invalid state and emits a 'URB submitted while active' warning; depending on kernel configuration and runtime conditions, this can lead to driver malfunction, repeated warnings, device failure, kernel instability, or denial of service.

How to fix it

Upgrade to a Linux kernel build that includes the pvrusb2 fix ensuring the write URB is unlinked and waited on when read URB submission fails. If vendor-specific fixed package versions are not available, apply the latest stable kernel updates from the operating system or appliance vendor once they include the upstream media/pvrusb2 patch. Where immediate patching is not possible, reduce exposure by preventing untrusted local users from accessing affected USB media devices, disabling or blacklisting the pvrusb2 module if it is not required, restricting physical USB access, and limiting module autoloading for unneeded media drivers.

How to confirm the fix worked

Confirm the running kernel package is updated to a vendor release containing the pvrusb2 URB leak fix. Verify whether the pvrusb2 module is present or loaded using standard kernel module inspection tools, and confirm it is disabled if not required. Review kernel changelogs or distribution advisories for the media:pvrusb2 fix to pvr2_send_request_ex(). After patching, exercise supported pvrusb2 device workflows under normal operation and confirm kernel logs no longer show active-URB warnings or pvrusb2 request failures.

Typical attack path

1. Gain local access to a Linux system running an affected kernel.
2. Confirm the pvrusb2 driver is present, loaded, or loadable and that a compatible USB media device path can be exercised.
3. Trigger pvrusb2 control/request operations that enter pvr2_send_request_ex().
4. Cause or wait for read URB submission failure after write URB submission succeeds, for example through resource pressure or crafted USB/device behavior.
5. Invoke the request path again so the driver attempts to submit an already-active reused URB.
6. Cause kernel warnings, driver instability, device malfunction, or host availability degradation.

How to detect it

Look for evidence of exploitation or attempted triggering in kernel and system logs, especially dmesg, journald, /var/log/kern.log, /var/log/messages, and crash/panic logs. Search for USB subsystem warnings indicating an attempt to submit an active URB, pvrusb2 driver errors, repeated USB media device resets, allocation failures around USB request handling, and kernel oops/panic events occurring shortly after pvrusb2 activity. Correlate these events with local user sessions, recent USB device insertion/removal, module load events, device-node access, and resource-exhaustion indicators. Because this vulnerability has no known public exploit maturity and no KEV listing, detection should focus on behavioral artifacts rather than known attacker tooling.

• URB submitted while active
• usb_submit_urb
• pvr2_send_request_ex
• pvrusb2
• media: pvrusb2
• pvrusb2:
• WARNING: CPU:
• kernel: WARNING
• dmesg:.*URB submitted while active
• /var/log/kern.log
• /var/log/messages
• /var/log/syslog
• pvrusb2.*URB
• usb_submit_urb.*active
• pvr2_send_request_ex.*ENOMEM

What your security team should do

• Prioritize patching Linux systems that use USB media capture devices, embedded media appliances, or workloads where local denial of service would be operationally disruptive.
• Inventory systems where the pvrusb2 module is loaded, available, or required, and separate them from systems that do not need the driver.
• Apply the latest vendor kernel updates that include the pvrusb2 fix; no exact fixed package versions were provided in the input.
• If patching is delayed, blacklist or unload pvrusb2 where it is not business-critical.
• Restrict local shell access, physical USB access, and device-node permissions for systems where the driver must remain enabled.
• Monitor kernel logs for URB activity warnings and pvrusb2 errors, especially on systems with untrusted local users or exposed USB ports.
• Treat this as lower internet-scale urgency due to local attack requirements, very low EPSS, no KEV listing, no ransomware association, and no known exploit maturity, while still addressing it through normal kernel maintenance cycles.