From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id DF397C25B0E for ; Tue, 16 Aug 2022 13:58:29 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232329AbiHPN62 (ORCPT ); Tue, 16 Aug 2022 09:58:28 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41096 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230096AbiHPN60 (ORCPT ); Tue, 16 Aug 2022 09:58:26 -0400 Received: from mail.toke.dk (mail.toke.dk [IPv6:2a0c:4d80:42:2001::664]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id ECBD95E678 for ; Tue, 16 Aug 2022 06:58:22 -0700 (PDT) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1660658300; bh=4MaAOuGtfGy51Q8bsqlh+zi5ulOMA2bxgVNmWeVp5QU=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=Z3Us0SnIY6tokmXmLJmroHWVNKmqiKeT5UUdowqlSbi9u8uamLKqLJzk73V6hIyLf LPV0JhDjILr2cyU34ZXI/HPh4VpokTB9Hi7JGLggK8cLCxHcTK7GFUYYFK7ILYDtzN q4bRSesMQd5it2YHRNh7PIo1d8LjTY4R/CBiaUZjSd5g1ki0vY8axt8Fz7wboqIVzA mWJgFI0Ptw/gGNi5B1tef9Z9jzWX/zZDdFdOIRgco9fixkoKLGafDJeEs2iY2tkgE9 a0Ibbe7myIKXDKmdT4XFMUVvyP905K67WQTvkJtoMRkpS17+V0eJu6axXP1T36lYGM l9Yl20fdJtA4Q== To: Tetsuo Handa , Kalle Valo Cc: linux-wireless Subject: Re: [PATCH] ath9k: avoid uninit memory read in ath9k_htc_rx_msg() In-Reply-To: References: <000000000000c98a7f05ac744f53@google.com> Date: Tue, 16 Aug 2022 15:58:18 +0200 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87edxgwarp.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain Precedence: bulk List-ID: X-Mailing-List: linux-wireless@vger.kernel.org Tetsuo Handa writes: > On 2022/07/30 21:13, Tetsuo Handa wrote: >> We have two choices. One is to workaround by adding __GFP_ZERO so that >> ath9k_htc_rx_msg() sees 0 if pkt_len is invalid. The other is to let >> ath9k_htc_rx_msg() validate pkt_len before accessing. > > Which choice do we want to go? I prefer the explicit length checks as you do in your patch. Could you please resend with an updated commit message making it explicit that this is the choice this patch is going with? -Toke