)]}'
{
  "commit": "0da9dfdd2cd9889201bc6f6f43580c99165cd087",
  "tree": "960a37da7bc3e35d9c598eff7b829ab5959e7027",
  "parents": [
    "7c6baa304b841673d3a55ea4fcf9a5cbf7a1674b"
  ],
  "author": {
    "name": "David Howells",
    "email": "dhowells@redhat.com",
    "time": "Tue Mar 12 16:44:31 2013 +1100"
  },
  "committer": {
    "name": "James Morris",
    "email": "james.l.morris@oracle.com",
    "time": "Tue Mar 12 16:44:31 2013 +1100"
  },
  "message": "keys: fix race with concurrent install_user_keyrings()\n\nThis fixes CVE-2013-1792.\n\nThere is a race in install_user_keyrings() that can cause a NULL pointer\ndereference when called concurrently for the same user if the uid and\nuid-session keyrings are not yet created.  It might be possible for an\nunprivileged user to trigger this by calling keyctl() from userspace in\nparallel immediately after logging in.\n\nAssume that we have two threads both executing lookup_user_key(), both\nlooking for KEY_SPEC_USER_SESSION_KEYRING.\n\n\tTHREAD A\t\t\tTHREAD B\n\t\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\t\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\n\t\t\t\t\t\u003d\u003d\u003ecall install_user_keyrings();\n\tif (!cred-\u003euser-\u003esession_keyring)\n\t\u003d\u003d\u003ecall install_user_keyrings()\n\t\t\t\t\t...\n\t\t\t\t\tuser-\u003euid_keyring \u003d uid_keyring;\n\tif (user-\u003euid_keyring)\n\t\treturn 0;\n\t\u003c\u003d\u003d\n\tkey \u003d cred-\u003euser-\u003esession_keyring [\u003d\u003d NULL]\n\t\t\t\t\tuser-\u003esession_keyring \u003d session_keyring;\n\tatomic_inc(\u0026key-\u003eusage); [oops]\n\nAt the point thread A dereferences cred-\u003euser-\u003esession_keyring, thread B\nhasn\u0027t updated user-\u003esession_keyring yet, but thread A assumes it is\npopulated because install_user_keyrings() returned ok.\n\nThe race window is really small but can be exploited if, for example,\nthread B is interrupted or preempted after initializing uid_keyring, but\nbefore doing setting session_keyring.\n\nThis couldn\u0027t be reproduced on a stock kernel.  However, after placing\nsystemtap probe on \u0027user-\u003esession_keyring \u003d session_keyring;\u0027 that\nintroduced some delay, the kernel could be crashed reliably.\n\nFix this by checking both pointers before deciding whether to return.\nAlternatively, the test could be done away with entirely as it is checked\ninside the mutex - but since the mutex is global, that may not be the best\nway.\n\nSigned-off-by: David Howells \u003cdhowells@redhat.com\u003e\nReported-by: Mateusz Guzik \u003cmguzik@redhat.com\u003e\nCc: \u003cstable@kernel.org\u003e\nSigned-off-by: Andrew Morton \u003cakpm@linux-foundation.org\u003e\nSigned-off-by: James Morris \u003cjames.l.morris@oracle.com\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "a571fad91010156aa7c532836b2a612e8e82e6fd",
      "old_mode": 33188,
      "old_path": "security/keys/process_keys.c",
      "new_id": "42defae1e161632e93b13b8194af1a30a09f2492",
      "new_mode": 33188,
      "new_path": "security/keys/process_keys.c"
    }
  ]
}