[PATCH AUTOSEL 6.19-5.10] media: pvrusb2: fix URB leak in pvr2_send_request_ex

Sasha Levin
2026-02-14T01:06:56Z

From: Szymon Wilczek <szymonwilczek@gmx.com>

[ Upstream commit a8333c8262aed2aedf608c18edd39cf5342680a7 ]

When pvr2_send_request_ex() submits a write URB successfully but fails to
submit the read URB (e.g. returns -ENOMEM), it returns immediately without
waiting for the write URB to complete. Since the driver reuses the same
URB structure, a subsequent call to pvr2_send_request_ex() attempts to
submit the still-active write URB, triggering a 'URB submitted while
active' warning in usb_submit_urb().

Fix this by ensuring the write URB is unlinked and waited upon if the read
URB submission fails.

Reported-by: syzbot+405dcd13121ff75a9e16@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=405dcd13121ff75a9e16
Signed-off-by: Szymon Wilczek <szymonwilczek@gmx.com>
Acked-by: Mike Isely <isely@pobox.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Analysis of pvrusb2 URB Leak Fix

### 1. Commit Message Analysis

The commit message is clear and well-structured:
- **Subject**: Explicitly says "fix URB leak" — this is a bug fix
- **Problem**: When the write URB is submitted successfully but the read
URB submission fails, the function returns without waiting for the
write URB to complete. The URB structure is reused, so a subsequent
call tries to submit a still-active URB.
- **Symptom**: Triggers a `'URB submitted while active'` warning in
`usb_submit_urb()`, which is a well-known USB core warning indicating
a real bug.
- **Reporter**: syzbot — fuzzer-found, reproducible bug
- **Acked-by**: Mike Isely (pvrusb2 maintainer) — subsystem maintainer
approved
- **Signed-off-by**: Hans Verkuil (media subsystem maintainer) — proper
review chain

### 2. Code Change Analysis

The fix adds 5 lines of code in a single error path:

```c
if (hdw->ctl_write_pend_flag) {
usb_unlink_urb(hdw->ctl_write_urb);
while (hdw->ctl_write_pend_flag)
wait_for_completion(&hdw->ctl_done);
}
```

**What it does**: When the read URB submission fails (`status < 0`), but
the write URB was already submitted and is pending
(`ctl_write_pend_flag` set), the fix:
1. Unlinks (cancels) the still-active write URB
2. Waits for the write URB completion callback to fire (which clears
`ctl_write_pend_flag`)

This is the correct pattern — it mirrors what the existing code already
does in the normal path (the `while (hdw->ctl_write_pend_flag ||
hdw->ctl_read_pend_flag)` loop further down), but adapted for this
specific error path.

### 3. Bug Classification

- **Type**: Resource leak / URB lifecycle mismanagement
- **Trigger**: Read URB submission failure (e.g., -ENOMEM) after
successful write URB submission
- **Consequence**:
- Active URB left dangling
- Next call to the same function triggers `'URB submitted while
active'` warning
- Could lead to undefined behavior with the USB subsystem, potential
data corruption or crashes
- **Reproducibility**: syzbot found it — reproducible with a concrete
trigger

### 4. Scope and Risk Assessment

- **Lines changed**: +5 lines added in a single file
- **Files affected**: 1 file (`drivers/media/usb/pvrusb2/pvrusb2-hdw.c`)
- **Complexity**: Very low — straightforward error path cleanup
- **Risk**: Minimal. The fix uses standard USB patterns
(`usb_unlink_urb` + wait for completion) that are well-established
throughout the kernel. The `ctl_write_pend_flag` check ensures we only
unlink if the write URB is actually active.
- **Regression potential**: Very low. This code path only executes when
read URB submission fails, and the fix ensures proper cleanup before
proceeding — strictly better than the current behavior.

### 5. User Impact

- **Affected users**: Anyone using pvrusb2 USB TV capture devices
- **Severity**: Medium-high — while pvrusb2 is not a widely-used driver,
submitting a still-active URB can cause USB core issues, kernel
warnings, and potentially crashes
- **Trigger likelihood**: Moderate — memory pressure situations can
cause `-ENOMEM` from `usb_submit_urb()`

### 6. Stability and Trust Indicators

- **Reported-by**: syzbot (automated, reproducible)
- **Acked-by**: Subsystem maintainer (Mike Isely)
- **Merged by**: Media subsystem maintainer (Hans Verkuil)
- **Fix pattern**: Standard, well-understood USB cleanup pattern

### 7. Dependencies

The fix is self-contained — it uses existing infrastructure
(`usb_unlink_urb`, `wait_for_completion`, existing flags) that has been
present in the pvrusb2 driver for years. No dependency on other recent
commits.

### 8. Stable Kernel Criteria

| Criterion | Met? |
|-----------|------|
| Obviously correct and tested | Yes — syzbot-reported, maintainer-acked
|
| Fixes a real bug | Yes — URB leak, 'URB submitted while active' |
| Important issue | Yes — can cause USB subsystem issues and warnings |
| Small and contained | Yes — 5 lines, 1 file |
| No new features | Correct — pure bug fix |
| Applies cleanly | Likely — the pvrusb2 code is stable and rarely
changed |

### Conclusion

This is a textbook stable backport candidate: a small, surgical fix for
a syzbot-reported URB lifecycle bug in a USB driver. It's maintainer-
acked, uses established patterns, has minimal regression risk, and fixes
a real bug that can cause kernel warnings and potential instability. The
fix is self-contained with no dependencies.

**YES**

drivers/media/usb/pvrusb2/pvrusb2-hdw.c | 5 +++++
1 file changed, 5 insertions(+)

diff --git a/drivers/media/usb/pvrusb2/pvrusb2-hdw.c b/drivers/media/usb/pvrusb2/pvrusb2-hdw.c
index b32bb906a9de2..5807734ae26c6 100644
--- a/drivers/media/usb/pvrusb2/pvrusb2-hdw.c
+++ b/drivers/media/usb/pvrusb2/pvrusb2-hdw.c
@@ -3709,6 +3709,11 @@ status);
"Failed to submit read-control URB status=%d",
status);
hdw->ctl_read_pend_flag = 0;
+ if (hdw->ctl_write_pend_flag) {
+ usb_unlink_urb(hdw->ctl_write_urb);
+ while (hdw->ctl_write_pend_flag)
+ wait_for_completion(&hdw->ctl_done);
+ }
goto done;
}
}
--
2.51.0