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()函数的实现发现以下事实：

该函数调用时会保证入参>= 16字节。
该函数开头首先检查了s[]是否初始化，如果没有的话检查r[]是否初始化。在r[]未初始化时调用poly1305_init_arch()函数。
poly1305_init_arch()函数接受一个32字节的入参，并且调用了poly1305_init_arm64()函数，之后用后16字节入参对s[]进行了初始化。
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算法。
操作：

将提供的复现程序编译为ko。
插入到打开了KASAN的内核中。
查看dmesg日志是否有与poly1305-neon相关的read-out-of-bound打印。

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

Hi redtailbullet, welcome to the openEuler Community.
I'm the Bot here serving you. You can find the instructions on how to interact with me at Here.
If you have any questions, please contact the SIG: Kernel, and any of the maintainers: @YangYingliang , @成坚 (CHENG Jian) , @jiaoff , @zhengzengkai , @刘勇强 , @wangxiongfeng , @朱科潜 , @WangShaoBo , @lujialin , @wuxu_buque , @Xu Kuohai , @冷嘲啊 , @Lingmingqiang , @yuzenghui , @岳海兵 , @juntian , @OSSIM , @陈结松 , @whoisxxx , @koulihong , @刘恺 , @hanjun-guo , @woqidaideshi , @Chiqijun , @Kefeng , @ThunderTown , @AlexGuo , @kylin-mayukun , @Zheng Zucheng , @柳歆 , @Jackie Liu , @zhujianwei001 , @郑振鹏 , @SuperSix173 , @colyli , @Zhang Yi , @htforge , @Xie XiuQi

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