In the Linux kernel, the following vulnerability has been resolved:

crypto: arm64/poly1305 - fix a read out-of-bound

A kasan error was reported during fuzzing:

BUG: KASAN: slab-out-of-bounds in neonpoly1305blocks.constprop.0+0x1b4/0x250 [poly1305neon] 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: dumpbacktrace+0x0/0x394 showstack+0x34/0x4c arch/arm64/kernel/stacktrace.c:196 _dumpstack lib/dumpstack.c:77 [inline] dumpstack+0x158/0x1e4 lib/dumpstack.c:118 printaddressdescription.constprop.0+0x68/0x204 mm/kasan/report.c:387 _kasanreport+0xe0/0x140 mm/kasan/report.c:547 kasanreport+0x44/0xe0 mm/kasan/report.c:564 checkmemoryregioninline mm/kasan/generic.c:187 [inline] _asanload4+0x94/0xd0 mm/kasan/generic.c:252 neonpoly1305blocks.constprop.0+0x1b4/0x250 [poly1305neon] neonpoly1305doupdate+0x6c/0x15c [poly1305neon] neonpoly1305update+0x9c/0x1c4 [poly1305neon] cryptoshashupdate crypto/shash.c:131 [inline] shashfinupunaligned+0x84/0x15c crypto/shash.c:179 cryptoshashfinup+0x8c/0x140 crypto/shash.c:193 shashdigestunaligned+0xb8/0xe4 crypto/shash.c:201 cryptoshashdigest+0xa4/0xfc crypto/shash.c:217 cryptoshashtfmdigest+0xb4/0x150 crypto/shash.c:229 essivskciphersetkey+0x164/0x200 [essiv] cryptoskciphersetkey+0xb0/0x160 crypto/skcipher.c:612 skciphersetkey+0x3c/0x50 crypto/algifskcipher.c:305 algsetkey+0x114/0x2a0 crypto/afalg.c:220 algsetsockopt+0x19c/0x210 crypto/afalg.c:253 _syssetsockopt+0x190/0x2e0 net/socket.c:2123 _dosyssetsockopt net/socket.c:2134 [inline] _sesyssetsockopt net/socket.c:2131 [inline] _arm64syssetsockopt+0x78/0x94 net/socket.c:2131 _invokesyscall arch/arm64/kernel/syscall.c:36 [inline] invokesyscall+0x64/0x100 arch/arm64/kernel/syscall.c:48 el0svccommon.constprop.0+0x220/0x230 arch/arm64/kernel/syscall.c:155 doel0svc+0xb4/0xd4 arch/arm64/kernel/syscall.c:217 el0svc+0x24/0x3c arch/arm64/kernel/entry-common.c:353 el0synchandler+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) { }

moduleinit(init) moduleexit(deinit) MODULE_LICENSE("GPL");

The root cause of the bug sits in neonpoly1305blocks. The logic neonpoly1305blocks() 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 poly1305initarch(), 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 poly1305initarm64() instead o ---truncated---