[PATCH v2 0/3] wifi: wcn36xx: fix OOB reads and heap overflow from firmware responses

[Loic Poulain]

Hi Jeff,

On Fri, Apr 17, 2026 at 2:01 AM Jeff Johnson
<jeff.johnson at oss.qualcomm.com> wrote:
>
> On 4/16/2026 11:39 AM, Johannes Berg wrote:
> > On Thu, 2026-04-16 at 09:25 -0700, Jeff Johnson wrote:
> >> On 4/15/2026 3:37 PM, Tristan Madani wrote:
> >>> From: Tristan Madani <tristan at talencesecurity.com>
> >>>
> >>> Hi Loic,
> >>>
> >>> Note: this is a v2 resubmission. The original was sent via Gmail which
> >>> caused HTML rendering issues. This version uses git send-email for
> >>> proper plain-text formatting.
> >>>
> >>> Three issues in wcn36xx HAL firmware response handling, including a heap
> >>> overflow in the main response dispatcher:
> >>>
> >>> Proposed fixes in the following patches.
> >>>
> >>> Thanks,
> >>> Tristan
> >>
> >> Are you able to cause these issues to occur?
> >> My expectation is that this is testing things that firmware will never do, and
> >> hence this adds code and processing with no actual benefit.
> >
> > We're not really supposed to completely trust firmware though, right? :)
>
> Like everything else in software there are tradeoffs. You have to mostly trust
> firmware since everything it it is doing is on behalf of the driver. So that
> is why I'm curious if these issues are actually exploitable, or if this is
> just preventative for the sake of being preventative.

I agree that some degree of trust in vendor firmware is unavoidable,
as its internal behavior cannot be fully controlled or inspected.
Nevertheless, the kernel and its drivers are expected to strictly
validate and constrain all interactions with firmware, so that any
faulty or compromised behavior is contained within its intended scope
(network/wireless).

So, it is the driver’s responsibility to control the firmware
interface and ensure that firmware misbehavior, whether deliberate or
the result of an exploited firmware bug, cannot lead to such kernel
memory corruption, which could otherwise be exploited well beyond the
driver’s original functional domain.

While this issue may be largely theoretical, it has now been reported
and a fix is available. In this context, addressing it seems to be the
responsible course of action.

With the increasing use of AI, we may indeed see more fixes proposed
for issues that are theoretical or unlikely to occur in practice. I
understand the concern about avoiding an influx of low‑value commits
and the need for some level of filtering. That said, in this particular case,
I believe the fix is legitimate.

Regards,
Loic