[ 055/108] iwlegacy: dont mess up the SCD when removing a key

From: Ben Hutchings
Date: Sun Jul 22 2012 - 21:52:10 EST

3.2-stable review patch. If anyone has any objections, please let me know.


From: Emmanuel Grumbach <emmanuel.grumbach@xxxxxxxxx>

commit b48d96652626b315229b1b82c6270eead6a77a6d upstream.

When we remove a key, we put a key index which was supposed
to tell the fw that we are actually removing the key. But
instead the fw took that index as a valid index and messed
up the SRAM of the device.

This memory corruption on the device mangled the data of
the SCD. The impact on the user is that SCD queue 2 got
stuck after having removed keys.

Reported-by: Paul Bolle <pebolle@xxxxxxxxxx>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@xxxxxxxxx>
Signed-off-by: Stanislaw Gruszka <sgruszka@xxxxxxxxxx>
Signed-off-by: John W. Linville <linville@xxxxxxxxxxxxx>
[bwh: Backported to 3.2: adjust filename, context and variable name]
Signed-off-by: Ben Hutchings <ben@xxxxxxxxxxxxxxx>
drivers/net/wireless/iwlegacy/4965-mac.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

--- a/drivers/net/wireless/iwlegacy/iwl-4965-sta.c
+++ b/drivers/net/wireless/iwlegacy/iwl-4965-sta.c
@@ -466,7 +466,7 @@ int iwl4965_remove_dynamic_key(struct iw
return 0;

- if (priv->stations[sta_id].sta.key.key_offset == WEP_INVALID_OFFSET) {
+ if (priv->stations[sta_id].sta.key.key_flags & STA_KEY_FLG_INVALID) {
IWL_WARN(priv, "Removing wrong key %d 0x%x\n",
keyconf->keyidx, key_flags);
spin_unlock_irqrestore(&priv->sta_lock, flags);
@@ -483,7 +483,7 @@ int iwl4965_remove_dynamic_key(struct iw
sizeof(struct iwl4965_keyinfo));
priv->stations[sta_id].sta.key.key_flags =
- priv->stations[sta_id].sta.key.key_offset = WEP_INVALID_OFFSET;
+ priv->stations[sta_id].sta.key.key_offset = keyconf->hw_key_idx;
priv->stations[sta_id].sta.sta.modify_mask = STA_MODIFY_KEY_MASK;
priv->stations[sta_id].sta.mode = STA_CONTROL_MODIFY_MSK;

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/