--- /dev/null
+From ede0fa98a900e657d1fcd80b50920efc896c1a4c Mon Sep 17 00:00:00 2001
+From: Eric Biggers <ebiggers@google.com>
+Date: Fri, 22 Feb 2019 15:36:18 +0000
+Subject: KEYS: always initialize keyring_index_key::desc_len
+
+From: Eric Biggers <ebiggers@google.com>
+
+commit ede0fa98a900e657d1fcd80b50920efc896c1a4c upstream.
+
+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")
+Signed-off-by: Eric Biggers <ebiggers@google.com>
+Signed-off-by: David Howells <dhowells@redhat.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: James Morris <james.morris@microsoft.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ security/keys/keyring.c | 4 +---
+ security/keys/proc.c | 3 +--
+ security/keys/request_key.c | 1 +
+ security/keys/request_key_auth.c | 2 +-
+ 4 files changed, 4 insertions(+), 6 deletions(-)
+
+--- a/security/keys/keyring.c
++++ b/security/keys/keyring.c
+@@ -652,9 +652,6 @@ static bool search_nested_keyrings(struc
+ 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.
+ */
+@@ -912,6 +909,7 @@ key_ref_t keyring_search(key_ref_t keyri
+ 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,
+--- a/security/keys/proc.c
++++ b/security/keys/proc.c
+@@ -186,8 +186,7 @@ static int proc_keys_show(struct seq_fil
+ int rc;
+
+ struct keyring_search_context ctx = {
+- .index_key.type = key->type,
+- .index_key.description = key->description,
++ .index_key = key->index_key,
+ .cred = current_cred(),
+ .match_data.cmp = lookup_user_key_possessed,
+ .match_data.raw_data = key,
+--- a/security/keys/request_key.c
++++ b/security/keys/request_key.c
+@@ -544,6 +544,7 @@ struct key *request_key_and_link(struct
+ 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,
+--- a/security/keys/request_key_auth.c
++++ b/security/keys/request_key_auth.c
+@@ -254,7 +254,7 @@ struct key *key_get_instantiation_authke
+ struct key *authkey;
+ key_ref_t authkey_ref;
+
+- sprintf(description, "%x", target_id);
++ ctx.index_key.desc_len = sprintf(description, "%x", target_id);
+
+ authkey_ref = search_process_keyrings(&ctx);
+
--- /dev/null
+From cc1780fc42c76c705dd07ea123f1143dc5057630 Mon Sep 17 00:00:00 2001
+From: Eric Biggers <ebiggers@google.com>
+Date: Wed, 20 Feb 2019 13:32:11 +0000
+Subject: KEYS: user: Align the payload buffer
+
+From: Eric Biggers <ebiggers@google.com>
+
+commit cc1780fc42c76c705dd07ea123f1143dc5057630 upstream.
+
+Align the payload of "user" and "logon" keys so that users of the
+keyrings service can access it as a struct that requires more than
+2-byte alignment. fscrypt currently does this which results in the read
+of fscrypt_key::size being misaligned as it needs 4-byte alignment.
+
+Align to __alignof__(u64) rather than __alignof__(long) since in the
+future it's conceivable that people would use structs beginning with
+u64, which on some platforms would require more than 'long' alignment.
+
+Reported-by: Aaro Koskinen <aaro.koskinen@iki.fi>
+Fixes: 2aa349f6e37c ("[PATCH] Keys: Export user-defined keyring operations")
+Fixes: 88bd6ccdcdd6 ("ext4 crypto: add encryption key management facilities")
+Cc: stable@vger.kernel.org
+Signed-off-by: Eric Biggers <ebiggers@google.com>
+Tested-by: Aaro Koskinen <aaro.koskinen@iki.fi>
+Signed-off-by: David Howells <dhowells@redhat.com>
+Signed-off-by: James Morris <james.morris@microsoft.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ include/keys/user-type.h | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/include/keys/user-type.h
++++ b/include/keys/user-type.h
+@@ -31,7 +31,7 @@
+ struct user_key_payload {
+ struct rcu_head rcu; /* RCU destructor */
+ unsigned short datalen; /* length of this data */
+- char data[0]; /* actual data */
++ char data[0] __aligned(__alignof__(u64)); /* actual data */
+ };
+
+ extern struct key_type key_type_user;
--- /dev/null
+From 48396e80fb6526ea5ed267bd84f028bae56d2f9e Mon Sep 17 00:00:00 2001
+From: Bart Van Assche <bvanassche@acm.org>
+Date: Wed, 30 Jan 2019 14:05:55 -0800
+Subject: RDMA/srp: Rework SCSI device reset handling
+
+From: Bart Van Assche <bvanassche@acm.org>
+
+commit 48396e80fb6526ea5ed267bd84f028bae56d2f9e upstream.
+
+Since .scsi_done() must only be called after scsi_queue_rq() has
+finished, make sure that the SRP initiator driver does not call
+.scsi_done() while scsi_queue_rq() is in progress. Although
+invoking sg_reset -d while I/O is in progress works fine with kernel
+v4.20 and before, that is not the case with kernel v5.0-rc1. This
+patch avoids that the following crash is triggered with kernel
+v5.0-rc1:
+
+BUG: unable to handle kernel NULL pointer dereference at 0000000000000138
+CPU: 0 PID: 360 Comm: kworker/0:1H Tainted: G B 5.0.0-rc1-dbg+ #1
+Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1 04/01/2014
+Workqueue: kblockd blk_mq_run_work_fn
+RIP: 0010:blk_mq_dispatch_rq_list+0x116/0xb10
+Call Trace:
+ blk_mq_sched_dispatch_requests+0x2f7/0x300
+ __blk_mq_run_hw_queue+0xd6/0x180
+ blk_mq_run_work_fn+0x27/0x30
+ process_one_work+0x4f1/0xa20
+ worker_thread+0x67/0x5b0
+ kthread+0x1cf/0x1f0
+ ret_from_fork+0x24/0x30
+
+Cc: <stable@vger.kernel.org>
+Fixes: 94a9174c630c ("IB/srp: reduce lock coverage of command completion")
+Signed-off-by: Bart Van Assche <bvanassche@acm.org>
+Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/infiniband/ulp/srp/ib_srp.c | 10 ----------
+ 1 file changed, 10 deletions(-)
+
+--- a/drivers/infiniband/ulp/srp/ib_srp.c
++++ b/drivers/infiniband/ulp/srp/ib_srp.c
+@@ -2639,7 +2639,6 @@ static int srp_reset_device(struct scsi_
+ {
+ struct srp_target_port *target = host_to_target(scmnd->device->host);
+ struct srp_rdma_ch *ch;
+- int i, j;
+ u8 status;
+
+ shost_printk(KERN_ERR, target->scsi_host, "SRP reset_device called\n");
+@@ -2651,15 +2650,6 @@ static int srp_reset_device(struct scsi_
+ if (status)
+ return FAILED;
+
+- for (i = 0; i < target->ch_count; i++) {
+- ch = &target->ch[i];
+- for (j = 0; j < target->req_ring_size; ++j) {
+- struct srp_request *req = &ch->req_ring[j];
+-
+- srp_finish_req(ch, req, scmnd->device, DID_RESET << 16);
+- }
+- }
+-
+ return SUCCESS;
+ }
+
projects / thirdparty / kernel / stable-queue.git / commitdiff
