[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <04b376ce-bb1c-f7ff-a41a-8905badd9dba@de.ibm.com>
Date: Wed, 9 Dec 2020 07:54:22 +0100
From: Christian Borntraeger <borntraeger@...ibm.com>
To: Xiaohui Zhang <ruc_zhangxiaohui@....com>,
Harald Freudenberger <freude@...ux.ibm.com>,
Heiko Carstens <hca@...ux.ibm.com>,
Vasily Gorbik <gor@...ux.ibm.com>, linux-s390@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/1] crypto: Fix possible buffer overflows in
pkey_protkey_aes_attr_read
On 09.12.20 07:47, Xiaohui Zhang wrote:
> From: Zhang Xiaohui <ruc_zhangxiaohui@....com>
>
> pkey_protkey_aes_attr_read() calls memcpy() without checking the
> destination size may trigger a buffer overflower.
To me it looks like protkey.len is generated programmatically in pkey_genprotkey/pkey_clr2protkey
and this purely depends on the keytype and we do check for known ones.
Not sure how this can happen.
>
> Signed-off-by: Zhang Xiaohui <ruc_zhangxiaohui@....com>
> ---
> drivers/s390/crypto/pkey_api.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/s390/crypto/pkey_api.c b/drivers/s390/crypto/pkey_api.c
> index 99cb60ea6..abc237130 100644
> --- a/drivers/s390/crypto/pkey_api.c
> +++ b/drivers/s390/crypto/pkey_api.c
> @@ -1589,6 +1589,8 @@ static ssize_t pkey_protkey_aes_attr_read(u32 keytype, bool is_xts, char *buf,
> if (rc)
> return rc;
>
> + if (protkey.len > MAXPROTKEYSIZE)
> + protkey.len = MAXPROTKEYSIZE;
> protkeytoken.len = protkey.len;
> memcpy(&protkeytoken.protkey, &protkey.protkey, protkey.len);
>
> @@ -1599,6 +1601,8 @@ static ssize_t pkey_protkey_aes_attr_read(u32 keytype, bool is_xts, char *buf,
> if (rc)
> return rc;
>
> + if (protkey.len > MAXPROTKEYSIZE)
> + protkey.len = MAXPROTKEYSIZE;
> protkeytoken.len = protkey.len;
> memcpy(&protkeytoken.protkey, &protkey.protkey, protkey.len);
>
>
Powered by blists - more mailing lists