mpi: Fix length check in mpi_key_length()

hulk inclusion
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I62DVN


CVE: NA

--------------------------------

Syzkaller reported a UAF in mpi_key_length().

BUG: KASAN: use-after-free in mpi_key_length+0x34/0xb0
Read of size 2 at addr ffff888005737e14 by task syz-executor.15/6236

CPU: 1 PID: 6236 Comm: syz-executor.15 Kdump: loaded Tainted: GF          OE     5.10.0.kasan.x86_64 #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58-20220525_182517-szxrtosci10000 04/01/2014
Call Trace:
 dump_stack+0x9c/0xd3
 print_address_description.constprop.0+0x19/0x170
 __kasan_report.cold+0x6c/0x84
 kasan_report+0x3a/0x50
 check_memory_region+0xfd/0x1f0
 mpi_key_length+0x34/0xb0
 pgp_calc_pkey_keyid.isra.0+0x100/0x5a0
 pgp_generate_fingerprint+0x159/0x330
 pgp_process_public_key+0x1c5/0x330
 pgp_parse_packets+0xf4/0x200
 pgp_key_parse+0xb6/0x340
 asymmetric_key_preparse+0x8a/0x120
 key_create_or_update+0x31f/0x8c0
 __se_sys_add_key+0x23e/0x400
 do_syscall_64+0x30/0x40
 entry_SYSCALL_64_after_hwframe+0x61/0xc6

The root cause of the issue is that pgp_calc_pkey_keyid() would call
mpi_key_length() and get the length of the public key. The length was
then ducted from keylen, which is an unsigned value. However, the
returnd byte count is not checked for legitimacy in mpi_key_length(),
resulting in an inverted keylen, hence the read overflow.

It turns out that the byte count check was mistakenly placed in
mpi_read_from_buffer() while commit 94479061 ("mpi: introduce
mpi_key_length()") tries to extract mpi_key_length() out of
mpi_read_from_buffer(). This patch moves the check into
mpi_key_length().

Fixes: commit 94479061 ("mpi: introduce mpi_key_length()")
Signed-off-by: GUO Zihua <guozihua@huawei.com>
Reviewed-by: Wang Weiyang <wangweiyang2@huawei.com>
Signed-off-by: Zheng Zengkai <zhengzengkai@huawei.com>