Re: [PATCH] wifi: carl9170: fix stack-out-of-bounds in carl9170_cmd_callback

[Jeff Johnson]

On 5/1/2026 3:17 AM, Christian Lamparter wrote:
> Hi,
> 
> On 4/24/26 5:17 AM, Deepanshu Kartikey wrote:
>> carl9170_cmd_callback() does not return after calling
>> carl9170_restart() when an invalid command response is detected.
>> This causes a fall-through into the memcpy block below, where
>> ar->readbuf is written with a device-controlled length (len - 4)
>> instead of the expected ar->readlen bytes.
>>
>> A malicious or fuzzing USB device can send an oversized response
>> (e.g. 60 bytes) causing a stack-out-of-bounds write into ar->readbuf,
>> as detected by KASAN.
>>
>> Fix this by adding a return after carl9170_restart() to match the
>> original intent stated in the comment ("Do not complete"). Also cap
>> the memcpy with min_t() as defense-in-depth to prevent overflow even
>> if the control flow changes in future.
>>
>> The bug has been present since the initial driver submission in 2010.
> 
> 
> I've seen this before in a mail from Tristan Madani (CC'd) on the 13th of April 2026.
> Unfortunately, he didn't post this to the linux-wireless mailing-list. Instead
> he went for the Security Officers <security@xxxxxxxxxx> , so I can't provide any link to it.
> That said, he since changed it because of the notes I had about the driver actually want to process
> further so only the memcpy that caused the overflow was modified with the same
> "min_t(u32, len - 4, ar->readlen)" instead of "len -4" as the length:
> "[PATCH v3 1/3] wifi: carl9170: bound memcpy length in cmd callback to prevent OOB read"
> 
> https://lore.kernel.org/linux-wireless/20260421134929.325662-2-tristmd@xxxxxxxxx/
> 
> So, who should get the credit? Maybe another person will post a patch soon too? Who knows.

My plan is to take Tristan's series once I get ACKs.
Any other contributions that conflict with his will be dropped.

/jeff