Re: [PATCH 1/3] Input: xpad - add safer data access framework
[email protected] Mon, 03 Aug 2026 15:27:04 +0000
| Newsgroups | org.kernel.vger.linux-input |
|---|---|
| Message-ID | <[email protected]> |
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: Pre-existing issues: - [High] Processing GIP_CMD_ANNOUNCE can trigger sleeping functions from an URB completion handler. -- --- Patch [1]: [PATCH 1/3] Input: xpad - add safer data access framework --- commit 852b38f29eb8d0217357629e77fd629842b2aed4 Author: Griffin Kroah-Hartman <[email protected]> Input: xpad - add safer data access framework This commit introduces a safe_data struct and a safe data check function to prevent reads and writes outside of the data buffer bounds. > diff --git a/drivers/input/joystick/xpad.c b/drivers/input/joystick/xpad.c > index feb8f368f834e..c516860711a82 100644 > --- a/drivers/input/joystick/xpad.c > +++ b/drivers/input/joystick/xpad.c [ ... ] > @@ -1078,44 +1100,49 @@ static void xpadone_process_packet(struct usb_xpad *xpad, u16 cmd, unsigned char [ ... ] > - } else if (data[0] == GIP_CMD_ANNOUNCE) { > + } else if (sdata_check(&sdata, 0) == GIP_CMD_ANNOUNCE) { > int error; > > if (xpad->delay_init && !xpad->delayed_init_done) { > xpad->delayed_init_done = true; > error = xpad_start_input(xpad); [Severity: High] This is a pre-existing issue, but does this code path trigger sleeping functions from an atomic context? When an Xbox One controller sends a GIP_CMD_ANNOUNCE packet on the irq_in endpoint, the URB completion handler (which runs in atomic softirq context) processes it via xpadone_process_packet(). If xpad->delay_init is true and initialization hasn't completed, it calls xpad_start_input(), which subsequently uses GFP_KERNEL: xpad_start_input() { ... if (usb_submit_urb(xpad->irq_in, GFP_KERNEL)) return -EIO; ... } Additionally, xpad_start_input() calls xpad_start_xbox_one(), which makes a synchronous blocking call that sleeps: xpad_start_xbox_one() { ... error = usb_set_interface(xpad->udev, GIP_WIRED_INTF_AUDIO, 0); ... } Could this lead to a scheduling while atomic kernel panic when a device sends this command during URB completion? > if (error) > dev_warn(&xpad->dev->dev, > "unable to start delayed input: %d\n", > error); > } -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=1