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