CVE-2022-50231

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: arm64/poly1305 - fix a read out-of-bound<br /> <br /> A kasan error was reported during fuzzing:<br /> <br /> BUG: KASAN: slab-out-of-bounds in neon_poly1305_blocks.constprop.0+0x1b4/0x250 [poly1305_neon]<br /> Read of size 4 at addr ffff0010e293f010 by task syz-executor.5/1646715<br /> CPU: 4 PID: 1646715 Comm: syz-executor.5 Kdump: loaded Not tainted 5.10.0.aarch64 #1<br /> Hardware name: Huawei TaiShan 2280 /BC11SPCD, BIOS 1.59 01/31/2019<br /> Call trace:<br /> dump_backtrace+0x0/0x394<br /> show_stack+0x34/0x4c arch/arm64/kernel/stacktrace.c:196<br /> __dump_stack lib/dump_stack.c:77 [inline]<br /> dump_stack+0x158/0x1e4 lib/dump_stack.c:118<br /> print_address_description.constprop.0+0x68/0x204 mm/kasan/report.c:387<br /> __kasan_report+0xe0/0x140 mm/kasan/report.c:547<br /> kasan_report+0x44/0xe0 mm/kasan/report.c:564<br /> check_memory_region_inline mm/kasan/generic.c:187 [inline]<br /> __asan_load4+0x94/0xd0 mm/kasan/generic.c:252<br /> neon_poly1305_blocks.constprop.0+0x1b4/0x250 [poly1305_neon]<br /> neon_poly1305_do_update+0x6c/0x15c [poly1305_neon]<br /> neon_poly1305_update+0x9c/0x1c4 [poly1305_neon]<br /> crypto_shash_update crypto/shash.c:131 [inline]<br /> shash_finup_unaligned+0x84/0x15c crypto/shash.c:179<br /> crypto_shash_finup+0x8c/0x140 crypto/shash.c:193<br /> shash_digest_unaligned+0xb8/0xe4 crypto/shash.c:201<br /> crypto_shash_digest+0xa4/0xfc crypto/shash.c:217<br /> crypto_shash_tfm_digest+0xb4/0x150 crypto/shash.c:229<br /> essiv_skcipher_setkey+0x164/0x200 [essiv]<br /> crypto_skcipher_setkey+0xb0/0x160 crypto/skcipher.c:612<br /> skcipher_setkey+0x3c/0x50 crypto/algif_skcipher.c:305<br /> alg_setkey+0x114/0x2a0 crypto/af_alg.c:220<br /> alg_setsockopt+0x19c/0x210 crypto/af_alg.c:253<br /> __sys_setsockopt+0x190/0x2e0 net/socket.c:2123<br /> __do_sys_setsockopt net/socket.c:2134 [inline]<br /> __se_sys_setsockopt net/socket.c:2131 [inline]<br /> __arm64_sys_setsockopt+0x78/0x94 net/socket.c:2131<br /> __invoke_syscall arch/arm64/kernel/syscall.c:36 [inline]<br /> invoke_syscall+0x64/0x100 arch/arm64/kernel/syscall.c:48<br /> el0_svc_common.constprop.0+0x220/0x230 arch/arm64/kernel/syscall.c:155<br /> do_el0_svc+0xb4/0xd4 arch/arm64/kernel/syscall.c:217<br /> el0_svc+0x24/0x3c arch/arm64/kernel/entry-common.c:353<br /> el0_sync_handler+0x160/0x164 arch/arm64/kernel/entry-common.c:369<br /> el0_sync+0x160/0x180 arch/arm64/kernel/entry.S:683<br /> <br /> This error can be reproduced by the following code compiled as ko on a<br /> system with kasan enabled:<br /> <br /> #include <br /> #include <br /> #include <br /> #include <br /> <br /> char test_data[] = "\x00\x01\x02\x03\x04\x05\x06\x07"<br /> "\x08\x09\x0a\x0b\x0c\x0d\x0e\x0f"<br /> "\x10\x11\x12\x13\x14\x15\x16\x17"<br /> "\x18\x19\x1a\x1b\x1c\x1d\x1e";<br /> <br /> int init(void)<br /> {<br /> struct crypto_shash *tfm = NULL;<br /> char *data = NULL, *out = NULL;<br /> <br /> tfm = crypto_alloc_shash("poly1305", 0, 0);<br /> data = kmalloc(POLY1305_KEY_SIZE - 1, GFP_KERNEL);<br /> out = kmalloc(POLY1305_DIGEST_SIZE, GFP_KERNEL);<br /> memcpy(data, test_data, POLY1305_KEY_SIZE - 1);<br /> crypto_shash_tfm_digest(tfm, data, POLY1305_KEY_SIZE - 1, out);<br /> <br /> kfree(data);<br /> kfree(out);<br /> return 0;<br /> }<br /> <br /> void deinit(void)<br /> {<br /> }<br /> <br /> module_init(init)<br /> module_exit(deinit)<br /> MODULE_LICENSE("GPL");<br /> <br /> The root cause of the bug sits in neon_poly1305_blocks. The logic<br /> neon_poly1305_blocks() performed is that if it was called with both s[]<br /> and r[] uninitialized, it will first try to initialize them with the<br /> data from the first "block" that it believed to be 32 bytes in length.<br /> First 16 bytes are used as the key and the next 16 bytes for s[]. This<br /> would lead to the aforementioned read out-of-bound. However, after<br /> calling poly1305_init_arch(), only 16 bytes were deducted from the input<br /> and s[] is initialized yet again with the following 16 bytes. The second<br /> initialization of s[] is certainly redundent which indicates that the<br /> first initialization should be for r[] only.<br /> <br /> This patch fixes the issue by calling poly1305_init_arm64() instead o<br /> ---truncated---