All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Rosalie Wanders" <rosalie@mailbox.org>
Cc: linux-input@vger.kernel.org, dmitry.torokhov@gmail.com
Subject: Re: [PATCH v2 1/4] HID: sony: use dedicated raw_event() handlers in sony_raw_event()
Date: Tue, 16 Jun 2026 21:08:18 +0000	[thread overview]
Message-ID: <20260616210819.0DB821F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260616205042.6671-3-rosalie@mailbox.org>

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:

Pre-existing issues:
- [High] Race Condition / Null Pointer Dereference in RB4_GUITAR_PS5 initialization.
- [High] Sleeping in Atomic Context in rb3_pro_instrument_raw_event.
--

commit ce2aa734b3cbe3b5ae8274fe7a1ef679e83470b5
Author: Rosalie Wanders <rosalie@mailbox.org>
Subject: HID: sony: use dedicated raw_event() handlers in sony_raw_event()

This commit simplifies how the sony driver processes raw events by introducing
dedicated handler function pointers inside the sony_sc structure. The
appropriate handler is now assigned during device configuration based on
hardware quirks.

> diff --git a/drivers/hid/hid-sony.c b/drivers/hid/hid-sony.c
> index 315343415e8f1..7da1fd1e52fea 100644
> --- a/drivers/hid/hid-sony.c
> +++ b/drivers/hid/hid-sony.c

[ ... ]

> +static int rb3_pro_instrument_raw_event(struct sony_sc *sc, u8 *rd, int size)
> +{
> +	/* Rock Band 3 PS3 Pro instruments set rd[24] to 0xE0 when they're
> +	 * sending full reports, and 0x02 when only sending navigation.
> +	 */
> +	if (size < 25 || rd[24] != 0x02)
> +		return 0;
> +
> +	/* Only attempt to enable full report every 8 seconds */
> +	if (time_after(jiffies, sc->rb3_pro_poke_jiffies)) {
> +		sc->rb3_pro_poke_jiffies = jiffies + secs_to_jiffies(8);
> +		rb3_pro_instrument_enable_full_report(sc);

[Severity: High]
This is a pre-existing issue, but can this call sequence sleep in an atomic
context?

The raw event handler usually executes in an atomic context, such as a USB URB
completion handler. This path calls rb3_pro_instrument_enable_full_report()
which allocates memory using GFP_KERNEL and issues a synchronous USB control
transfer via hid_hw_raw_request().

Could calling these blocking functions in atomic context trigger a might_sleep
warning or lead to a kernel panic?

> +	}
> +
> +	return 0;
> +}

[ ... ]

> -static void rb4_ps5_guitar_parse_report(struct sony_sc *sc, u8 *rd, int size)
> +static int rb4_ps5_guitar_raw_event(struct sony_sc *sc, u8 *rd, int size)
>  {
>  	u8 charging_status;
>  	u8 battery_data;
> @@ -1094,6 +1150,9 @@ static void rb4_ps5_guitar_parse_report(struct sony_sc *sc, u8 *rd, int size)
>  	u8 battery_status;
>  	unsigned long flags;
>  
> +	if (unlikely(size != 64 || rd[0] != 0x01))
> +		return 0;
> +
>  	/*
>  	 * Rock Band 4 PS5 guitars have whammy and
>  	 * tilt functionality, they're located at

[Severity: High]
This isn't a bug introduced by this patch, but could this handler dereference
a null pointer if an event arrives during device initialization?

Looking at sony_input_configured(), the raw event handler for the guitar is
registered, and hid_hw_open() is called because the device has battery support.
However, sc->input_dev is not assigned until after these initialization steps.

If the device sends a report immediately after the hardware connection opens,
would this event handler trigger and attempt to call input_report_abs() using
a null sc->input_dev pointer?

> @@ -1138,65 +1197,22 @@ static void rb4_ps5_guitar_parse_report(struct sony_sc *sc, u8 *rd, int size)
>  	spin_unlock_irqrestore(&sc->lock, flags);
>  
>  	input_sync(sc->input_dev);
> +	return 0;
>  }

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260616205042.6671-2-rosalie@mailbox.org?part=1

  reply	other threads:[~2026-06-16 21:08 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-16 20:50 [PATCH v2 0/4] HID: sony: more cleanup Rosalie Wanders
2026-06-16 20:50 ` [PATCH v2 1/4] HID: sony: use dedicated raw_event() handlers in sony_raw_event() Rosalie Wanders
2026-06-16 21:08   ` sashiko-bot [this message]
2026-06-16 20:50 ` [PATCH v2 2/4] HID: sony: use guard() and scoped_guard() Rosalie Wanders
2026-06-16 20:50 ` [PATCH v2 3/4] HID: sony: remove unneeded which argument from sony_schedule_work() Rosalie Wanders
2026-06-16 21:04   ` sashiko-bot
2026-06-16 20:50 ` [PATCH v2 4/4] HID: sony: use devm_kasprintf() Rosalie Wanders
2026-06-16 20:55 ` [PATCH v2 0/4] HID: sony: more cleanup Jiri Kosina

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=20260616210819.0DB821F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=dmitry.torokhov@gmail.com \
    --cc=linux-input@vger.kernel.org \
    --cc=rosalie@mailbox.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.