From: David Howells <dhowells@xxxxxxxxxx> This patch has been added to the 4.1 stable tree. If you have any objections, please let us know. =============== [ Upstream commit eee045021fb22aeac7f5d6f2092430b530c880ee ] KEY_FLAG_KEEP should only be applied to a key if the keyring it is being linked into has KEY_FLAG_KEEP set. To this end, partially revert the following patch: commit 1d6d167c2efcfe9539d9cffb1a1be9c92e39c2c0 Author: Mimi Zohar <zohar@xxxxxxxxxxxxxxxxxx> Date: Thu Jan 7 07:46:36 2016 -0500 KEYS: refcount bug fix to undo the change that made it unconditional (Mimi got it right the first time). Without undoing this change, it becomes impossible to delete, revoke or invalidate keys added to keyrings through __key_instantiate_and_link() where the keyring has itself been linked to. To test this, run the following command sequence: keyctl newring foo @s keyctl add user a a %:foo keyctl unlink %user:a %:foo keyctl clear %:foo With the commit mentioned above the third and fourth commands fail with EPERM when they should succeed. Reported-by: Stephen Gallager <sgallagh@xxxxxxxxxx> Signed-off-by: David Howells <dhowells@xxxxxxxxxx> Acked-by: Mimi Zohar <zohar@xxxxxxxxxxxxxxxxxx> cc: Mimi Zohar <zohar@xxxxxxxxxxxxxxxxxx> cc: keyrings@xxxxxxxxxxxxxxx cc: stable@xxxxxxxxxxxxxxx Signed-off-by: James Morris <james.l.morris@xxxxxxxxxx> Signed-off-by: Sasha Levin <sasha.levin@xxxxxxxxxx> --- security/keys/key.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/security/keys/key.c b/security/keys/key.c index 0a0ff94..3ac72df 100644 --- a/security/keys/key.c +++ b/security/keys/key.c @@ -430,7 +430,8 @@ static int __key_instantiate_and_link(struct key *key, /* and link it into the destination keyring */ if (keyring) { - set_bit(KEY_FLAG_KEEP, &key->flags); + if (test_bit(KEY_FLAG_KEEP, &keyring->flags)) + set_bit(KEY_FLAG_KEEP, &key->flags); __key_link(key, _edit); } -- 2.5.0 -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html