[PATCH 1/1] HID: uhid: Fix out-of-bounds write caused by raw events mismanagement

[PATCH 1/1] HID: uhid: Fix out-of-bounds write caused by raw events mismanagement

[Lee Jones]

Since the report ID is located within the data buffer, overwriting it
would mean that any subsequent matching could cause a disparity in
assumed allocated buffer size.  This in turn could trivially result in
an out-of-bounds condition.  To mitigate this issue, let's refuse to
overwrite a given report's data area if the ID in get_report_reply
doesn't match.

Cc: stable@vger.kernel.org
Fixes: fcfcf0deb89ec ("HID: uhid: implement feature requests")
Signed-off-by: Lee Jones <lee@kernel.org>
---
 drivers/hid/uhid.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/drivers/hid/uhid.c b/drivers/hid/uhid.c
index 21a70420151e..a0ee4e86656f 100644
--- a/drivers/hid/uhid.c
+++ b/drivers/hid/uhid.c
@@ -262,6 +262,10 @@ static int uhid_hid_get_report(struct hid_device *hid, unsigned char rnum,
 	req = &uhid->report_buf.u.get_report_reply;
 	if (req->err) {
 		ret = -EIO;
+	} else if (rnum != req->data[0]) {
+		hid_err(hid, "Report ID mismatch - refusing to overwrite the data buffer\n");
+		ret = -EINVAL;
+		goto unlock;
 	} else {
 		ret = min3(count, (size_t)req->size, (size_t)UHID_DATA_MAX);
 		memcpy(buf, req->data, ret);
-- 
2.53.0.273.g2a3d683680-goog

Re: [PATCH 1/1] HID: uhid: Fix out-of-bounds write caused by raw events mismanagement

[Jiri Kosina]

On Wed, 11 Feb 2026, Lee Jones wrote:

> Since the report ID is located within the data buffer, overwriting it
> would mean that any subsequent matching could cause a disparity in
> assumed allocated buffer size.  This in turn could trivially result in
> an out-of-bounds condition.  To mitigate this issue, let's refuse to
> overwrite a given report's data area if the ID in get_report_reply
> doesn't match.

Applied to hid.git#for-7.0/upstream-fixes, thanks.

-- 
Jiri Kosina
SUSE Labs

Re: [PATCH 1/1] HID: uhid: Fix out-of-bounds write caused by raw events mismanagement

[Benjamin Tissoires]

On Feb 11 2026, Lee Jones wrote:
> Since the report ID is located within the data buffer, overwriting it
> would mean that any subsequent matching could cause a disparity in
> assumed allocated buffer size.  This in turn could trivially result in
> an out-of-bounds condition.  To mitigate this issue, let's refuse to
> overwrite a given report's data area if the ID in get_report_reply
> doesn't match.

That's a strong assumption and a breakage of the userspace FWIW. The CI
is now full of errors:
https://gitlab.freedesktop.org/bentiss/hid/-/commits/for-7.0/upstream-fixes

It is pretty common to allocate the buffer and not initialize it in
get_report operations.

It was a bad API choice to have rnum and data[0] for all HID requests
(internally, externally), but we should stick to it. The CI breakage in
itself is not a big issue TBH, but if it breaks here, it will probably
break existing users.

Cheers,
Benjamin

> 
> Cc: stable@vger.kernel.org
> Fixes: fcfcf0deb89ec ("HID: uhid: implement feature requests")
> Signed-off-by: Lee Jones <lee@kernel.org>
> ---
>  drivers/hid/uhid.c | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/drivers/hid/uhid.c b/drivers/hid/uhid.c
> index 21a70420151e..a0ee4e86656f 100644
> --- a/drivers/hid/uhid.c
> +++ b/drivers/hid/uhid.c
> @@ -262,6 +262,10 @@ static int uhid_hid_get_report(struct hid_device *hid, unsigned char rnum,
>  	req = &uhid->report_buf.u.get_report_reply;
>  	if (req->err) {
>  		ret = -EIO;
> +	} else if (rnum != req->data[0]) {
> +		hid_err(hid, "Report ID mismatch - refusing to overwrite the data buffer\n");
> +		ret = -EINVAL;
> +		goto unlock;
>  	} else {
>  		ret = min3(count, (size_t)req->size, (size_t)UHID_DATA_MAX);
>  		memcpy(buf, req->data, ret);
> -- 
> 2.53.0.273.g2a3d683680-goog
> 

Re: [PATCH 1/1] HID: uhid: Fix out-of-bounds write caused by raw events mismanagement

[Jiri Kosina]

On Sat, 21 Feb 2026, Benjamin Tissoires wrote:

> > Since the report ID is located within the data buffer, overwriting it
> > would mean that any subsequent matching could cause a disparity in
> > assumed allocated buffer size.  This in turn could trivially result in
> > an out-of-bounds condition.  To mitigate this issue, let's refuse to
> > overwrite a given report's data area if the ID in get_report_reply
> > doesn't match.
> 
> That's a strong assumption and a breakage of the userspace FWIW. The CI
> is now full of errors:
> https://gitlab.freedesktop.org/bentiss/hid/-/commits/for-7.0/upstream-fixes
> 
> It is pretty common to allocate the buffer and not initialize it in
> get_report operations.
> 
> It was a bad API choice to have rnum and data[0] for all HID requests
> (internally, externally), but we should stick to it. The CI breakage in
> itself is not a big issue TBH, but if it breaks here, it will probably
> break existing users.

Lee,

was this found via code inspection, fuzzing, or is there some real-world 
report behind it?

Thanks,

-- 
Jiri Kosina
SUSE Labs

Re: [PATCH 1/1] HID: uhid: Fix out-of-bounds write caused by raw events mismanagement

[Jiri Kosina]

On Sat, 21 Feb 2026, Jiri Kosina wrote:

> > > Since the report ID is located within the data buffer, overwriting it
> > > would mean that any subsequent matching could cause a disparity in
> > > assumed allocated buffer size.  This in turn could trivially result in
> > > an out-of-bounds condition.  To mitigate this issue, let's refuse to
> > > overwrite a given report's data area if the ID in get_report_reply
> > > doesn't match.
> > 
> > That's a strong assumption and a breakage of the userspace FWIW. The CI
> > is now full of errors:
> > https://gitlab.freedesktop.org/bentiss/hid/-/commits/for-7.0/upstream-fixes
> > 
> > It is pretty common to allocate the buffer and not initialize it in
> > get_report operations.
> > 
> > It was a bad API choice to have rnum and data[0] for all HID requests
> > (internally, externally), but we should stick to it. The CI breakage in
> > itself is not a big issue TBH, but if it breaks here, it will probably
> > break existing users.
> 
> Lee,
> 
> was this found via code inspection, fuzzing, or is there some real-world 
> report behind it?

For now I've dropped this from for-7.0/upstream-fixes until it's all 
clarified.

Thanks,

-- 
Jiri Kosina
SUSE Labs

Re: [PATCH 1/1] HID: uhid: Fix out-of-bounds write caused by raw events mismanagement

[Benjamin Tissoires]

On Feb 24 2026, Jiri Kosina wrote:
> On Sat, 21 Feb 2026, Jiri Kosina wrote:
> 
> > > > Since the report ID is located within the data buffer, overwriting it
> > > > would mean that any subsequent matching could cause a disparity in
> > > > assumed allocated buffer size.  This in turn could trivially result in
> > > > an out-of-bounds condition.  To mitigate this issue, let's refuse to
> > > > overwrite a given report's data area if the ID in get_report_reply
> > > > doesn't match.
> > > 
> > > That's a strong assumption and a breakage of the userspace FWIW. The CI
> > > is now full of errors:
> > > https://gitlab.freedesktop.org/bentiss/hid/-/commits/for-7.0/upstream-fixes
> > > 
> > > It is pretty common to allocate the buffer and not initialize it in
> > > get_report operations.
> > > 
> > > It was a bad API choice to have rnum and data[0] for all HID requests
> > > (internally, externally), but we should stick to it. The CI breakage in
> > > itself is not a big issue TBH, but if it breaks here, it will probably
> > > break existing users.
> > 
> > Lee,
> > 
> > was this found via code inspection, fuzzing, or is there some real-world 
> > report behind it?
> 
> For now I've dropped this from for-7.0/upstream-fixes until it's all 
> clarified.
> 
> Thanks,
> 

So I've debugged today the error I was seeing. First, my statement is
slightly exagerated, because we are talking here about a get_report
function, and Lee's patch checks for the return buffer, not the incoming
buffer.

So I had a small time where I was wondering if I was not wrong and
something was off in the test suite.

However, it seems the bug is caused by the PS3 emulation:
https://gitlab.freedesktop.org/libevdev/hid-tools/-/blob/master/hidtools/device/sony_gamepad.py?ref_type=heads#L256-257

During the initialization of the PS3 controller, hid-sony.c calls
several GET_REPORT on 0xF2 and 0xF5. Both of these feature reports are
hidden in the report descriptor (a few lines above in the
sony_gamepad.py file). However, the emulation returns `[0x01, 0x00,
0x18, 0x5E, 0x0F, 0x71, 0xA4, 0xBB]` when we request a 0xf5 report,
which seems to be bogus.

So I digged out the PS3 controller from a drawer, and looked at the
incoming data from it.

And it turns out that the controller reply that exact sequence when
requested about the 0xf5 feature.

So that means that the emulation is correct, and we can have devices
which report a different report number. Arguably this is wrong, but we
are in the peripheral world where every vendor does what it wants :(

Long story short: that patch is too intrusive as it makes assumption on
the behavior of the device. We need to understand where/if the bug was
spotted and fix the caller of hid_hw_raw_request, not the uhid
implementation.

Cheers,
Benjamin

Re: [PATCH 1/1] HID: uhid: Fix out-of-bounds write caused by raw events mismanagement

[Jiri Kosina]

On Tue, 24 Feb 2026, Benjamin Tissoires wrote:

> Long story short: that patch is too intrusive as it makes assumption on
> the behavior of the device. We need to understand where/if the bug was
> spotted and fix the caller of hid_hw_raw_request, not the uhid
> implementation.

Thanks a lot for the analysis, Benjamin!

I asked about that here:

	https://lore.kernel.org/all/172q4775-616s-p7s4-7n80-p8579n0r3516@xreary.bet/

So let's wait for Lee to clarify. Until that, the patch stays out of the 
branch.

Thanks,

-- 
Jiri Kosina
SUSE Labs

Re: [PATCH 1/1] HID: uhid: Fix out-of-bounds write caused by raw events mismanagement

[Lee Jones]

On Tue, 24 Feb 2026, Jiri Kosina wrote:

> On Tue, 24 Feb 2026, Benjamin Tissoires wrote:
> 
> > Long story short: that patch is too intrusive as it makes assumption on
> > the behavior of the device. We need to understand where/if the bug was
> > spotted and fix the caller of hid_hw_raw_request, not the uhid
> > implementation.
> 
> Thanks a lot for the analysis, Benjamin!
> 
> I asked about that here:
> 
> 	https://lore.kernel.org/all/172q4775-616s-p7s4-7n80-p8579n0r3516@xreary.bet/
> 
> So let's wait for Lee to clarify. Until that, the patch stays out of the 
> branch.

Thanks to both of you for looking into this.  I appreciate your efforts.

This is very much real world.

Is there a way to add an errata for the PS3 controller?

-- 
Lee Jones [李琼斯]

Re: [PATCH 1/1] HID: uhid: Fix out-of-bounds write caused by raw events mismanagement

[Benjamin Tissoires]

On Feb 26 2026, Lee Jones wrote:
> On Tue, 24 Feb 2026, Jiri Kosina wrote:
> 
> > On Tue, 24 Feb 2026, Benjamin Tissoires wrote:
> > 
> > > Long story short: that patch is too intrusive as it makes assumption on
> > > the behavior of the device. We need to understand where/if the bug was
> > > spotted and fix the caller of hid_hw_raw_request, not the uhid
> > > implementation.
> > 
> > Thanks a lot for the analysis, Benjamin!
> > 
> > I asked about that here:
> > 
> > 	https://lore.kernel.org/all/172q4775-616s-p7s4-7n80-p8579n0r3516@xreary.bet/
> > 
> > So let's wait for Lee to clarify. Until that, the patch stays out of the 
> > branch.
> 
> Thanks to both of you for looking into this.  I appreciate your efforts.
> 
> This is very much real world.
> 
> Is there a way to add an errata for the PS3 controller?
> 

Unfortunatelly no. uhid merely emulates what a device can do, and HID is
a convention. So if we were to have a special case to PS3 controllers,
we would then start having to maintain an endless list of quirks when
the issue is *not* in uhid, but in the processing of the device after
(maybe in hid-core?).

Cheers,
Benjamin

Re: [PATCH 1/1] HID: uhid: Fix out-of-bounds write caused by raw events mismanagement

[Lee Jones]

On Thu, 26 Feb 2026, Benjamin Tissoires wrote:

> On Feb 26 2026, Lee Jones wrote:
> > On Tue, 24 Feb 2026, Jiri Kosina wrote:
> > 
> > > On Tue, 24 Feb 2026, Benjamin Tissoires wrote:
> > > 
> > > > Long story short: that patch is too intrusive as it makes assumption on
> > > > the behavior of the device. We need to understand where/if the bug was
> > > > spotted and fix the caller of hid_hw_raw_request, not the uhid
> > > > implementation.
> > > 
> > > Thanks a lot for the analysis, Benjamin!
> > > 
> > > I asked about that here:
> > > 
> > > 	https://lore.kernel.org/all/172q4775-616s-p7s4-7n80-p8579n0r3516@xreary.bet/
> > > 
> > > So let's wait for Lee to clarify. Until that, the patch stays out of the 
> > > branch.
> > 
> > Thanks to both of you for looking into this.  I appreciate your efforts.
> > 
> > This is very much real world.
> > 
> > Is there a way to add an errata for the PS3 controller?
> > 
> 
> Unfortunatelly no. uhid merely emulates what a device can do, and HID is
> a convention. So if we were to have a special case to PS3 controllers,
> we would then start having to maintain an endless list of quirks when
> the issue is *not* in uhid, but in the processing of the device after
> (maybe in hid-core?).

Actually I think the issue is in UHID.  At least the way I read it.

Are there legitimate use-cases for devices overwriting the Report ID
contained in the first index of the data buffer?  From my very limited
knowledge of the subsystem, this sounds like an oversight.

-- 
Lee Jones [李琼斯]

Re: [PATCH 1/1] HID: uhid: Fix out-of-bounds write caused by raw events mismanagement

[Benjamin Tissoires]

On Feb 26 2026, Lee Jones wrote:
> On Thu, 26 Feb 2026, Benjamin Tissoires wrote:
> 
> > On Feb 26 2026, Lee Jones wrote:
> > > On Tue, 24 Feb 2026, Jiri Kosina wrote:
> > > 
> > > > On Tue, 24 Feb 2026, Benjamin Tissoires wrote:
> > > > 
> > > > > Long story short: that patch is too intrusive as it makes assumption on
> > > > > the behavior of the device. We need to understand where/if the bug was
> > > > > spotted and fix the caller of hid_hw_raw_request, not the uhid
> > > > > implementation.
> > > > 
> > > > Thanks a lot for the analysis, Benjamin!
> > > > 
> > > > I asked about that here:
> > > > 
> > > > 	https://lore.kernel.org/all/172q4775-616s-p7s4-7n80-p8579n0r3516@xreary.bet/
> > > > 
> > > > So let's wait for Lee to clarify. Until that, the patch stays out of the 
> > > > branch.
> > > 
> > > Thanks to both of you for looking into this.  I appreciate your efforts.
> > > 
> > > This is very much real world.
> > > 
> > > Is there a way to add an errata for the PS3 controller?
> > > 
> > 
> > Unfortunatelly no. uhid merely emulates what a device can do, and HID is
> > a convention. So if we were to have a special case to PS3 controllers,
> > we would then start having to maintain an endless list of quirks when
> > the issue is *not* in uhid, but in the processing of the device after
> > (maybe in hid-core?).
> 
> Actually I think the issue is in UHID.  At least the way I read it.

And I disagree :)

> 
> Are there legitimate use-cases for devices overwriting the Report ID
> contained in the first index of the data buffer?  From my very limited
> knowledge of the subsystem, this sounds like an oversight.
> 

Legitimate, probably no, but we are talking about physical devices
here. uhid is a mere replacement of a transport layer, and there is
nothing that prevents a device to reply with a buffer starting with 1
when requested about feature 2 (because it's firmware and they just
don't care).

This happens a lot with proprietary features on devices, when there is
no spec, so ODM provide their own driver and they can do whatever they
want.

If uhid or any transport layer solely takes the decision that a reply to
a request is wrong, we have no chance of fixing it after the fact. This
is what happens with the PS3 controller: an undocumented feature is
used, but that's what the Playstation does, so we need to tag along.

I hope it makes more sense now.

FTR, Lee shared the logs of the issue privately, and I already told him
where we should fix the issue.

Cheers,
Benjamin

Re: [PATCH 1/1] HID: uhid: Fix out-of-bounds write caused by raw events mismanagement

[Lee Jones]

On Thu, 26 Feb 2026, Benjamin Tissoires wrote:

> On Feb 26 2026, Lee Jones wrote:
> > On Thu, 26 Feb 2026, Benjamin Tissoires wrote:
> > 
> > > On Feb 26 2026, Lee Jones wrote:
> > > > On Tue, 24 Feb 2026, Jiri Kosina wrote:
> > > > 
> > > > > On Tue, 24 Feb 2026, Benjamin Tissoires wrote:
> > > > > 
> > > > > > Long story short: that patch is too intrusive as it makes assumption on
> > > > > > the behavior of the device. We need to understand where/if the bug was
> > > > > > spotted and fix the caller of hid_hw_raw_request, not the uhid
> > > > > > implementation.
> > > > > 
> > > > > Thanks a lot for the analysis, Benjamin!
> > > > > 
> > > > > I asked about that here:
> > > > > 
> > > > > 	https://lore.kernel.org/all/172q4775-616s-p7s4-7n80-p8579n0r3516@xreary.bet/
> > > > > 
> > > > > So let's wait for Lee to clarify. Until that, the patch stays out of the 
> > > > > branch.
> > > > 
> > > > Thanks to both of you for looking into this.  I appreciate your efforts.
> > > > 
> > > > This is very much real world.
> > > > 
> > > > Is there a way to add an errata for the PS3 controller?
> > > > 
> > > 
> > > Unfortunatelly no. uhid merely emulates what a device can do, and HID is
> > > a convention. So if we were to have a special case to PS3 controllers,
> > > we would then start having to maintain an endless list of quirks when
> > > the issue is *not* in uhid, but in the processing of the device after
> > > (maybe in hid-core?).
> > 
> > Actually I think the issue is in UHID.  At least the way I read it.
> 
> And I disagree :)
> 
> > 
> > Are there legitimate use-cases for devices overwriting the Report ID
> > contained in the first index of the data buffer?  From my very limited
> > knowledge of the subsystem, this sounds like an oversight.
> > 
> 
> Legitimate, probably no, but we are talking about physical devices
> here. uhid is a mere replacement of a transport layer, and there is
> nothing that prevents a device to reply with a buffer starting with 1
> when requested about feature 2 (because it's firmware and they just
> don't care).
> 
> This happens a lot with proprietary features on devices, when there is
> no spec, so ODM provide their own driver and they can do whatever they
> want.
> 
> If uhid or any transport layer solely takes the decision that a reply to
> a request is wrong, we have no chance of fixing it after the fact. This
> is what happens with the PS3 controller: an undocumented feature is
> used, but that's what the Playstation does, so we need to tag along.
> 
> I hope it makes more sense now.
> 
> FTR, Lee shared the logs of the issue privately, and I already told him
> where we should fix the issue.

Thanks for all the help and the insight.

I will follow-up with the suggested fixes soon.

-- 
Lee Jones [李琼斯]