From: Fedor Pchelkin <pchelkin@ispras.ru>
To: "Toke Høiland-Jørgensen" <toke@toke.dk>
Cc: Kalle Valo <kvalo@kernel.org>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Senthil Balasubramanian <senthilkumar@atheros.com>,
"John W. Linville" <linville@tuxdriver.com>,
Vasanthakumar Thiagarajan <vasanth@atheros.com>,
Sujith <Sujith.Manoharan@atheros.com>,
linux-wireless@vger.kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org,
Alexey Khoroshilov <khoroshilov@ispras.ru>,
lvc-project@linuxtesting.org
Subject: Re: [PATCH 0/3] wifi: ath9k: deal with uninit memory
Date: Wed, 15 Mar 2023 23:47:20 +0300 [thread overview]
Message-ID: <20230315204720.xtqik56r7ddbynho@fpc> (raw)
In-Reply-To: <20230315202112.163012-1-pchelkin@ispras.ru>
On Wed, Mar 15, 2023 at 11:21:09PM +0300, Fedor Pchelkin wrote:
> Syzkaller reports two cases ([1] and [2]) of uninitialized memory referencing in ath9k
> wmi functions. The following patch series is intended to fix them and related issues.
>
> [1] https://syzkaller.appspot.com/bug?id=51d401326d8ee41859d68997acdd6f3b1b39f186
> [2] https://syzkaller.appspot.com/bug?id=fc54e8d79f5d5082c7867259d71b4e6618b69d25
During the patch development I observed that the return value of REG_READ
(ath9k_regread), REG_READ_MULTI (ath9k_multi_regread) and similar macros
is not checked in most places inside ath9k where they are called. That may
also potentially lead to incorrect behaviour. I wonder if it actually
poses a problem as the current implementation has been for a long time and
perhaps somebody has already addressed this.
In more details:
-- ath9k_regread returns -1 on error, and probably this is a predefined
error state and doesn't need additional check. But, overall, it seems
strange to me that the return value is not checked in places where it
is used later (for example, in ath9k_reg_rmw or
ath9k_hw_ani_read_counters).
-- ath9k_multi_regread fills 'val' buffer with undefined values on error
case, that should definitely be fixed with initializing the local
buffer to zero, I think.
Could you please say your opinion on this issue?
prev parent reply other threads:[~2023-03-15 20:47 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-15 20:21 [PATCH 0/3] wifi: ath9k: deal with uninit memory Fedor Pchelkin
2023-03-15 20:21 ` [PATCH 1/3] wifi: ath9k: avoid referencing uninit memory in ath9k_wmi_ctrl_rx Fedor Pchelkin
2023-03-17 5:26 ` Kalle Valo
2023-03-18 20:25 ` Fedor Pchelkin
2023-04-24 18:23 ` Fedor Pchelkin
2023-04-24 18:33 ` [PATCH v2] " Fedor Pchelkin
2023-04-25 11:14 ` Toke Høiland-Jørgensen
2023-04-28 16:52 ` Kalle Valo
2023-03-15 20:21 ` [PATCH 2/3] wifi: ath9k: fix races between ath9k_wmi_cmd and ath9k_wmi_ctrl_rx Fedor Pchelkin
2023-04-24 19:11 ` Fedor Pchelkin
2023-04-24 19:18 ` [PATCH v2] " Fedor Pchelkin
[not found] ` <20230425033832.2041-1-hdanton@sina.com>
2023-04-25 7:54 ` Fedor Pchelkin
2023-04-25 19:26 ` [PATCH v3 1/2] " Fedor Pchelkin
2023-04-25 19:26 ` [PATCH v3 2/2] wifi: ath9k: protect WMI command response buffer replacement with a lock Fedor Pchelkin
2023-08-08 14:07 ` Toke Høiland-Jørgensen
[not found] ` <20230425230708.2132-1-hdanton@sina.com>
2023-04-26 19:02 ` [PATCH v3 1/2] wifi: ath9k: fix races between ath9k_wmi_cmd and ath9k_wmi_ctrl_rx Fedor Pchelkin
2023-05-15 12:06 ` Toke Høiland-Jørgensen
2023-05-18 10:24 ` Hillf Danton
2023-05-18 15:44 ` Fedor Pchelkin
2023-08-08 14:06 ` Toke Høiland-Jørgensen
2023-08-22 13:35 ` Kalle Valo
2023-03-15 20:21 ` [PATCH 3/3] wifi: ath9k: fix ath9k_wmi_cmd return value when device is unplugged Fedor Pchelkin
2023-03-15 20:47 ` Fedor Pchelkin [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20230315204720.xtqik56r7ddbynho@fpc \
--to=pchelkin@ispras.ru \
--cc=Sujith.Manoharan@atheros.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=khoroshilov@ispras.ru \
--cc=kuba@kernel.org \
--cc=kvalo@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=linville@tuxdriver.com \
--cc=lvc-project@linuxtesting.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=senthilkumar@atheros.com \
--cc=toke@toke.dk \
--cc=vasanth@atheros.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).