Re: [cip-dev] [backport 4.4] mac80211: Fix TKIP replay protection immediately after key setup

From: Ben Hutchings <ben.hutchings@codethink.co.uk>
To: Pavel Machek <pavel@ucw.cz>,
	cip-dev@lists.cip-project.org,  Chris.Paterson2@renesas.com
Subject: Re: [cip-dev] [backport 4.4] mac80211: Fix TKIP replay protection immediately after key setup
Date: Fri, 20 Mar 2020 21:41:08 +0000	[thread overview]
Message-ID: <5f17418f68274169e0e08af7b02529912358dc54.camel@codethink.co.uk> (raw)
In-Reply-To: <20200215195407.GA10344@amd>

On Sat, 2020-02-15 at 20:54 +0100, Pavel Machek wrote:
> Hi!
> 
> So... this is first backport patch. I'll need to reformat a changelog.
> 
> The patch should pass our tests on gitlab, but I somehow don't think
> those tests involved wifi at all... At least it compiles.
> 
> Can someone test it easily? Should I just submit it to stable
> explaining I did not test it?

That's what I would do.

> Do you have other patches that should go to 4.4/4.19?
> 
> Best regards,
> 								Pavel
> 
> commit 911e21ed055f6700fa80d0f7a818ba223999bb2a
> Author: Pavel Machek <pavel@ucw.cz>
> Date:   Thu Feb 13 22:56:46 2020 +0100
> 
>     Author: Jouni Malinen <j@w1.fi>
>     Date:   Tue Jan 7 17:35:45 2020 +0200
>
>     commit fa73f24d1b119b85b32cd8f217a73d108888097e

This reference is wrong; the upstream commit is
6f601265215a421f425ba3a4850a35861d024643.  Also the usual format for
this reference has "upstream." after the commit hash.

[...]
> --- a/net/mac80211/tkip.c
> +++ b/net/mac80211/tkip.c
> @@ -265,10 +265,21 @@ int ieee80211_tkip_decrypt_data(struct crypto_cipher *tfm,
>  	if ((keyid >> 6) != key->conf.keyidx)
>  		return TKIP_DECRYPT_INVALID_KEYIDX;
>  
> -	if (key->u.tkip.rx[queue].state != TKIP_STATE_NOT_INIT &&
> -	    (iv32 < key->u.tkip.rx[queue].iv32 ||
> -	     (iv32 == key->u.tkip.rx[queue].iv32 &&
> -	      iv16 <= key->u.tkip.rx[queue].iv16)))
> +	/* Reject replays if the received TSC is smaller than or equal to the
> +	 * last received value in a valid message, but with an exception for
> +	 * the case where a new key has been set and no valid frame using that
> +	 * key has yet received and the local RSC was initialized to 0. This
> +	 * exception allows the very first frame sent by the transmitter to be
> +	 * accepted even if that transmitter were to use TSC 0 (IEEE 802.11
> +	 * described TSC to be initialized to 1 whenever a new key is taken into
> +	 * use).
> +	 */
> +	if (iv32 < key->u.tkip.rx[queue].iv32 ||
> +	    (iv32 == key->u.tkip.rx[queue].iv32 &&
> +	     (iv16 < key->u.tkip.rx[queue].iv16 ||
> +	      (iv16 == key->u.tkip.rx[queue].iv16 &&
> +	       (key->u.tkip.rx[queue].iv32 || key->u.tkip.rx[queue].iv16 ||
> +		key->u.tkip.rx[queue].state != TKIP_STATE_NOT_INIT)))))
>  		return TKIP_DECRYPT_REPLAY;
>  
>  	if (only_iv) {

This backport makes sense to me.  Please can you send it to the stable
list, with the fixed commit message?

Ben.

-- 
Ben Hutchings, Software Developer                         Codethink Ltd
https://www.codethink.co.uk/                 Dale House, 35 Dale Street
                                     Manchester, M1 2HF, United Kingdom

_______________________________________________
cip-dev mailing list
cip-dev@lists.cip-project.org
https://lists.cip-project.org/mailman/listinfo/cip-dev