{"push_id":948816189,"size":11,"distinct_size":11,"ref":"refs/heads/taurusdev","head":"191720782402693716cc113165514db0a98024c4","before":"81b406d1ed0158e3ddac7bb6e84ba040cbac0ecc","commits":[{"sha":"fb769b3856625f2c3579a58d1e4d3deb8c083efa","author":{"email":"20b70f0af00562e63758b9ee42012ecc96c58590@redhat.com","name":"Oleg Nesterov"},"message":"keys: change keyctl_session_to_parent() to use task_work_add()\n\nChange keyctl_session_to_parent() to use task_work_add() and move\nkey_replace_session_keyring() logic into task_work->func().\n\nNote that we do task_work_cancel() before task_work_add() to ensure that\nonly one work can be pending at any time.  This is important, we must not\nallow user-space to abuse the parent's ->task_works list.\n\nThe callback, replace_session_keyring(), checks PF_EXITING.  I guess this\nis not really needed but looks better.\n\nAs a side effect, this fixes the (unlikely) race.  The callers of\nkey_replace_session_keyring() and keyctl_session_to_parent() lack the\nnecessary barriers, the parent can miss the request.\n\nNow we can remove task_struct->replacement_session_keyring and related\ncode.\n\nSigned-off-by: Oleg Nesterov <oleg@redhat.com>\nAcked-by: David Howells <dhowells@redhat.com>\nCc: Thomas Gleixner <tglx@linutronix.de>\nCc: Richard Kuo <rkuo@codeaurora.org>\nCc: Linus Torvalds <torvalds@linux-foundation.org>\nCc: Alexander Gordeev <agordeev@redhat.com>\nCc: Chris Zankel <chris@zankel.net>\nCc: David Smith <dsmith@redhat.com>\nCc: \"Frank Ch. Eigler\" <fche@redhat.com>\nCc: Geert Uytterhoeven <geert@linux-m68k.org>\nCc: Larry Woodman <lwoodman@redhat.com>\nCc: Peter Zijlstra <peterz@infradead.org>\nCc: Tejun Heo <tj@kernel.org>\nCc: Ingo Molnar <mingo@elte.hu>\nSigned-off-by: Andrew Morton <akpm@linux-foundation.org>\nSigned-off-by: Al Viro <viro@zeniv.linux.org.uk>","distinct":true,"url":"https://api.github.com/repos/txuki2005/TaUrUs_Kernel/commits/fb769b3856625f2c3579a58d1e4d3deb8c083efa"},{"sha":"d4faba7d2e64719399e097c41b954f91db5039d9","author":{"email":"5c1e68b099950c134891f0b6e179498a8ebe9cf9@linux-foundation.org","name":"Andrew Morton"},"message":"security/keys/keyctl.c: suppress memory allocation failure warning\n\nThis allocation may be large.  The code is probing to see if it will\nsucceed and if not, it falls back to vmalloc().  We should suppress any\npage-allocation failure messages when the fallback happens.\n\nReported-by: Dave Jones <davej@redhat.com>\nAcked-by: David Howells <dhowells@redhat.com>\nCc: James Morris <jmorris@namei.org>\nSigned-off-by: Andrew Morton <akpm@linux-foundation.org>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>","distinct":true,"url":"https://api.github.com/repos/txuki2005/TaUrUs_Kernel/commits/d4faba7d2e64719399e097c41b954f91db5039d9"},{"sha":"4629fd13ad5842a5005a1f29ccdcb1c64840372a","author":{"email":"ebac1d06c1688626821bb0e574a037a7a5354e49@redhat.com","name":"David Howells"},"message":"KEYS: Make the session and process keyrings per-thread\n\nMake the session keyring per-thread rather than per-process, but still\ninherited from the parent thread to solve a problem with PAM and gdm.\n\nThe problem is that join_session_keyring() will reject attempts to change the\nsession keyring of a multithreaded program but gdm is now multithreaded before\nit gets to the point of starting PAM and running pam_keyinit to create the\nsession keyring.  See:\n\n\thttps://bugs.freedesktop.org/show_bug.cgi?id=49211\n\nThe reason that join_session_keyring() will only change the session keyring\nunder a single-threaded environment is that it's hard to alter the other\nthread's credentials to effect the change in a multi-threaded program.  The\nproblems are such as:\n\n (1) How to prevent two threads both running join_session_keyring() from\n     racing.\n\n (2) Another thread's credentials may not be modified directly by this process.\n\n (3) The number of threads is uncertain whilst we're not holding the\n     appropriate spinlock, making preallocation slightly tricky.\n\n (4) We could use TIF_NOTIFY_RESUME and key_replace_session_keyring() to get\n     another thread to replace its keyring, but that means preallocating for\n     each thread.\n\nA reasonable way around this is to make the session keyring per-thread rather\nthan per-process and just document that if you want a common session keyring,\nyou must get it before you spawn any threads - which is the current situation\nanyway.\n\nWhilst we're at it, we can the process keyring behave in the same way.  This\nmeans we can clean up some of the ickyness in the creds code.\n\nBasically, after this patch, the session, process and thread keyrings are about\ninheritance rules only and not about sharing changes of keyring.\n\nReported-by: Mantas M. <grawity@gmail.com>\nSigned-off-by: David Howells <dhowells@redhat.com>\nTested-by: Ray Strode <rstrode@redhat.com>\n\nConflicts:\n\tsecurity/keys/keyctl.c","distinct":true,"url":"https://api.github.com/repos/txuki2005/TaUrUs_Kernel/commits/4629fd13ad5842a5005a1f29ccdcb1c64840372a"},{"sha":"c2726afa3698d1cbf563396423dae17097545a96","author":{"email":"ebac1d06c1688626821bb0e574a037a7a5354e49@redhat.com","name":"David Howells"},"message":"KEYS: Reduce initial permissions on keys\n\nReduce the initial permissions on new keys to grant the possessor everything,\nview permission only to the user (so the keys can be seen in /proc/keys) and\nnothing else.\n\nThis gives the creator a chance to adjust the permissions mask before other\nprocesses can access the new key or create a link to it.\n\nTo aid with this, keyring_alloc() now takes a permission argument rather than\nsetting the permissions itself.\n\nThe following permissions are now set:\n\n (1) The user and user-session keyrings grant the user that owns them full\n     permissions and grant a possessor everything bar SETATTR.\n\n (2) The process and thread keyrings grant the possessor full permissions but\n     only grant the user VIEW.  This permits the user to see them in\n     /proc/keys, but not to do anything with them.\n\n (3) Anonymous session keyrings grant the possessor full permissions, but only\n     grant the user VIEW and READ.  This means that the user can see them in\n     /proc/keys and can list them, but nothing else.  Possibly READ shouldn't\n     be provided either.\n\n (4) Named session keyrings grant everything an anonymous session keyring does,\n     plus they grant the user LINK permission.  The whole point of named\n     session keyrings is that others can also subscribe to them.  Possibly this\n     should be a separate permission to LINK.\n\n (5) The temporary session keyring created by call_sbin_request_key() gets the\n     same permissions as an anonymous session keyring.\n\n (6) Keys created by add_key() get VIEW, SEARCH, LINK and SETATTR for the\n     possessor, plus READ and/or WRITE if the key type supports them.  The used\n     only gets VIEW now.\n\n (7) Keys created by request_key() now get the same as those created by\n     add_key().\n\nReported-by: Lennart Poettering <lennart@poettering.net>\nReported-by: Stef Walter <stefw@redhat.com>\nSigned-off-by: David Howells <dhowells@redhat.com>","distinct":true,"url":"https://api.github.com/repos/txuki2005/TaUrUs_Kernel/commits/c2726afa3698d1cbf563396423dae17097545a96"},{"sha":"1884d0565fce97e254dbd96e52c5be9015f8db18","author":{"email":"a8e70ce470c554a6f43803df5187177f222204a8@perception-point.io","name":"Yevgeny Pats"},"message":"KEYS: Fix keyring ref leak in join_session_keyring()\n\nThis fixes CVE-2016-0728.\n\nIf a thread is asked to join as a session keyring the keyring that's already\nset as its session, we leak a keyring reference.\n\nThis can be tested with the following program:\n\n\t#include <stddef.h>\n\t#include <stdio.h>\n\t#include <sys/types.h>\n\t#include <keyutils.h>\n\n\tint main(int argc, const char *argv[])\n\t{\n\t\tint i = 0;\n\t\tkey_serial_t serial;\n\n\t\tserial = keyctl(KEYCTL_JOIN_SESSION_KEYRING,\n\t\t\t\t\"leaked-keyring\");\n\t\tif (serial < 0) {\n\t\t\tperror(\"keyctl\");\n\t\t\treturn -1;\n\t\t}\n\n\t\tif (keyctl(KEYCTL_SETPERM, serial,\n\t\t\t   KEY_POS_ALL | KEY_USR_ALL) < 0) {\n\t\t\tperror(\"keyctl\");\n\t\t\treturn -1;\n\t\t}\n\n\t\tfor (i = 0; i < 100; i++) {\n\t\t\tserial = keyctl(KEYCTL_JOIN_SESSION_KEYRING,\n\t\t\t\t\t\"leaked-keyring\");\n\t\t\tif (serial < 0) {\n\t\t\t\tperror(\"keyctl\");\n\t\t\t\treturn -1;\n\t\t\t}\n\t\t}\n\n\t\treturn 0;\n\t}\n\nIf, after the program has run, there something like the following line in\n/proc/keys:\n\n3f3d898f I--Q---   100 perm 3f3f0000     0     0 keyring   leaked-keyring: empty\n\nwith a usage count of 100 * the number of times the program has been run,\nthen the kernel is malfunctioning.  If leaked-keyring has zero usages or\nhas been garbage collected, then the problem is fixed.\n\nReported-by: Yevgeny Pats <yevgeny@perception-point.io>\nSigned-off-by: David Howells <dhowells@redhat.com>\nAcked-by: Don Zickus <dzickus@redhat.com>\nAcked-by: Prarit Bhargava <prarit@redhat.com>\nAcked-by: Jarod Wilson <jarod@redhat.com>\nSigned-off-by: James Morris <james.l.morris@oracle.com>\nSigned-off-by: Pranav Vashi <neobuddy89@gmail.com>","distinct":true,"url":"https://api.github.com/repos/txuki2005/TaUrUs_Kernel/commits/1884d0565fce97e254dbd96e52c5be9015f8db18"},{"sha":"655aeddf1d7feab60e9f0c64473e935f29098723","author":{"email":"91e38e63b890fbb214c8914809fde03c73e7f24d@linux.intel.com","name":"Alan Cox"},"message":"keys: Fix unreachable code\n\nWe set ret to NULL then test it. Remove the bogus test\n\nSigned-off-by: Alan Cox <alan@linux.intel.com>\nSigned-off-by: Jiri Kosina <jkosina@suse.cz>","distinct":true,"url":"https://api.github.com/repos/txuki2005/TaUrUs_Kernel/commits/655aeddf1d7feab60e9f0c64473e935f29098723"},{"sha":"1c2425bc0607b4950a39aaebd3c0043c7191df98","author":{"email":"ebac1d06c1688626821bb0e574a037a7a5354e49@redhat.com","name":"David Howells"},"message":"KEYS: Do LRU discard in full keyrings\n\nDo an LRU discard in keyrings that are full rather than returning ENFILE.  To\nperform this, a time_t is added to the key struct and updated by the creation\nof a link to a key and by a key being found as the result of a search.  At the\ncompletion of a successful search, the keyrings in the path between the root of\nthe search and the first found link to it also have their last-used times\nupdated.\n\nNote that discarding a link to a key from a keyring does not necessarily\ndestroy the key as there may be references held by other places.\n\nAn alternate discard method that might suffice is to perform FIFO discard from\nthe keyring, using the spare 2-byte hole in the keylist header as the index of\nthe next link to be discarded.\n\nThis is useful when using a keyring as a cache for DNS results or foreign\nfilesystem IDs.\n\nThis can be tested by the following.  As root do:\n\n\techo 1000 >/proc/sys/kernel/keys/root_maxkeys\n\n\tkr=`keyctl newring foo @s`\n\tfor ((i=0; i<2000; i++)); do keyctl add user a$i a $kr; done\n\nWithout this patch ENFILE should be reported when the keyring fills up.  With\nthis patch, the keyring discards keys in an LRU fashion.  Note that the stored\nLRU time has a granularity of 1s.\n\nAfter doing this, /proc/key-users can be observed and should show that most of\nthe 2000 keys have been discarded:\n\n\t[root@andromeda ~]# cat /proc/key-users\n\t    0:   517 516/516 513/1000 5249/20000\n\nThe \"513/1000\" here is the number of quota-accounted keys present for this user\nout of the maximum permitted.\n\nIn /proc/keys, the keyring shows the number of keys it has and the number of\nslots it has allocated:\n\n\t[root@andromeda ~]# grep foo /proc/keys\n\t200c64c4 I--Q--     1 perm 3b3f0000     0     0 keyring   foo: 509/509\n\nThe maximum is (PAGE_SIZE - header) / key pointer size.  That's typically 509\non a 64-bit system and 1020 on a 32-bit system.\n\nSigned-off-by: David Howells <dhowells@redhat.com>","distinct":true,"url":"https://api.github.com/repos/txuki2005/TaUrUs_Kernel/commits/1c2425bc0607b4950a39aaebd3c0043c7191df98"},{"sha":"4e7abb4eb8e14fddc1f697de9193fdf6de0503ab","author":{"email":"ebac1d06c1688626821bb0e574a037a7a5354e49@redhat.com","name":"David Howells"},"message":"KEYS: Add payload preparsing opportunity prior to key instantiate or update\n\nGive the key type the opportunity to preparse the payload prior to the\ninstantiation and update routines being called.  This is done with the\nprovision of two new key type operations:\n\n\tint (*preparse)(struct key_preparsed_payload *prep);\n\tvoid (*free_preparse)(struct key_preparsed_payload *prep);\n\nIf the first operation is present, then it is called before key creation (in\nthe add/update case) or before the key semaphore is taken (in the update and\ninstantiate cases).  The second operation is called to clean up if the first\nwas called.\n\npreparse() is given the opportunity to fill in the following structure:\n\n\tstruct key_preparsed_payload {\n\t\tchar\t\t*description;\n\t\tvoid\t\t*type_data[2];\n\t\tvoid\t\t*payload;\n\t\tconst void\t*data;\n\t\tsize_t\t\tdatalen;\n\t\tsize_t\t\tquotalen;\n\t};\n\nBefore the preparser is called, the first three fields will have been cleared,\nthe payload pointer and size will be stored in data and datalen and the default\nquota size from the key_type struct will be stored into quotalen.\n\nThe preparser may parse the payload in any way it likes and may store data in\nthe type_data[] and payload fields for use by the instantiate() and update()\nops.\n\nThe preparser may also propose a description for the key by attaching it as a\nstring to the description field.  This can be used by passing a NULL or \"\"\ndescription to the add_key() system call or the key_create_or_update()\nfunction.  This cannot work with request_key() as that required the description\nto tell the upcall about the key to be created.\n\nThis, for example permits keys that store PGP public keys to generate their own\nname from the user ID and public key fingerprint in the key.\n\nThe instantiate() and update() operations are then modified to look like this:\n\n\tint (*instantiate)(struct key *key, struct key_preparsed_payload *prep);\n\tint (*update)(struct key *key, struct key_preparsed_payload *prep);\n\nand the new payload data is passed in *prep, whether or not it was preparsed.\n\nSigned-off-by: David Howells <dhowells@redhat.com>\nSigned-off-by: Rusty Russell <rusty@rustcorp.com.au>","distinct":true,"url":"https://api.github.com/repos/txuki2005/TaUrUs_Kernel/commits/4e7abb4eb8e14fddc1f697de9193fdf6de0503ab"},{"sha":"179473e26f0619f4335bf3efa9dcfb83fb622519","author":{"email":"ebac1d06c1688626821bb0e574a037a7a5354e49@redhat.com","name":"David Howells"},"message":"KEYS: Use keyring_alloc() to create special keyrings\n\nUse keyring_alloc() to create special keyrings now that it has a permissions\nparameter rather than using key_alloc() + key_instantiate_and_link().\n\nAlso document and export keyring_alloc() so that modules can use it too.\n\nSigned-off-by: David Howells <dhowells@redhat.com>","distinct":true,"url":"https://api.github.com/repos/txuki2005/TaUrUs_Kernel/commits/179473e26f0619f4335bf3efa9dcfb83fb622519"},{"sha":"b5d4a1d213b1b4fb329e5e8e0bbd209e3c2a7f11","author":{"email":"ebac1d06c1688626821bb0e574a037a7a5354e49@redhat.com","name":"David Howells"},"message":"KEYS: Fix some sparse warnings\n\nFix some sparse warnings in the keyrings code:\n\n (1) compat_keyctl_instantiate_key_iov() should be static.\n\n (2) There were a couple of places where a pointer was being compared against\n     integer 0 rather than NULL.\n\n (3) keyctl_instantiate_key_common() should not take a __user-labelled iovec\n     pointer as the caller must have copied the iovec to kernel space.\n\n (4) __key_link_begin() takes and __key_link_end() releases\n     keyring_serialise_link_sem under some circumstances and so this should be\n     declared.\n\n     Note that adding __acquires() and __releases() for this doesn't help cure\n     the warnings messages - something only commenting out both helps.\n\nSigned-off-by: David Howells <dhowells@redhat.com>\nSigned-off-by: James Morris <james.l.morris@oracle.com>","distinct":true,"url":"https://api.github.com/repos/txuki2005/TaUrUs_Kernel/commits/b5d4a1d213b1b4fb329e5e8e0bbd209e3c2a7f11"},{"sha":"191720782402693716cc113165514db0a98024c4","author":{"email":"ebac1d06c1688626821bb0e574a037a7a5354e49@redhat.com","name":"David Howells"},"message":"KEYS: Don't check for NULL key pointer in key_validate()\n\nDon't bother checking for NULL key pointer in key_validate() as all of the\nplaces that call it will crash anyway if the relevant key pointer is NULL by\nthe time they call key_validate().  Therefore, the checking must be done prior\nto calling here.\n\nWhilst we're at it, simplify the key_validate() function a bit and mark its\nargument const.\n\nReported-by: Dan Carpenter <dan.carpenter@oracle.com>\nSigned-off-by: David Howells <dhowells@redhat.com>\ncc: Dan Carpenter <dan.carpenter@oracle.com>\nSigned-off-by: James Morris <james.l.morris@oracle.com>","distinct":true,"url":"https://api.github.com/repos/txuki2005/TaUrUs_Kernel/commits/191720782402693716cc113165514db0a98024c4"}]}