linux-security-module.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Eric Biggers <ebiggers@kernel.org>
To: keyrings@vger.kernel.org, David Howells <dhowells@redhat.com>
Cc: linux-security-module@vger.kernel.org,
	linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com
Subject: Re: [PATCH] KEYS: always initialize keyring_index_key::desc_len
Date: Fri, 2 Nov 2018 18:57:36 -0700	[thread overview]
Message-ID: <20181103015735.GA771@sol.localdomain> (raw)
In-Reply-To: <20181102231510.15911-1-ebiggers@kernel.org>

On Fri, Nov 02, 2018 at 04:15:10PM -0700, Eric Biggers wrote:
> From: Eric Biggers <ebiggers@google.com>
> 
> syzbot hit the 'BUG_ON(index_key->desc_len == 0);' in __key_link_begin()
> called from construct_alloc_key() during sys_request_key(), because the
> length of the key description was never calculated.
> 
> The problem is that we rely on ->desc_len being initialized by
> search_process_keyrings(), specifically by search_nested_keyrings().
> But, if the process isn't subscribed to any keyrings that never happens.
> 
> Fix it by always initializing keyring_index_key::desc_len as soon as the
> description is set, like we already do in some places.
> 
> The following program reproduces the BUG_ON() when it's run as root and
> no session keyring has been installed.  If it doesn't work, try removing
> pam_keyinit.so from /etc/pam.d/login and rebooting.
> 
>     #include <stdlib.h>
>     #include <unistd.h>
>     #include <keyutils.h>
> 
>     int main(void)
>     {
>             int id = add_key("keyring", "syz", NULL, 0, KEY_SPEC_USER_KEYRING);
> 
>             keyctl_setperm(id, KEY_OTH_WRITE);
>             setreuid(5000, 5000);
>             request_key("user", "desc", "", id);
>     }
> 
> Reported-by: syzbot+ec24e95ea483de0a24da@syzkaller.appspotmail.com
> Fixes: b2a4df200d57 ("KEYS: Expand the capacity of a keyring")
> Cc: <stable@vger.kernel.org> # v3.13+
> Signed-off-by: Eric Biggers <ebiggers@google.com>
> ---
>  security/keys/keyring.c          | 4 +---
>  security/keys/proc.c             | 1 +
>  security/keys/request_key.c      | 1 +
>  security/keys/request_key_auth.c | 2 +-
>  4 files changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/security/keys/keyring.c b/security/keys/keyring.c
> index 41bcf57e96f2..99a55145ddcd 100644
> --- a/security/keys/keyring.c
> +++ b/security/keys/keyring.c
> @@ -661,9 +661,6 @@ static bool search_nested_keyrings(struct key *keyring,
>  	BUG_ON((ctx->flags & STATE_CHECKS) == 0 ||
>  	       (ctx->flags & STATE_CHECKS) == STATE_CHECKS);
>  
> -	if (ctx->index_key.description)
> -		ctx->index_key.desc_len = strlen(ctx->index_key.description);
> -
>  	/* Check to see if this top-level keyring is what we are looking for
>  	 * and whether it is valid or not.
>  	 */
> @@ -914,6 +911,7 @@ key_ref_t keyring_search(key_ref_t keyring,
>  	struct keyring_search_context ctx = {
>  		.index_key.type		= type,
>  		.index_key.description	= description,
> +		.index_key.desc_len	= strlen(description),
>  		.cred			= current_cred(),
>  		.match_data.cmp		= key_default_cmp,
>  		.match_data.raw_data	= description,
> diff --git a/security/keys/proc.c b/security/keys/proc.c
> index 5af2934965d8..909f6c5270a1 100644
> --- a/security/keys/proc.c
> +++ b/security/keys/proc.c
> @@ -168,6 +168,7 @@ static int proc_keys_show(struct seq_file *m, void *v)
>  	struct keyring_search_context ctx = {
>  		.index_key.type		= key->type,
>  		.index_key.description	= key->description,
> +		.index_key.desc_len	= strlen(key->description),
>  		.cred			= m->file->f_cred,
>  		.match_data.cmp		= lookup_user_key_possessed,
>  		.match_data.raw_data	= key,

It's actually possible to just set '.index_key = key->index_key' here.
I'll send v2 with that instead.

- Eric

  reply	other threads:[~2018-11-03  1:57 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-05 11:16 kernel BUG at security/keys/keyring.c:LINE! syzbot
2018-11-02 23:15 ` [PATCH] KEYS: always initialize keyring_index_key::desc_len Eric Biggers
2018-11-03  1:57   ` Eric Biggers [this message]
2018-11-03  1:58 ` [PATCH v2] " Eric Biggers
2018-11-28 23:19   ` Eric Biggers
2018-12-06 18:26     ` Eric Biggers
2019-01-10 20:27     ` Eric Biggers
2019-02-07 23:35       ` Eric Biggers
2019-02-19 23:04         ` Eric Biggers
2019-02-22 15:36 [PATCH] " David Howells

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20181103015735.GA771@sol.localdomain \
    --to=ebiggers@kernel.org \
    --cc=dhowells@redhat.com \
    --cc=keyrings@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=syzkaller-bugs@googlegroups.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).