On 3/21/23 06:28, Lorenzo Bianconi wrote:
On 3/21/23 02:58, Lorenzo Bianconi wrote:
From: Ben Greear <greearb@xxxxxxxxxxxxxxx>
Stop referencing 'features' memory after release_firmware is called.
Fixes this crash:
RIP: 0010:mt7921_check_offload_capability+0x17d
mt7921_pci_probe+0xca/0x4b0
...
Signed-off-by: Ben Greear <greearb@xxxxxxxxxxxxxxx>
---
drivers/net/wireless/mediatek/mt76/mt7921/init.c | 11 +++++++++--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/mediatek/mt76/mt7921/init.c b/drivers/net/wireless/mediatek/mt76/mt7921/init.c
index 38d6563cb12f..d2bb8d02ce0a 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7921/init.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7921/init.c
@@ -165,12 +165,12 @@ mt7921_mac_init_band(struct mt7921_dev *dev, u8 band)
u8 mt7921_check_offload_capability(struct device *dev, const char *fw_wm)
{
- struct mt7921_fw_features *features = NULL;
const struct mt76_connac2_fw_trailer *hdr;
struct mt7921_realease_info *rel_info;
const struct firmware *fw;
int ret, i, offset = 0;
const u8 *data, *end;
+ u8 offload_caps = 0;
ret = request_firmware(&fw, fw_wm, dev);
if (ret)
@@ -197,12 +197,19 @@ u8 mt7921_check_offload_capability(struct device *dev, const char *fw_wm)
data += sizeof(*rel_info);
end = data + le16_to_cpu(rel_info->len);
+ /* TODO: This needs better sanity checking I think.
+ * Likely a corrupted firmware with bad rel_info->len, for instance,
+ * would blow this up.
+ */
can you please repost dropping this comment?
Why? Looks to me like this portion of mtk driver logic assumes firmware is
never corrupted on accident or on purpose. It should be fixed at some point.
even if this is a theoretical issue, this does not seem the right way to track
it and it is not related to this patch.
There is no better way I know to track such problems, it is not like random OSS developers will
read kernel bugzilla for this sort of thing, and email bug report about it will be buried in days
and never seen again.
And it is related to crazy memory corruption bugs since a corrupted firmware could cause similar
memory corruption. So next time someone is working on this code, maybe they will see the
comment and code it more defensively.
Anyway, if you insist, I can re-spin the patch against 6.2 and repost. I also hear that it will not
apply to 6.3, but I'm not yet working on 6.3.
Thanks,
Ben
--
Ben Greear <greearb@xxxxxxxxxxxxxxx>
Candela Technologies Inc http://www.candelatech.com
