The attached patch fixes the problem of an oops occuring when a user attempts to add a key to a non-keyring key [CVE-2006-1522]. The problem is that __keyring_search_one() doesn't check that the keyring it's been given is actually a keyring. I've fixed this problem by: (1) declaring that caller of __keyring_search_one() must guarantee that the keyring is a keyring; and (2) making key_create_or_update() check that the keyring is a keyring, and return -ENOTDIR if it isn't. This can be tested by: keyctl add user b b `keyctl add user a a @s` Signed-Off-By: David Howells <dhowells@redhat.com> --- pseries>diffstat -p1 linux-2.6.16-key-check.patch security/keys/key.c | 4 ++++ security/keys/keyring.c | 1 + 2 files changed, 5 insertions(+) --- linux-2.6.9/security/keys/key.c.orig 2006-04-10 13:45:43.000000000 +0100 +++ linux-2.6.9/security/keys/key.c 2006-04-10 13:47:19.000000000 +0100 @@ -782,6 +782,10 @@ key_ref_t key_create_or_update(key_ref_t key_check(keyring); + key_ref = ERR_PTR(-ENOTDIR); + if (keyring->type != &key_type_keyring) + goto error_2; + down_write(&keyring->sem); /* if we're going to allocate a new key, we're going to have --- linux-2.6.9/security/keys/keyring.c.orig 2006-04-10 13:45:43.000000000 +0100 +++ linux-2.6.9/security/keys/keyring.c 2006-04-10 13:47:19.000000000 +0100 @@ -437,6 +437,7 @@ EXPORT_SYMBOL(keyring_search); /* * search the given keyring only (no recursion) * - keyring must be locked by caller + * - caller must guarantee that the keyring is a keyring */ key_ref_t __keyring_search_one(key_ref_t keyring_ref, const struct key_type *ktype,
Fixed in genpatches 2.6.16-3. Adding maintainers to CC: ck-sources: marineam hppa-sources: GMSoft mips-sources-2.6.15: Kumba rsbac-sources-2.6: kang usermode-sources: dsd
fixed in ck-sources-2.6.16_p6
2.6.16.5-pa11 already stable in the tree for hppa.
chrb: Please bump xen-sources.
usermode-sources fixed thanks to dang
All done (apart from sh-sources); resolving.
