.../hid/intel-thc-hid/intel-quickspi/pci-quickspi.c | 9 +++++++-- .../intel-thc-hid/intel-quickspi/quickspi-protocol.c | 12 ++++++++++-- 2 files changed, 17 insertions(+), 4 deletions(-)
Two heap overflows on the QuickSPI receive path, both from a controller
that declares one length and sends another.
The first is the DMA landing buffer, sized from the device descriptor while
the THC DMA rounds its packet size up to 4K. The second is the GET REPORT
response, whose length is checked against what the DMA delivered and never
against report_buf. Each has a sibling in-tree that already gets it right,
named in the patch.
Neither was reproduced on hardware. Both turned up while working on
commit 035ec4a71cb8 ("HID: intel-thc-hid: intel-quickspi: bound GET_REPORT
response to the caller buffer"), which covers neither.
A fuller fix for the first would give thc_rxdma_read() a capacity argument,
but that changes a shared API and touches intel-quicki2c, so this keeps to
the driver.
HyeongJun An (2):
HID: intel-thc-hid: intel-quickspi: size the input buffer for the DMA
HID: intel-thc-hid: intel-quickspi: bound the GET REPORT response to
report_buf
.../hid/intel-thc-hid/intel-quickspi/pci-quickspi.c | 9 +++++++--
.../intel-thc-hid/intel-quickspi/quickspi-protocol.c | 12 ++++++++++--
2 files changed, 17 insertions(+), 4 deletions(-)
--
2.43.0
On Thu, 20 Aug 2026, HyeongJun An wrote:
> Two heap overflows on the QuickSPI receive path, both from a controller
> that declares one length and sends another.
>
> The first is the DMA landing buffer, sized from the device descriptor while
> the THC DMA rounds its packet size up to 4K. The second is the GET REPORT
> response, whose length is checked against what the DMA delivered and never
> against report_buf. Each has a sibling in-tree that already gets it right,
> named in the patch.
>
> Neither was reproduced on hardware. Both turned up while working on
> commit 035ec4a71cb8 ("HID: intel-thc-hid: intel-quickspi: bound GET_REPORT
> response to the caller buffer"), which covers neither.
>
> A fuller fix for the first would give thc_rxdma_read() a capacity argument,
> but that changes a shared API and touches intel-quicki2c, so this keeps to
> the driver.
>
> HyeongJun An (2):
> HID: intel-thc-hid: intel-quickspi: size the input buffer for the DMA
> HID: intel-thc-hid: intel-quickspi: bound the GET REPORT response to
> report_buf
Even Xu, can you please review this? Thanks,
--
Jiri Kosina
SUSE Labs
Sure, sorry for missing these.
Best Regards,
Even Xu
> -----Original Message-----
> From: Jiri Kosina <jikos@kernel.org>
> Sent: Saturday, September 12, 2026 12:09 AM
> To: HyeongJun An <sammiee5311@gmail.com>
> Cc: Xu, Even <even.xu@intel.com>; Sun, Xinpeng <xinpeng.sun@intel.com>;
> Benjamin Tissoires <bentiss@kernel.org>; linux-input@vger.kernel.org; linux-
> kernel@vger.kernel.org; stable@vger.kernel.org
> Subject: Re: [PATCH 0/2] HID: intel-thc-hid: intel-quickspi: two DMA buffer
> overflows
>
> On Thu, 20 Aug 2026, HyeongJun An wrote:
>
> > Two heap overflows on the QuickSPI receive path, both from a
> > controller that declares one length and sends another.
> >
> > The first is the DMA landing buffer, sized from the device descriptor
> > while the THC DMA rounds its packet size up to 4K. The second is the
> > GET REPORT response, whose length is checked against what the DMA
> > delivered and never against report_buf. Each has a sibling in-tree
> > that already gets it right, named in the patch.
> >
> > Neither was reproduced on hardware. Both turned up while working on
> > commit 035ec4a71cb8 ("HID: intel-thc-hid: intel-quickspi: bound
> > GET_REPORT response to the caller buffer"), which covers neither.
> >
> > A fuller fix for the first would give thc_rxdma_read() a capacity
> > argument, but that changes a shared API and touches intel-quicki2c, so
> > this keeps to the driver.
> >
> > HyeongJun An (2):
> > HID: intel-thc-hid: intel-quickspi: size the input buffer for the DMA
> > HID: intel-thc-hid: intel-quickspi: bound the GET REPORT response to
> > report_buf
>
> Even Xu, can you please review this? Thanks,
>
> --
> Jiri Kosina
> SUSE Labs
© 2016 - 2026 Red Hat, Inc.