)]}'
{
  "commit": "d4e46a3d9869563c6210b01bb651c40cbe65da80",
  "tree": "d37626d8077c0eaca35ec41e705c62af2a324847",
  "parents": [
    "c29b9b9b0235d56e5602f61ed38702dd376aae20"
  ],
  "author": {
    "name": "Johannes Berg",
    "email": "johannes@sipsolutions.net",
    "time": "Fri Sep 14 11:10:24 2007 -0400"
  },
  "committer": {
    "name": "David S. Miller",
    "email": "davem@sunset.davemloft.net",
    "time": "Wed Oct 10 16:49:26 2007 -0700"
  },
  "message": "[MAC80211]: fix race conditions with keys\n\nDuring receive processing, we select the key long before using it and\nbecause there\u0027s no locking it is possible that we kfree() the key\nafter having selected it but before using it for crypto operations.\nObviously, this is bad.\n\nSecondly, during transmit processing, there are two possible races: We\nhave a similar race between select_key() and using it for encryption,\nbut we also have a race here between select_key() and hardware\nencryption (both when a key is removed.)\n\nThis patch solves these issues by using RCU: when a key is to be freed,\nwe first remove the pointer from the appropriate places (sdata-\u003ekeys,\nsdata-\u003edefault_key, sta-\u003ekey) using rcu_assign_pointer() and then\nsynchronize_rcu(). Then, we can safely kfree() the key and remove it\nfrom the hardware. There\u0027s a window here where the hardware may still\nbe using it for decryption, but we can\u0027t work around that without having\ntwo hardware callbacks, one to disable the key for RX and one to disable\nit for TX; but the worst thing that will happen is that we receive a\npacket decrypted that we don\u0027t find a key for any more and then drop it.\n\nWhen we add a key, we first need to upload it to the hardware and then,\nusing rcu_assign_pointer() again, link it into our structures.\n\nIn the code using keys (TX/RX paths) we use rcu_dereference() to get the\nkey and enclose the whole tx/rx section in a rcu_read_lock() ...\nrcu_read_unlock() block. Because we\u0027ve uploaded the key to hardware\nbefore linking it into internal structures, we can guarantee that it is\nvalid once get to into tx().\n\nOne possible race condition remains, however: when we have hardware\nacceleration enabled and the driver shuts down the queues, we end up\nqueueing the frame. If now somebody removes the key, the key will be\nremoved from hwaccel and then then driver will be asked to encrypt the\nframe with a key index that has been removed. Hence, drivers will need\nto be aware that the hw_key_index they are passed might not be under\nall circumstances. Most drivers will, however, simply ignore that\ncondition and encrypt the frame with the selected key anyway, this\nonly results in a frame being encrypted with a wrong key or dropped\n(rightfully) because the key was not valid. There isn\u0027t much we can\ndo about it unless we want to walk the pending frame queue every time\na key is removed and remove all frames that used it.\n\nThis race condition, however, will most likely be solved once we add\nmultiqueue support to mac80211 because then frames will be queued\nfurther up the stack instead of after being processed.\n\nSigned-off-by: Johannes Berg \u003cjohannes@sipsolutions.net\u003e\nAcked-by: Michael Wu \u003cflamingice@sourmilk.net\u003e\nSigned-off-by: John W. Linville \u003clinville@tuxdriver.com\u003e\nSigned-off-by: David S. Miller \u003cdavem@davemloft.net\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "1d585cc2c8c748bf088f0f2dde05529b15720196",
      "old_mode": 33188,
      "old_path": "net/mac80211/ieee80211_ioctl.c",
      "new_id": "10ec05624a67b436835204d1f0d8d1afb93b63d1",
      "new_mode": 33188,
      "new_path": "net/mac80211/ieee80211_ioctl.c"
    },
    {
      "type": "modify",
      "old_id": "178f00cf61b925110e4efd865ece28854e97f837",
      "old_mode": 33188,
      "old_path": "net/mac80211/key.c",
      "new_id": "19e77f626d848a0d532234e6733fbda092b8ddcb",
      "new_mode": 33188,
      "new_path": "net/mac80211/key.c"
    },
    {
      "type": "modify",
      "old_id": "4fb8c7026f11d3fcafb8f252608a53dc3d6c5e05",
      "old_mode": 33188,
      "old_path": "net/mac80211/rx.c",
      "new_id": "91b7886bf797f4c64d9db3206d3e56f1a613db9b",
      "new_mode": 33188,
      "new_path": "net/mac80211/rx.c"
    },
    {
      "type": "modify",
      "old_id": "0820f127da2b34dfe8d5698b4ace996b143c7675",
      "old_mode": 33188,
      "old_path": "net/mac80211/tx.c",
      "new_id": "b29dc70b2f0171e8d7aef207397d0eda3bf382eb",
      "new_mode": 33188,
      "new_path": "net/mac80211/tx.c"
    }
  ]
}