Received-SPF: pass (google.com: domain of linux-wireless+bounces-5878-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) client-ip=147.75.48.161;
From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= <toke@toke.dk>
To: Chien Wong <m@xv97.com>, Kalle Valo <kvalo@kernel.org>
Cc: linux-wireless@vger.kernel.org
Subject: Re: [PATCH] wifi: ath9k_htc: drop too long USB messages
In-Reply-To: <20240404150110.13816-1-m@xv97.com>
References: <20240404150110.13816-1-m@xv97.com>
Date: Thu, 04 Apr 2024 20:40:37 +0200
Message-ID: <87edblkm3e.fsf@toke.dk>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain

Chien Wong <m@xv97.com> writes:

> Currently, the length of USB messages sent from host to Wi-Fi dongle is
> not checked. Without the check, we could crash the firmware.
>
> The length limits are determined by _HIFusb_get_max_msg_len_patch()
> in the firmware code, located in k2_HIF_usb_patch.c and HIF_usb_patch.c
> of the open-ath9k-htc-firmware project. The limits are 512 and 1600
> bytes for regout and Wi-Fi TX messages respectively.
> I'm not sure if the firmware crash is due to buffer overflow if RXing
> too long USB messages but the length limit is clear and verified.
> Somebody knowing hardware internals could help.
>
> We should try our best not to crash the firmware. Note that setting the
> MTU limit may not work: monitor interfaces will ignore the limit.
> So we just drop too long messages and give warning on such events.

Silently dropping packets seems like a bad idea. If needed, we can have
a length check with a warning *in addition* to the MTU limit, but we
should definitely disallow the MTU change first...

-Toke