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

[Jeff Johnson]

On 4/17/2026 1:24 AM, Loic Poulain wrote:
> 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.

Sounds reasonable to me. We do actually take this approach with the Qualcomm
downstream Android driver.

So if you ack these I'll take them :)

/jeff

/jeff