From: Wen Gong <[email protected]>
commit 079a108feba474b4b32bd3471db03e11f2f83b81 upstream.
When the discard flag is set by the firmware for an MPDU, it should be
dropped. This allows a mitigation for CVE-2020-24588 to be implemented
in the firmware.
Tested-on: QCA6174 hw3.2 SDIO WLAN.RMH.4.4.1-00049
Cc: [email protected]
Signed-off-by: Wen Gong <[email protected]>
Signed-off-by: Jouni Malinen <[email protected]>
Link: https://lore.kernel.org/r/20210511200110.11968c725b5c.Idd166365ebea2771c0c0a38c78b5060750f90e17@changeid
Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/net/wireless/ath/ath10k/htt_rx.c | 5 +++++
drivers/net/wireless/ath/ath10k/rx_desc.h | 14 +++++++++++++-
2 files changed, 18 insertions(+), 1 deletion(-)
--- a/drivers/net/wireless/ath/ath10k/htt_rx.c
+++ b/drivers/net/wireless/ath/ath10k/htt_rx.c
@@ -2312,6 +2312,11 @@ static bool ath10k_htt_rx_proc_rx_ind_hl
fw_desc = &rx->fw_desc;
rx_desc_len = fw_desc->len;
+ if (fw_desc->u.bits.discard) {
+ ath10k_dbg(ar, ATH10K_DBG_HTT, "htt discard mpdu\n");
+ goto err;
+ }
+
/* I have not yet seen any case where num_mpdu_ranges > 1.
* qcacld does not seem handle that case either, so we introduce the
* same limitiation here as well.
--- a/drivers/net/wireless/ath/ath10k/rx_desc.h
+++ b/drivers/net/wireless/ath/ath10k/rx_desc.h
@@ -1282,7 +1282,19 @@ struct fw_rx_desc_base {
#define FW_RX_DESC_UDP (1 << 6)
struct fw_rx_desc_hl {
- u8 info0;
+ union {
+ struct {
+ u8 discard:1,
+ forward:1,
+ any_err:1,
+ dup_err:1,
+ reserved:1,
+ inspect:1,
+ extension:2;
+ } bits;
+ u8 info0;
+ } u;
+
u8 version;
u8 len;
u8 flags;
Hi!
> commit 079a108feba474b4b32bd3471db03e11f2f83b81 upstream.
>
> When the discard flag is set by the firmware for an MPDU, it should be
> dropped. This allows a mitigation for CVE-2020-24588 to be implemented
> in the firmware.
>
> Tested-on: QCA6174 hw3.2 SDIO WLAN.RMH.4.4.1-00049
This introduces bitfields for communication with firmware.
> +++ b/drivers/net/wireless/ath/ath10k/rx_desc.h
> @@ -1282,7 +1282,19 @@ struct fw_rx_desc_base {
> #define FW_RX_DESC_UDP (1 << 6)
>
> struct fw_rx_desc_hl {
> - u8 info0;
> + union {
> + struct {
> + u8 discard:1,
> + forward:1,
> + any_err:1,
> + dup_err:1,
> + reserved:1,
> + inspect:1,
> + extension:2;
> + } bits;
> + u8 info0;
> + } u;
> +
That is a) quite unusual (see the define just above) and b) very
fragile AFAICT. Compilers on LE and BE machines behave differently,
for example. Should it use usual bit manipulation functions?
Best regards,
Pavel
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
A follow-up patch would, I think, be needed to fix this for big endian
architectures.