- Linux-stable-mirror - lists.linaro.org

[Linux-stable-mirror] Patch "KVM: VMX: remove I/O port 0x80 bypass on Intel hosts" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled KVM: VMX: remove I/O port 0x80 bypass on Intel hosts to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: kvm-vmx-remove-i-o-port-0x80-bypass-on-intel-hosts.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From d59d51f088014f25c2562de59b9abff4f42a7468 Mon Sep 17 00:00:00 2001 From: Andrew Honig <ahonig(a)google.com> Date: Fri, 1 Dec 2017 10:21:09 -0800 Subject: KVM: VMX: remove I/O port 0x80 bypass on Intel hosts MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Andrew Honig <ahonig(a)google.com> commit d59d51f088014f25c2562de59b9abff4f42a7468 upstream. This fixes CVE-2017-1000407. KVM allows guests to directly access I/O port 0x80 on Intel hosts. If the guest floods this port with writes it generates exceptions and instability in the host kernel, leading to a crash. With this change guest writes to port 0x80 on Intel will behave the same as they currently behave on AMD systems. Prevent the flooding by removing the code that sets port 0x80 as a passthrough port. This is essentially the same as upstream patch 99f85a28a78e96d28907fe036e1671a218fee597, except that patch was for AMD chipsets and this patch is for Intel. Signed-off-by: Andrew Honig <ahonig(a)google.com> Signed-off-by: Jim Mattson <jmattson(a)google.com> Fixes: fdef3ad1b386 ("KVM: VMX: Enable io bitmaps to avoid IO port 0x80 VMEXITs") Signed-off-by: Radim Krčmář <rkrcmar(a)redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/x86/kvm/vmx.c | 5 ----- 1 file changed, 5 deletions(-) --- a/arch/x86/kvm/vmx.c +++ b/arch/x86/kvm/vmx.c @@ -6750,12 +6750,7 @@ static __init int hardware_setup(void) memset(vmx_vmread_bitmap, 0xff, PAGE_SIZE); memset(vmx_vmwrite_bitmap, 0xff, PAGE_SIZE); - /* - * Allow direct access to the PC debug port (it is often used for I/O - * delays, but the vmexits simply slow things down). - */ memset(vmx_io_bitmap_a, 0xff, PAGE_SIZE); - clear_bit(0x80, vmx_io_bitmap_a); memset(vmx_io_bitmap_b, 0xff, PAGE_SIZE); Patches currently in stable-queue which might be from ahonig(a)google.com are queue-4.14/kvm-vmx-remove-i-o-port-0x80-bypass-on-intel-hosts.patch

6 years, 9 months

1
0
0 0

[Linux-stable-mirror] Patch "KVM: s390: Fix skey emulation permission check" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled KVM: s390: Fix skey emulation permission check to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: kvm-s390-fix-skey-emulation-permission-check.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From ca76ec9ca871e67d8cd0b6caba24aca3d3ac4546 Mon Sep 17 00:00:00 2001 From: Janosch Frank <frankja(a)linux.vnet.ibm.com> Date: Mon, 4 Dec 2017 12:19:11 +0100 Subject: KVM: s390: Fix skey emulation permission check From: Janosch Frank <frankja(a)linux.vnet.ibm.com> commit ca76ec9ca871e67d8cd0b6caba24aca3d3ac4546 upstream. All skey functions call skey_check_enable at their start, which checks if we are in the PSTATE and injects a privileged operation exception if we are. Unfortunately they continue processing afterwards and perform the operation anyhow as skey_check_enable does not deliver an error if the exception injection was successful. Let's move the PSTATE check into the skey functions and exit them on such an occasion, also we now do not enable skey handling anymore in such a case. Signed-off-by: Janosch Frank <frankja(a)linux.vnet.ibm.com> Reviewed-by: Christian Borntraeger <borntraeger(a)de.ibm.com> Fixes: a7e19ab ("KVM: s390: handle missing storage-key facility") Reviewed-by: Cornelia Huck <cohuck(a)redhat.com> Reviewed-by: Thomas Huth <thuth(a)redhat.com> Signed-off-by: Christian Borntraeger <borntraeger(a)de.ibm.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/s390/kvm/priv.c | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-) --- a/arch/s390/kvm/priv.c +++ b/arch/s390/kvm/priv.c @@ -235,8 +235,6 @@ static int try_handle_skey(struct kvm_vc VCPU_EVENT(vcpu, 4, "%s", "retrying storage key operation"); return -EAGAIN; } - if (vcpu->arch.sie_block->gpsw.mask & PSW_MASK_PSTATE) - return kvm_s390_inject_program_int(vcpu, PGM_PRIVILEGED_OP); return 0; } @@ -247,6 +245,9 @@ static int handle_iske(struct kvm_vcpu * int reg1, reg2; int rc; + if (vcpu->arch.sie_block->gpsw.mask & PSW_MASK_PSTATE) + return kvm_s390_inject_program_int(vcpu, PGM_PRIVILEGED_OP); + rc = try_handle_skey(vcpu); if (rc) return rc != -EAGAIN ? rc : 0; @@ -276,6 +277,9 @@ static int handle_rrbe(struct kvm_vcpu * int reg1, reg2; int rc; + if (vcpu->arch.sie_block->gpsw.mask & PSW_MASK_PSTATE) + return kvm_s390_inject_program_int(vcpu, PGM_PRIVILEGED_OP); + rc = try_handle_skey(vcpu); if (rc) return rc != -EAGAIN ? rc : 0; @@ -311,6 +315,9 @@ static int handle_sske(struct kvm_vcpu * int reg1, reg2; int rc; + if (vcpu->arch.sie_block->gpsw.mask & PSW_MASK_PSTATE) + return kvm_s390_inject_program_int(vcpu, PGM_PRIVILEGED_OP); + rc = try_handle_skey(vcpu); if (rc) return rc != -EAGAIN ? rc : 0; Patches currently in stable-queue which might be from frankja(a)linux.vnet.ibm.com are queue-4.14/kvm-s390-fix-skey-emulation-permission-check.patch

6 years, 9 months

1
0
0 0

[Linux-stable-mirror] Patch "KVM: arm/arm64: vgic: Preserve the revious read from the pending table" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled KVM: arm/arm64: vgic: Preserve the revious read from the pending table to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: kvm-arm-arm64-vgic-preserve-the-revious-read-from-the-pending-table.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From ddb4b0102cb9cdd2398d98b3e1e024e08a2f4239 Mon Sep 17 00:00:00 2001 From: Marc Zyngier <marc.zyngier(a)arm.com> Date: Thu, 16 Nov 2017 17:58:16 +0000 Subject: KVM: arm/arm64: vgic: Preserve the revious read from the pending table From: Marc Zyngier <marc.zyngier(a)arm.com> commit ddb4b0102cb9cdd2398d98b3e1e024e08a2f4239 upstream. The current pending table parsing code assumes that we keep the previous read of the pending bits, but keep that variable in the current block, making sure it is discarded on each loop. We end-up using whatever is on the stack. Who knows, it might just be the right thing... Fixes: 280771252c1ba ("KVM: arm64: vgic-v3: KVM_DEV_ARM_VGIC_SAVE_PENDING_TABLES") Reported-by: AKASHI Takahiro <takahiro.akashi(a)linaro.org> Reviewed-by: Christoffer Dall <christoffer.dall(a)linaro.org> Signed-off-by: Marc Zyngier <marc.zyngier(a)arm.com> Signed-off-by: Christoffer Dall <christoffer.dall(a)linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- virt/kvm/arm/vgic/vgic-v3.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/virt/kvm/arm/vgic/vgic-v3.c +++ b/virt/kvm/arm/vgic/vgic-v3.c @@ -324,13 +324,13 @@ int vgic_v3_save_pending_tables(struct k int last_byte_offset = -1; struct vgic_irq *irq; int ret; + u8 val; list_for_each_entry(irq, &dist->lpi_list_head, lpi_list) { int byte_offset, bit_nr; struct kvm_vcpu *vcpu; gpa_t pendbase, ptr; bool stored; - u8 val; vcpu = irq->target_vcpu; if (!vcpu) Patches currently in stable-queue which might be from marc.zyngier(a)arm.com are queue-4.14/arm-kvm-fix-vttbr_baddr_mask-bug_on-off-by-one.patch queue-4.14/kvm-arm-arm64-vgic-its-check-result-of-allocation-before-use.patch queue-4.14/kvm-arm-arm64-vgic-preserve-the-revious-read-from-the-pending-table.patch queue-4.14/kvm-arm-arm64-vgic-irqfd-fix-msi-entry-allocation.patch queue-4.14/bus-arm-cci-fix-use-of-smp_processor_id-in-preemptible-context.patch queue-4.14/arm64-kvm-fix-vttbr_baddr_mask-bug_on-off-by-one.patch queue-4.14/bus-arm-ccn-fix-use-of-smp_processor_id-in-preemptible-context.patch

6 years, 9 months

1
0
0 0

[Linux-stable-mirror] Patch "KVM: arm/arm64: vgic-its: Check result of allocation before use" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled KVM: arm/arm64: vgic-its: Check result of allocation before use to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: kvm-arm-arm64-vgic-its-check-result-of-allocation-before-use.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 686f294f2f1ae40705283dd413ca1e4c14f20f93 Mon Sep 17 00:00:00 2001 From: Marc Zyngier <marc.zyngier(a)arm.com> Date: Thu, 16 Nov 2017 17:58:18 +0000 Subject: KVM: arm/arm64: vgic-its: Check result of allocation before use From: Marc Zyngier <marc.zyngier(a)arm.com> commit 686f294f2f1ae40705283dd413ca1e4c14f20f93 upstream. We miss a test against NULL after allocation. Fixes: 6d03a68f8054 ("KVM: arm64: vgic-its: Turn device_id validation into generic ID validation") Reported-by: AKASHI Takahiro <takahiro.akashi(a)linaro.org> Acked-by: Christoffer Dall <christoffer.dall(a)linaro.org> Signed-off-by: Marc Zyngier <marc.zyngier(a)arm.com> Signed-off-by: Christoffer Dall <christoffer.dall(a)linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- virt/kvm/arm/vgic/vgic-its.c | 2 ++ 1 file changed, 2 insertions(+) --- a/virt/kvm/arm/vgic/vgic-its.c +++ b/virt/kvm/arm/vgic/vgic-its.c @@ -775,6 +775,8 @@ static int vgic_its_alloc_collection(str return E_ITS_MAPC_COLLECTION_OOR; collection = kzalloc(sizeof(*collection), GFP_KERNEL); + if (!collection) + return -ENOMEM; collection->collection_id = coll_id; collection->target_addr = COLLECTION_NOT_MAPPED; Patches currently in stable-queue which might be from marc.zyngier(a)arm.com are queue-4.14/arm-kvm-fix-vttbr_baddr_mask-bug_on-off-by-one.patch queue-4.14/kvm-arm-arm64-vgic-its-check-result-of-allocation-before-use.patch queue-4.14/kvm-arm-arm64-vgic-preserve-the-revious-read-from-the-pending-table.patch queue-4.14/kvm-arm-arm64-vgic-irqfd-fix-msi-entry-allocation.patch queue-4.14/bus-arm-cci-fix-use-of-smp_processor_id-in-preemptible-context.patch queue-4.14/arm64-kvm-fix-vttbr_baddr_mask-bug_on-off-by-one.patch queue-4.14/bus-arm-ccn-fix-use-of-smp_processor_id-in-preemptible-context.patch

6 years, 9 months

1
0
0 0

[Linux-stable-mirror] Patch "KVM: arm/arm64: vgic-irqfd: Fix MSI entry allocation" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled KVM: arm/arm64: vgic-irqfd: Fix MSI entry allocation to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: kvm-arm-arm64-vgic-irqfd-fix-msi-entry-allocation.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 150009e2c70cc3c6e97f00e7595055765d32fb85 Mon Sep 17 00:00:00 2001 From: Marc Zyngier <marc.zyngier(a)arm.com> Date: Thu, 16 Nov 2017 17:58:15 +0000 Subject: KVM: arm/arm64: vgic-irqfd: Fix MSI entry allocation From: Marc Zyngier <marc.zyngier(a)arm.com> commit 150009e2c70cc3c6e97f00e7595055765d32fb85 upstream. Using the size of the structure we're allocating is a good idea and avoids any surprise... In this case, we're happilly confusing kvm_kernel_irq_routing_entry and kvm_irq_routing_entry... Fixes: 95b110ab9a09 ("KVM: arm/arm64: Enable irqchip routing") Reported-by: AKASHI Takahiro <takahiro.akashi(a)linaro.org> Reviewed-by: Christoffer Dall <christoffer.dall(a)linaro.org> Signed-off-by: Marc Zyngier <marc.zyngier(a)arm.com> Signed-off-by: Christoffer Dall <christoffer.dall(a)linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- virt/kvm/arm/vgic/vgic-irqfd.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) --- a/virt/kvm/arm/vgic/vgic-irqfd.c +++ b/virt/kvm/arm/vgic/vgic-irqfd.c @@ -112,8 +112,7 @@ int kvm_vgic_setup_default_irq_routing(s u32 nr = dist->nr_spis; int i, ret; - entries = kcalloc(nr, sizeof(struct kvm_kernel_irq_routing_entry), - GFP_KERNEL); + entries = kcalloc(nr, sizeof(*entries), GFP_KERNEL); if (!entries) return -ENOMEM; Patches currently in stable-queue which might be from marc.zyngier(a)arm.com are queue-4.14/arm-kvm-fix-vttbr_baddr_mask-bug_on-off-by-one.patch queue-4.14/kvm-arm-arm64-vgic-its-check-result-of-allocation-before-use.patch queue-4.14/kvm-arm-arm64-vgic-preserve-the-revious-read-from-the-pending-table.patch queue-4.14/kvm-arm-arm64-vgic-irqfd-fix-msi-entry-allocation.patch queue-4.14/bus-arm-cci-fix-use-of-smp_processor_id-in-preemptible-context.patch queue-4.14/arm64-kvm-fix-vttbr_baddr_mask-bug_on-off-by-one.patch queue-4.14/bus-arm-ccn-fix-use-of-smp_processor_id-in-preemptible-context.patch

6 years, 9 months

1
0
0 0

[Linux-stable-mirror] Patch "KVM: arm/arm64: Fix broken GICH_ELRSR big endian conversion" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled KVM: arm/arm64: Fix broken GICH_ELRSR big endian conversion to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: kvm-arm-arm64-fix-broken-gich_elrsr-big-endian-conversion.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From fc396e066318c0a02208c1d3f0b62950a7714999 Mon Sep 17 00:00:00 2001 From: Christoffer Dall <christoffer.dall(a)linaro.org> Date: Sun, 3 Dec 2017 23:54:41 +0100 Subject: KVM: arm/arm64: Fix broken GICH_ELRSR big endian conversion From: Christoffer Dall <christoffer.dall(a)linaro.org> commit fc396e066318c0a02208c1d3f0b62950a7714999 upstream. We are incorrectly rearranging 32-bit words inside a 64-bit typed value for big endian systems, which would result in never marking a virtual interrupt as inactive on big endian systems (assuming 32 or fewer LRs on the hardware). Fix this by not doing any word order manipulation for the typed values. Acked-by: Christoffer Dall <christoffer.dall(a)linaro.org> Signed-off-by: Christoffer Dall <christoffer.dall(a)linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- virt/kvm/arm/hyp/vgic-v2-sr.c | 4 ---- 1 file changed, 4 deletions(-) --- a/virt/kvm/arm/hyp/vgic-v2-sr.c +++ b/virt/kvm/arm/hyp/vgic-v2-sr.c @@ -34,11 +34,7 @@ static void __hyp_text save_elrsr(struct else elrsr1 = 0; -#ifdef CONFIG_CPU_BIG_ENDIAN - cpu_if->vgic_elrsr = ((u64)elrsr0 << 32) | elrsr1; -#else cpu_if->vgic_elrsr = ((u64)elrsr1 << 32) | elrsr0; -#endif } static void __hyp_text save_lrs(struct kvm_vcpu *vcpu, void __iomem *base) Patches currently in stable-queue which might be from christoffer.dall(a)linaro.org are queue-4.14/arm-kvm-fix-vttbr_baddr_mask-bug_on-off-by-one.patch queue-4.14/kvm-arm-arm64-fix-broken-gich_elrsr-big-endian-conversion.patch queue-4.14/kvm-arm-arm64-vgic-its-check-result-of-allocation-before-use.patch queue-4.14/kvm-arm-arm64-vgic-preserve-the-revious-read-from-the-pending-table.patch queue-4.14/kvm-arm-arm64-vgic-irqfd-fix-msi-entry-allocation.patch queue-4.14/arm64-kvm-fix-vttbr_baddr_mask-bug_on-off-by-one.patch

6 years, 9 months

1
0
0 0

[Linux-stable-mirror] Patch "KEYS: reject NULL restriction string when type is specified" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled KEYS: reject NULL restriction string when type is specified to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: keys-reject-null-restriction-string-when-type-is-specified.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 18026d866801d0c52e5550210563222bd6c7191d Mon Sep 17 00:00:00 2001 From: Eric Biggers <ebiggers(a)google.com> Date: Fri, 8 Dec 2017 15:13:29 +0000 Subject: KEYS: reject NULL restriction string when type is specified From: Eric Biggers <ebiggers(a)google.com> commit 18026d866801d0c52e5550210563222bd6c7191d upstream. keyctl_restrict_keyring() allows through a NULL restriction when the "type" is non-NULL, which causes a NULL pointer dereference in asymmetric_lookup_restriction() when it calls strcmp() on the restriction string. But no key types actually use a "NULL restriction" to mean anything, so update keyctl_restrict_keyring() to reject it with EINVAL. Reported-by: syzbot <syzkaller(a)googlegroups.com> Fixes: 97d3aa0f3134 ("KEYS: Add a lookup_restriction function for the asymmetric key type") Signed-off-by: Eric Biggers <ebiggers(a)google.com> Signed-off-by: David Howells <dhowells(a)redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- security/keys/keyctl.c | 24 ++++++++++-------------- 1 file changed, 10 insertions(+), 14 deletions(-) --- a/security/keys/keyctl.c +++ b/security/keys/keyctl.c @@ -1588,9 +1588,8 @@ error_keyring: * The caller must have Setattr permission to change keyring restrictions. * * The requested type name may be a NULL pointer to reject all attempts - * to link to the keyring. If _type is non-NULL, _restriction can be - * NULL or a pointer to a string describing the restriction. If _type is - * NULL, _restriction must also be NULL. + * to link to the keyring. In this case, _restriction must also be NULL. + * Otherwise, both _type and _restriction must be non-NULL. * * Returns 0 if successful. */ @@ -1598,7 +1597,6 @@ long keyctl_restrict_keyring(key_serial_ const char __user *_restriction) { key_ref_t key_ref; - bool link_reject = !_type; char type[32]; char *restriction = NULL; long ret; @@ -1607,31 +1605,29 @@ long keyctl_restrict_keyring(key_serial_ if (IS_ERR(key_ref)) return PTR_ERR(key_ref); + ret = -EINVAL; if (_type) { + if (!_restriction) + goto error; + ret = key_get_type_from_user(type, _type, sizeof(type)); if (ret < 0) goto error; - } - - if (_restriction) { - if (!_type) { - ret = -EINVAL; - goto error; - } restriction = strndup_user(_restriction, PAGE_SIZE); if (IS_ERR(restriction)) { ret = PTR_ERR(restriction); goto error; } + } else { + if (_restriction) + goto error; } - ret = keyring_restrict(key_ref, link_reject ? NULL : type, restriction); + ret = keyring_restrict(key_ref, _type ? type : NULL, restriction); kfree(restriction); - error: key_ref_put(key_ref); - return ret; } Patches currently in stable-queue which might be from ebiggers(a)google.com are queue-4.14/x.509-reject-invalid-bit-string-for-subjectpublickey.patch queue-4.14/asn.1-check-for-error-from-asn1_op_end__act-actions.patch queue-4.14/keys-add-missing-permission-check-for-request_key-destination.patch queue-4.14/asn.1-fix-out-of-bounds-read-when-parsing-indefinite-length-item.patch queue-4.14/keys-reject-null-restriction-string-when-type-is-specified.patch queue-4.14/x.509-fix-comparisons-of-pkey_algo.patch

6 years, 9 months

1
0
0 0

[Linux-stable-mirror] Patch "KEYS: add missing permission check for request_key() destination" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled KEYS: add missing permission check for request_key() destination to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: keys-add-missing-permission-check-for-request_key-destination.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 4dca6ea1d9432052afb06baf2e3ae78188a4410b Mon Sep 17 00:00:00 2001 From: Eric Biggers <ebiggers(a)google.com> Date: Fri, 8 Dec 2017 15:13:27 +0000 Subject: KEYS: add missing permission check for request_key() destination From: Eric Biggers <ebiggers(a)google.com> commit 4dca6ea1d9432052afb06baf2e3ae78188a4410b upstream. When the request_key() syscall is not passed a destination keyring, it links the requested key (if constructed) into the "default" request-key keyring. This should require Write permission to the keyring. However, there is actually no permission check. This can be abused to add keys to any keyring to which only Search permission is granted. This is because Search permission allows joining the keyring. keyctl_set_reqkey_keyring(KEY_REQKEY_DEFL_SESSION_KEYRING) then will set the default request-key keyring to the session keyring. Then, request_key() can be used to add keys to the keyring. Both negatively and positively instantiated keys can be added using this method. Adding negative keys is trivial. Adding a positive key is a bit trickier. It requires that either /sbin/request-key positively instantiates the key, or that another thread adds the key to the process keyring at just the right time, such that request_key() misses it initially but then finds it in construct_alloc_key(). Fix this bug by checking for Write permission to the keyring in construct_get_dest_keyring() when the default keyring is being used. We don't do the permission check for non-default keyrings because that was already done by the earlier call to lookup_user_key(). Also, request_key_and_link() is currently passed a 'struct key *' rather than a key_ref_t, so the "possessed" bit is unavailable. We also don't do the permission check for the "requestor keyring", to continue to support the use case described by commit 8bbf4976b59f ("KEYS: Alter use of key instantiation link-to-keyring argument") where /sbin/request-key recursively calls request_key() to add keys to the original requestor's destination keyring. (I don't know of any users who actually do that, though...) Fixes: 3e30148c3d52 ("[PATCH] Keys: Make request-key create an authorisation key") Signed-off-by: Eric Biggers <ebiggers(a)google.com> Signed-off-by: David Howells <dhowells(a)redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- security/keys/request_key.c | 46 +++++++++++++++++++++++++++++++++++--------- 1 file changed, 37 insertions(+), 9 deletions(-) --- a/security/keys/request_key.c +++ b/security/keys/request_key.c @@ -251,11 +251,12 @@ static int construct_key(struct key *key * The keyring selected is returned with an extra reference upon it which the * caller must release. */ -static void construct_get_dest_keyring(struct key **_dest_keyring) +static int construct_get_dest_keyring(struct key **_dest_keyring) { struct request_key_auth *rka; const struct cred *cred = current_cred(); struct key *dest_keyring = *_dest_keyring, *authkey; + int ret; kenter("%p", dest_keyring); @@ -264,6 +265,8 @@ static void construct_get_dest_keyring(s /* the caller supplied one */ key_get(dest_keyring); } else { + bool do_perm_check = true; + /* use a default keyring; falling through the cases until we * find one that we actually have */ switch (cred->jit_keyring) { @@ -278,8 +281,10 @@ static void construct_get_dest_keyring(s dest_keyring = key_get(rka->dest_keyring); up_read(&authkey->sem); - if (dest_keyring) + if (dest_keyring) { + do_perm_check = false; break; + } } case KEY_REQKEY_DEFL_THREAD_KEYRING: @@ -314,11 +319,29 @@ static void construct_get_dest_keyring(s default: BUG(); } + + /* + * Require Write permission on the keyring. This is essential + * because the default keyring may be the session keyring, and + * joining a keyring only requires Search permission. + * + * However, this check is skipped for the "requestor keyring" so + * that /sbin/request-key can itself use request_key() to add + * keys to the original requestor's destination keyring. + */ + if (dest_keyring && do_perm_check) { + ret = key_permission(make_key_ref(dest_keyring, 1), + KEY_NEED_WRITE); + if (ret) { + key_put(dest_keyring); + return ret; + } + } } *_dest_keyring = dest_keyring; kleave(" [dk %d]", key_serial(dest_keyring)); - return; + return 0; } /* @@ -444,11 +467,15 @@ static struct key *construct_key_and_lin if (ctx->index_key.type == &key_type_keyring) return ERR_PTR(-EPERM); - user = key_user_lookup(current_fsuid()); - if (!user) - return ERR_PTR(-ENOMEM); + ret = construct_get_dest_keyring(&dest_keyring); + if (ret) + goto error; - construct_get_dest_keyring(&dest_keyring); + user = key_user_lookup(current_fsuid()); + if (!user) { + ret = -ENOMEM; + goto error_put_dest_keyring; + } ret = construct_alloc_key(ctx, dest_keyring, flags, user, &key); key_user_put(user); @@ -463,7 +490,7 @@ static struct key *construct_key_and_lin } else if (ret == -EINPROGRESS) { ret = 0; } else { - goto couldnt_alloc_key; + goto error_put_dest_keyring; } key_put(dest_keyring); @@ -473,8 +500,9 @@ static struct key *construct_key_and_lin construction_failed: key_negate_and_link(key, key_negative_timeout, NULL, NULL); key_put(key); -couldnt_alloc_key: +error_put_dest_keyring: key_put(dest_keyring); +error: kleave(" = %d", ret); return ERR_PTR(ret); } Patches currently in stable-queue which might be from ebiggers(a)google.com are queue-4.14/x.509-reject-invalid-bit-string-for-subjectpublickey.patch queue-4.14/asn.1-check-for-error-from-asn1_op_end__act-actions.patch queue-4.14/keys-add-missing-permission-check-for-request_key-destination.patch queue-4.14/asn.1-fix-out-of-bounds-read-when-parsing-indefinite-length-item.patch queue-4.14/keys-reject-null-restriction-string-when-type-is-specified.patch queue-4.14/x.509-fix-comparisons-of-pkey_algo.patch

6 years, 9 months

1
0
0 0

[Linux-stable-mirror] Patch "kdb: Fix handling of kallsyms_symbol_next() return value" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled kdb: Fix handling of kallsyms_symbol_next() return value to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: kdb-fix-handling-of-kallsyms_symbol_next-return-value.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From c07d35338081d107e57cf37572d8cc931a8e32e2 Mon Sep 17 00:00:00 2001 From: Daniel Thompson <daniel.thompson(a)linaro.org> Date: Mon, 2 Mar 2015 14:13:36 +0000 Subject: kdb: Fix handling of kallsyms_symbol_next() return value From: Daniel Thompson <daniel.thompson(a)linaro.org> commit c07d35338081d107e57cf37572d8cc931a8e32e2 upstream. kallsyms_symbol_next() returns a boolean (true on success). Currently kdb_read() tests the return value with an inequality that unconditionally evaluates to true. This is fixed in the obvious way and, since the conditional branch is supposed to be unreachable, we also add a WARN_ON(). Reported-by: Dan Carpenter <dan.carpenter(a)oracle.com> Signed-off-by: Daniel Thompson <daniel.thompson(a)linaro.org> Signed-off-by: Jason Wessel <jason.wessel(a)windriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- kernel/debug/kdb/kdb_io.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/kernel/debug/kdb/kdb_io.c +++ b/kernel/debug/kdb/kdb_io.c @@ -350,7 +350,7 @@ poll_again: } kdb_printf("\n"); for (i = 0; i < count; i++) { - if (kallsyms_symbol_next(p_tmp, i) < 0) + if (WARN_ON(!kallsyms_symbol_next(p_tmp, i))) break; kdb_printf("%s ", p_tmp); *(p_tmp + len) = '\0'; Patches currently in stable-queue which might be from daniel.thompson(a)linaro.org are queue-4.14/kdb-fix-handling-of-kallsyms_symbol_next-return-value.patch

6 years, 9 months

1
0
0 0

[Linux-stable-mirror] Patch "iwlwifi: mvm: mark MIC stripped MPDUs" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled iwlwifi: mvm: mark MIC stripped MPDUs to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: iwlwifi-mvm-mark-mic-stripped-mpdus.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From bf19037074e770aad74b3b90f37b8b98db3f3748 Mon Sep 17 00:00:00 2001 From: Sara Sharon <sara.sharon(a)intel.com> Date: Mon, 8 Feb 2016 23:30:47 +0200 Subject: iwlwifi: mvm: mark MIC stripped MPDUs From: Sara Sharon <sara.sharon(a)intel.com> commit bf19037074e770aad74b3b90f37b8b98db3f3748 upstream. When RADA is active, the hardware decrypts the packets and strips off the MIC as it is useless after decryption. Indicate that to mac80211. [this is needed for the 9000-series HW to work properly] Signed-off-by: Sara Sharon <sara.sharon(a)intel.com> Signed-off-by: Luca Coelho <luciano.coelho(a)intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c | 2 ++ 1 file changed, 2 insertions(+) --- a/drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c +++ b/drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c @@ -253,6 +253,8 @@ static int iwl_mvm_rx_crypto(struct iwl_ return -1; stats->flag |= RX_FLAG_DECRYPTED; + if (pkt_flags & FH_RSCSR_RADA_EN) + stats->flag |= RX_FLAG_MIC_STRIPPED; *crypt_len = IEEE80211_CCMP_HDR_LEN; return 0; case IWL_RX_MPDU_STATUS_SEC_TKIP: Patches currently in stable-queue which might be from sara.sharon(a)intel.com are queue-4.14/iwlwifi-mvm-mark-mic-stripped-mpdus.patch

6 years, 9 months

1
0
0 0

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror