From: sashiko-bot@kernel.org
To: "Guangshuo Li" <lgs201920130244@gmail.com>
Cc: dmitry.torokhov@gmail.com, linux-input@vger.kernel.org
Subject: Re: [PATCH] Input: xpad - ignore short Xbox One packets
Date: Wed, 08 Jul 2026 14:19:39 +0000 [thread overview]
Message-ID: <20260708141939.C278C1F00A3E@smtp.kernel.org> (raw)
In-Reply-To: <20260708135939.774433-1-lgs201920130244@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] Atomic context violation and double URB submission via xpad_start_input
--
--- Patch [1]: [PATCH] Input: xpad - ignore short Xbox One packets ---
commit d7d9f4eb601031ea325de5332a0575c0310240ad
Author: Guangshuo Li <lgs201920130244@gmail.com>
Input: xpad - ignore short Xbox One packets
This commit adds length checks for fixed-offset Xbox One packet fields and
skips optional extended fields when the corresponding bytes are not present.
This prevents parsing stale data left in the transfer buffer from previous
longer transfers when a malformed device sends a short packet.
> diff --git a/drivers/input/joystick/xpad.c b/drivers/input/joystick/xpad.c
> index feb8f368f834e..649f59b3a162f 100644
> --- a/drivers/input/joystick/xpad.c
> +++ b/drivers/input/joystick/xpad.c
[ ... ]
> @@ -1079,6 +1090,9 @@ static void xpadone_process_packet(struct usb_xpad *xpad, u16 cmd, unsigned char
> error);
[Severity: High]
This isn't a bug introduced by this patch, but is it safe to call
xpad_start_input() from here?
Since xpadone_process_packet() is called from the URB completion handler,
it runs in atomic softirq context. However, xpad_start_input() appears to
perform sleeping operations:
xpadone_process_packet()
xpad_start_input()
usb_submit_urb(xpad->irq_in, GFP_KERNEL);
It also calls xpad_start_xbox_one(), which uses synchronous USB control
messages that can sleep:
xpad_start_input()
xpad_start_xbox_one()
usb_set_interface(xpad->udev, GIP_WIRED_INTF_AUDIO, 0);
Could this sequence trigger might_sleep() warnings or cause a deadlock under
memory pressure? Additionally, could submitting xpad->irq_in while its
completion handler is still running cause a double-submission error?
> }
> } else if (data[0] == GIP_CMD_INPUT) { /* The main valid packet type for inputs */
> + if (len < 18)
> + return;
> +
> /* menu/view buttons */
> input_report_key(dev, BTN_START, data[4] & BIT(2));
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260708135939.774433-1-lgs201920130244@gmail.com?part=1
prev parent reply other threads:[~2026-07-08 14:19 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-08 13:59 [PATCH] Input: xpad - ignore short Xbox One packets Guangshuo Li
2026-07-08 14:19 ` sashiko-bot [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260708141939.C278C1F00A3E@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=dmitry.torokhov@gmail.com \
--cc=lgs201920130244@gmail.com \
--cc=linux-input@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox