All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kalle Valo <kvalo@codeaurora.org>
To: Takashi Iwai <tiwai@suse.de>
Cc: Ping-Ke Shih <pkshih@realtek.com>,
	linux-wireless@vger.kernel.org, linux-kernel@vger.kernel.org,
	Larry Finger <Larry.Finger@gmail.com>
Subject: Re: [PATCH] rtw89: Fix crash by loading compressed firmware file
Date: Fri, 05 Nov 2021 11:03:55 +0200	[thread overview]
Message-ID: <87v917q8hw.fsf@codeaurora.org> (raw)
In-Reply-To: <s5hh7crgflg.wl-tiwai@suse.de> (Takashi Iwai's message of "Fri, 05 Nov 2021 09:40:43 +0100")

Takashi Iwai <tiwai@suse.de> writes:

> On Fri, 05 Nov 2021 09:25:13 +0100,
> Kalle Valo wrote:
>> 
>> Takashi Iwai <tiwai@suse.de> writes:
>> 
>> > On Fri, 05 Nov 2021 08:17:25 +0100,
>> > Takashi Iwai wrote:
>> >> 
>> >> When a firmware is loaded in the compressed format or via user-mode
>> >> helper, it's mapped in read-only, and the rtw89 driver crashes at
>> >> rtw89_fw_download() when it tries to modify some data.
>> >> 
>> >> This patch is an attemp to avoid the crash by re-allocating the data
>> >> via vmalloc() for the data modification.
>> >
>> > Alternatively, we may drop the code that modifies the loaded firmware
>> > data?  At least SET_FW_HDR_PART_SIZE() in rtw89_fw_hdr_parser() looks
>> > writing it, and I have no idea why this overwrite is needed.
>> 
>> Strange, isn't the firmware data marked as const just to avoid this kind
>> of problem? Does rtw89 have wrong casts somewhere which removes the
>> const?
>
> Yes.  SET_FW_HDR_PART_SIZE() does the cast, dropping the const.

Oh man, all of GET and SET macros in fw.h have those casts:

#define GET_FW_HDR_MAJOR_VERSION(fwhdr)	\
	le32_get_bits(*((__le32 *)(fwhdr) + 1), GENMASK(7, 0))
#define GET_FW_HDR_MINOR_VERSION(fwhdr)	\
	le32_get_bits(*((__le32 *)(fwhdr) + 1), GENMASK(15, 8))
#define GET_FW_HDR_SUBVERSION(fwhdr)	\
	le32_get_bits(*((__le32 *)(fwhdr) + 1), GENMASK(23, 16))

I don't know how I missed those during my review :( But this is exactly
why I prefer having a proper struct for commands and events, instead of
u8 buf used with these macros.

-- 
https://patchwork.kernel.org/project/linux-wireless/list/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

  reply	other threads:[~2021-11-05  9:04 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-05  7:17 [PATCH] rtw89: Fix crash by loading compressed firmware file Takashi Iwai
2021-11-05  7:21 ` Takashi Iwai
2021-11-05  8:25   ` Kalle Valo
2021-11-05  8:40     ` Takashi Iwai
2021-11-05  9:03       ` Kalle Valo [this message]
2021-11-05 14:28         ` Pkshih
2021-11-05 15:07           ` Takashi Iwai
2021-11-11  2:28             ` Pkshih
2021-11-11  6:31               ` Takashi Iwai
2021-11-11 13:34                 ` Takashi Iwai
2021-11-12  0:38                   ` Pkshih

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=87v917q8hw.fsf@codeaurora.org \
    --to=kvalo@codeaurora.org \
    --cc=Larry.Finger@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=pkshih@realtek.com \
    --cc=tiwai@suse.de \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.