crypto: arm64/poly1305 - fix a read out-of-bound · Issue #I5MF5J · openEuler/kernel

【问题背景】

在进行fuzz测试时，poly1305_neon模块报告了以下问题：

```
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
```
该问题可以使用以下程序进行复现：
```
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");
```

其问题根因为neon_poly1305_blocks()函数调用了poly1305_init_arch()函数进行s[]和r[]的初始化。但是在调用时没有检查函数入参长度是否满足32字节的要求，导致poly1305_init_arch()函数读越界。

但是检查neon_poly1305_blocks()函数的实现发现以下事实：
1. 该函数调用时会保证入参>= 16字节。
2. 该函数开头首先检查了s[]是否初始化，如果没有的话检查r[]是否初始化。在r[]未初始化时调用poly1305_init_arch()函数。
3. poly1305_init_arch()函数接受一个32字节的入参，并且调用了poly1305_init_arm64()函数，之后**用后16字节入参对s[]进行了初始化**。
4. neon_poly1305_blocks()调用poly1305_init_arch()之后，只从入参中去掉了**16**字节。如果入参长度仍然大于16字节，会**再次进行s[]的初始化**。

涉及代码段如下：
```
 1 void poly1305_init_arch(struct poly1305_desc_ctx *dctx, const u8 key[POLY1305_KEY_SIZE])
 2 {
 3     poly1305_init_arm64(&dctx->h, key);
 4     dctx->s[0] = get_unaligned_le32(key + 16);    // 后16位初始化s[]
 5     dctx->s[1] = get_unaligned_le32(key + 20);
 6     dctx->s[2] = get_unaligned_le32(key + 24);
 7     dctx->s[3] = get_unaligned_le32(key + 28);
 8     dctx->buflen = 0;
 9 }

1 static void neon_poly1305_blocks(struct poly1305_desc_ctx *dctx, const u8 *src,
 2                  u32 len, u32 hibit, bool do_neon)
 3 {
 4     if (unlikely(!dctx->sset)) {
 5         if (!dctx->rset) {
 6             poly1305_init_arch(dctx, src);
 7             src += POLY1305_BLOCK_SIZE;
 8             len -= POLY1305_BLOCK_SIZE;    // 只从入参中减少了16位
 9             dctx->rset = 1;
10         }
11         if (len >= POLY1305_BLOCK_SIZE) {
12             dctx->s[0] = get_unaligned_le32(src +  0);    // 再次进行s[]的初始化
13             dctx->s[1] = get_unaligned_le32(src +  4);
14             dctx->s[2] = get_unaligned_le32(src +  8);
15             dctx->s[3] = get_unaligned_le32(src + 12);
16             src += POLY1305_BLOCK_SIZE;
17             len -= POLY1305_BLOCK_SIZE;
18             dctx->sset = true;
19         }
20         if (len < POLY1305_BLOCK_SIZE)
21             return;
22     }
23
24     len &= ~(POLY1305_BLOCK_SIZE - 1);
25
26     if (static_branch_likely(&have_neon) && likely(do_neon))
27         poly1305_blocks_neon(&dctx->h, src, len, hibit);
28     else
29         poly1305_blocks(&dctx->h, src, len, hibit);
30 }
```
这里有个很明显的问题：从代码分析，调用poly1305_init_arch()应当**只消耗16字节的入参**，同时应当是在r[]未初始化的情况下才会调用。而s[]的初始化是在poly1305_init_arch()的调用**后**进行的。因此，判断调用poly1305_init_arch()时实际上应当初始化r[]，s[]的初始化留给后面的流程。

【修复方法】

参考ARM平台的相同算法实现，将调用poly1305_init_arch()改为调用poly1305_init_arm64()进行r[]的初始化。

【测试方法】

前提：内核打开了KASAN，并且安装了poly1305-neon算法。
操作：
1. 将提供的复现程序编译为ko。
2. 插入到打开了KASAN的内核中。
3. 查看dmesg日志是否有与poly1305-neon相关的read-out-of-bound打印。

如果有打印则证明问题存在，没有打印则证明问题被修复。

GVP openEuler/kernel

内容风险标识

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

评论 (1)

GVPopenEuler/kernel

内容风险标识

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

评论 (1)

搜索帮助

GVP openEuler/kernel