public inbox for stable@vger.kernel.org
 help / color / mirror / Atom feed
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: linux-kernel@vger.kernel.org
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	stable@vger.kernel.org, GUO Zihua <guozihua@huawei.com>,
	Eric Biggers <ebiggers@google.com>, Will Deacon <will@kernel.org>,
	Herbert Xu <herbert@gondor.apana.org.au>
Subject: [PATCH 5.18 07/35] crypto: arm64/poly1305 - fix a read out-of-bound
Date: Tue,  9 Aug 2022 20:00:36 +0200	[thread overview]
Message-ID: <20220809175515.340186939@linuxfoundation.org> (raw)
In-Reply-To: <20220809175515.046484486@linuxfoundation.org>

From: GUO Zihua <guozihua@huawei.com>

commit 7ae19d422c7da84b5f13bc08b98bd737a08d3a53 upstream.

A kasan error was reported during fuzzing:

BUG: KASAN: slab-out-of-bounds in neon_poly1305_blocks.constprop.0+0x1b4/0x250 [poly1305_neon]
Read of size 4 at addr ffff0010e293f010 by task syz-executor.5/1646715
CPU: 4 PID: 1646715 Comm: syz-executor.5 Kdump: loaded Not tainted 5.10.0.aarch64 #1
Hardware name: Huawei TaiShan 2280 /BC11SPCD, BIOS 1.59 01/31/2019
Call trace:
 dump_backtrace+0x0/0x394
 show_stack+0x34/0x4c arch/arm64/kernel/stacktrace.c:196
 __dump_stack lib/dump_stack.c:77 [inline]
 dump_stack+0x158/0x1e4 lib/dump_stack.c:118
 print_address_description.constprop.0+0x68/0x204 mm/kasan/report.c:387
 __kasan_report+0xe0/0x140 mm/kasan/report.c:547
 kasan_report+0x44/0xe0 mm/kasan/report.c:564
 check_memory_region_inline mm/kasan/generic.c:187 [inline]
 __asan_load4+0x94/0xd0 mm/kasan/generic.c:252
 neon_poly1305_blocks.constprop.0+0x1b4/0x250 [poly1305_neon]
 neon_poly1305_do_update+0x6c/0x15c [poly1305_neon]
 neon_poly1305_update+0x9c/0x1c4 [poly1305_neon]
 crypto_shash_update crypto/shash.c:131 [inline]
 shash_finup_unaligned+0x84/0x15c crypto/shash.c:179
 crypto_shash_finup+0x8c/0x140 crypto/shash.c:193
 shash_digest_unaligned+0xb8/0xe4 crypto/shash.c:201
 crypto_shash_digest+0xa4/0xfc crypto/shash.c:217
 crypto_shash_tfm_digest+0xb4/0x150 crypto/shash.c:229
 essiv_skcipher_setkey+0x164/0x200 [essiv]
 crypto_skcipher_setkey+0xb0/0x160 crypto/skcipher.c:612
 skcipher_setkey+0x3c/0x50 crypto/algif_skcipher.c:305
 alg_setkey+0x114/0x2a0 crypto/af_alg.c:220
 alg_setsockopt+0x19c/0x210 crypto/af_alg.c:253
 __sys_setsockopt+0x190/0x2e0 net/socket.c:2123
 __do_sys_setsockopt net/socket.c:2134 [inline]
 __se_sys_setsockopt net/socket.c:2131 [inline]
 __arm64_sys_setsockopt+0x78/0x94 net/socket.c:2131
 __invoke_syscall arch/arm64/kernel/syscall.c:36 [inline]
 invoke_syscall+0x64/0x100 arch/arm64/kernel/syscall.c:48
 el0_svc_common.constprop.0+0x220/0x230 arch/arm64/kernel/syscall.c:155
 do_el0_svc+0xb4/0xd4 arch/arm64/kernel/syscall.c:217
 el0_svc+0x24/0x3c arch/arm64/kernel/entry-common.c:353
 el0_sync_handler+0x160/0x164 arch/arm64/kernel/entry-common.c:369
 el0_sync+0x160/0x180 arch/arm64/kernel/entry.S:683

This error can be reproduced by the following code compiled as ko on a
system with kasan enabled:

#include <linux/module.h>
#include <linux/crypto.h>
#include <crypto/hash.h>
#include <crypto/poly1305.h>

char test_data[] = "\x00\x01\x02\x03\x04\x05\x06\x07"
                   "\x08\x09\x0a\x0b\x0c\x0d\x0e\x0f"
                   "\x10\x11\x12\x13\x14\x15\x16\x17"
                   "\x18\x19\x1a\x1b\x1c\x1d\x1e";

int init(void)
{
        struct crypto_shash *tfm = NULL;
        char *data = NULL, *out = NULL;

        tfm = crypto_alloc_shash("poly1305", 0, 0);
        data = kmalloc(POLY1305_KEY_SIZE - 1, GFP_KERNEL);
        out = kmalloc(POLY1305_DIGEST_SIZE, GFP_KERNEL);
        memcpy(data, test_data, POLY1305_KEY_SIZE - 1);
        crypto_shash_tfm_digest(tfm, data, POLY1305_KEY_SIZE - 1, out);

        kfree(data);
        kfree(out);
        return 0;
}

void deinit(void)
{
}

module_init(init)
module_exit(deinit)
MODULE_LICENSE("GPL");

The root cause of the bug sits in neon_poly1305_blocks. The logic
neon_poly1305_blocks() performed is that if it was called with both s[]
and r[] uninitialized, it will first try to initialize them with the
data from the first "block" that it believed to be 32 bytes in length.
First 16 bytes are used as the key and the next 16 bytes for s[]. This
would lead to the aforementioned read out-of-bound. However, after
calling poly1305_init_arch(), only 16 bytes were deducted from the input
and s[] is initialized yet again with the following 16 bytes. The second
initialization of s[] is certainly redundent which indicates that the
first initialization should be for r[] only.

This patch fixes the issue by calling poly1305_init_arm64() instead of
poly1305_init_arch(). This is also the implementation for the same
algorithm on arm platform.

Fixes: f569ca164751 ("crypto: arm64/poly1305 - incorporate OpenSSL/CRYPTOGAMS NEON implementation")
Cc: stable@vger.kernel.org
Signed-off-by: GUO Zihua <guozihua@huawei.com>
Reviewed-by: Eric Biggers <ebiggers@google.com>
Acked-by: Will Deacon <will@kernel.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 arch/arm64/crypto/poly1305-glue.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/arch/arm64/crypto/poly1305-glue.c
+++ b/arch/arm64/crypto/poly1305-glue.c
@@ -52,7 +52,7 @@ static void neon_poly1305_blocks(struct
 {
 	if (unlikely(!dctx->sset)) {
 		if (!dctx->rset) {
-			poly1305_init_arch(dctx, src);
+			poly1305_init_arm64(&dctx->h, src);
 			src += POLY1305_BLOCK_SIZE;
 			len -= POLY1305_BLOCK_SIZE;
 			dctx->rset = 1;



  parent reply	other threads:[~2022-08-09 18:19 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-09 18:00 [PATCH 5.18 00/35] 5.18.17-rc1 review Greg Kroah-Hartman
2022-08-09 18:00 ` [PATCH 5.18 01/35] x86/speculation: Make all RETbleed mitigations 64-bit only Greg Kroah-Hartman
2022-08-09 18:00 ` [PATCH 5.18 02/35] block: fix default IO priority handling again Greg Kroah-Hartman
2022-08-09 18:00 ` [PATCH 5.18 03/35] tools/vm/slabinfo: Handle files in debugfs Greg Kroah-Hartman
2022-08-09 18:00 ` [PATCH 5.18 04/35] ACPI: video: Force backlight native for some TongFang devices Greg Kroah-Hartman
2022-08-09 18:00 ` [PATCH 5.18 05/35] ACPI: video: Shortening quirk list by identifying Clevo by board_name only Greg Kroah-Hartman
2022-08-09 18:00 ` [PATCH 5.18 06/35] ACPI: APEI: Better fix to avoid spamming the console with old error logs Greg Kroah-Hartman
2022-08-09 18:00 ` Greg Kroah-Hartman [this message]
2022-08-09 18:00 ` [PATCH 5.18 08/35] KVM: x86: do not report a vCPU as preempted outside instruction boundaries Greg Kroah-Hartman
2022-08-09 18:00 ` [PATCH 5.18 09/35] KVM: x86: do not set st->preempted when going back to user space Greg Kroah-Hartman
2022-08-09 18:00 ` [PATCH 5.18 10/35] KVM: selftests: Make hyperv_clock selftest more stable Greg Kroah-Hartman
2022-08-09 18:00 ` [PATCH 5.18 11/35] KVM: x86/MMU: Zap non-leaf SPTEs when disabling dirty logging Greg Kroah-Hartman
2022-08-09 18:00 ` [PATCH 5.18 12/35] entry/kvm: Exit to user mode when TIF_NOTIFY_SIGNAL is set Greg Kroah-Hartman
2022-08-09 18:00 ` [PATCH 5.18 13/35] KVM: x86: disable preemption while updating apicv inhibition Greg Kroah-Hartman
2022-08-09 18:00 ` [PATCH 5.18 14/35] KVM: x86: disable preemption around the call to kvm_arch_vcpu_{un|}blocking Greg Kroah-Hartman
2022-08-09 18:00 ` [PATCH 5.18 15/35] KVM: selftests: Restrict test region to 48-bit physical addresses when using nested Greg Kroah-Hartman
2022-08-09 18:00 ` [PATCH 5.18 16/35] tools/kvm_stat: fix display of error when multiple processes are found Greg Kroah-Hartman
2022-08-09 18:00 ` [PATCH 5.18 17/35] selftests: KVM: Handle compiler optimizations in ucall Greg Kroah-Hartman
2022-08-09 18:00 ` [PATCH 5.18 18/35] KVM: x86/svm: add __GFP_ACCOUNT to __sev_dbg_{en,de}crypt_user() Greg Kroah-Hartman
2022-08-09 18:00 ` [PATCH 5.18 19/35] arm64: set UXN on swapper page tables Greg Kroah-Hartman
2022-08-09 18:00 ` [PATCH 5.18 20/35] btrfs: zoned: prevent allocation from previous data relocation BG Greg Kroah-Hartman
2022-08-09 18:00 ` [PATCH 5.18 21/35] btrfs: zoned: fix critical section of relocation inode writeback Greg Kroah-Hartman
2022-08-09 18:00 ` [PATCH 5.18 22/35] btrfs: zoned: drop optimization of zone finish Greg Kroah-Hartman
2022-08-09 18:00 ` [PATCH 5.18 23/35] Bluetooth: hci_qca: Return wakeup for qca_wakeup Greg Kroah-Hartman
2022-08-09 18:00 ` [PATCH 5.18 24/35] Bluetooth: hci_bcm: Add BCM4349B1 variant Greg Kroah-Hartman
2022-08-09 18:00 ` [PATCH 5.18 25/35] Bluetooth: hci_bcm: Add DT compatible for CYW55572 Greg Kroah-Hartman
2022-08-09 18:00 ` [PATCH 5.18 26/35] dt-bindings: bluetooth: broadcom: Add BCM4349B1 DT binding Greg Kroah-Hartman
2022-08-09 18:00 ` [PATCH 5.18 27/35] Bluetooth: btusb: Add support of IMC Networks PID 0x3568 Greg Kroah-Hartman
2022-08-09 18:00 ` [PATCH 5.18 28/35] Bluetooth: btusb: Add Realtek RTL8852C support ID 0x04CA:0x4007 Greg Kroah-Hartman
2022-08-09 18:00 ` [PATCH 5.18 29/35] Bluetooth: btusb: Add Realtek RTL8852C support ID 0x04C5:0x1675 Greg Kroah-Hartman
2022-08-09 18:00 ` [PATCH 5.18 30/35] Bluetooth: btusb: Add Realtek RTL8852C support ID 0x0CB8:0xC558 Greg Kroah-Hartman
2022-08-09 18:01 ` [PATCH 5.18 31/35] Bluetooth: btusb: Add Realtek RTL8852C support ID 0x13D3:0x3587 Greg Kroah-Hartman
2022-08-09 18:01 ` [PATCH 5.18 32/35] Bluetooth: btusb: Add Realtek RTL8852C support ID 0x13D3:0x3586 Greg Kroah-Hartman
2022-08-09 18:01 ` [PATCH 5.18 33/35] macintosh/adb: fix oob read in do_adb_query() function Greg Kroah-Hartman
2022-08-09 18:01 ` [PATCH 5.18 34/35] x86/speculation: Add RSB VM Exit protections Greg Kroah-Hartman
2022-08-09 18:01 ` [PATCH 5.18 35/35] x86/speculation: Add LFENCE to RSB fill sequence Greg Kroah-Hartman
2022-08-09 21:47 ` [PATCH 5.18 00/35] 5.18.17-rc1 review Florian Fainelli
2022-08-10  6:16 ` Naresh Kamboju
2022-08-10 12:54 ` Ron Economos
2022-08-10 13:26 ` Sudip Mukherjee (Codethink)
2022-08-10 13:33 ` Guenter Roeck
2022-08-10 14:17 ` Justin Forbes
2022-08-10 14:25 ` Jon Hunter
2022-08-10 14:31 ` Shuah Khan

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=20220809175515.340186939@linuxfoundation.org \
    --to=gregkh@linuxfoundation.org \
    --cc=ebiggers@google.com \
    --cc=guozihua@huawei.com \
    --cc=herbert@gondor.apana.org.au \
    --cc=linux-kernel@vger.kernel.org \
    --cc=stable@vger.kernel.org \
    --cc=will@kernel.org \
    /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