)]}'
{
  "commit": "eea915bb0d1358755f151eaefb8208a2d5f3e10c",
  "tree": "35d593bde3caa1b79751e0ec1a6c6333b2a72506",
  "parents": [
    "8f257a142fc3868d69de3f996b95d7bdbc509560"
  ],
  "author": {
    "name": "Neil Horman",
    "email": "nhorman@tuxdriver.com",
    "time": "Mon Jan 02 15:31:23 2012 -0500"
  },
  "committer": {
    "name": "Greg Kroah-Hartman",
    "email": "gregkh@suse.de",
    "time": "Wed Jan 04 16:31:29 2012 -0800"
  },
  "message": "firmware: Fix an oops on reading fw_priv-\u003efw in sysfs loading file\n\nThis oops was reported recently:\nfirmware_loading_store+0xf9/0x17b\ndev_attr_store+0x20/0x22\nsysfs_write_file+0x101/0x134\nvfs_write+0xac/0xf3\nsys_write+0x4a/0x6e\nsystem_call_fastpath+0x16/0x1b\n\nThe complete backtrace was unfortunately not captured, but details can be found\nhere:\nhttps://bugzilla.redhat.com/show_bug.cgi?id\u003d769920\n\nThe cause is fairly clear.\n\nIts caused by the fact that firmware_loading_store has a case 0 in its\nswitch statement that reads and writes the fw_priv-\u003efw poniter without the\nprotection of the fw_lock mutex.  since there is a window between the time that\n_request_firmware sets fw_priv-\u003efw to NULL and the time the corresponding sysfs\nfile is unregistered, its possible for a user space application to race in, and\nwrite a zero to the loading file, causing a NULL dereference in\nfirmware_loading_store.  Fix it by extending the protection of the fw_lock mutex\nto cover all of the firware_loading_store function.\n\nSigned-off-by: Neil Horman \u003cnhorman@tuxdriver.com\u003e\nCc: stable \u003cstable@vger.kernel.org\u003e\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@suse.de\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "06ed6b4e7df5ecc0d236cd73ee2690933f8e8ee7",
      "old_mode": 33188,
      "old_path": "drivers/base/firmware_class.c",
      "new_id": "3719c94be19c1016812150ba8127bb04b96806a4",
      "new_mode": 33188,
      "new_path": "drivers/base/firmware_class.c"
    }
  ]
}