All of lore.kernel.org
 help / color / mirror / Atom feed
From: yangerkun <yangerkun@huawei.com>
To: Sasha Levin <sashal@kernel.org>
Cc: <gregkh@linuxfoundation.org>, <herbert@gondor.apana.org.au>,
	<stable@vger.kernel.org>, <linux-crypto@vger.kernel.org>,
	<yangerkun@huawei.com>
Subject: Re: [PATCH 4.4.y v2] crypto: algif_skcipher - use ZERO_OR_NULL_PTR in skcipher_recvmsg_async
Date: Sat, 7 Mar 2020 09:49:25 +0800	[thread overview]
Message-ID: <8bb5b0d7-4232-14cb-49c7-a3cc348645ae@huawei.com> (raw)
In-Reply-To: <20200306133941.GQ21491@sasha-vm>



On 2020/3/6 21:39, Sasha Levin wrote:
> On Thu, Mar 05, 2020 at 04:57:55PM +0800, yangerkun wrote:
>> Nowdays, we trigger a oops:
>> ...
>> kasan: GPF could be caused by NULL-ptr deref or user memory 
>> accessgeneral protection fault: 0000 [#1] SMP KASAN
>> ...
>> Call Trace:
>> [<ffffffff81a26fb1>] skcipher_recvmsg_async+0x3f1/0x1400 
>> x86/../crypto/algif_skcipher.c:543
>> [<ffffffff81a28053>] skcipher_recvmsg+0x93/0x7f0 
>> x86/../crypto/algif_skcipher.c:723
>> [<ffffffff823e43a4>] sock_recvmsg_nosec x86/../net/socket.c:702 [inline]
>> [<ffffffff823e43a4>] sock_recvmsg x86/../net/socket.c:710 [inline]
>> [<ffffffff823e43a4>] sock_recvmsg+0x94/0xc0 x86/../net/socket.c:705
>> [<ffffffff823e464b>] sock_read_iter+0x27b/0x3a0 x86/../net/socket.c:787
>> [<ffffffff817f479b>] aio_run_iocb+0x21b/0x7a0 x86/../fs/aio.c:1520
>> [<ffffffff817f57c9>] io_submit_one x86/../fs/aio.c:1630 [inline]
>> [<ffffffff817f57c9>] do_io_submit+0x6b9/0x10b0 x86/../fs/aio.c:1688
>> [<ffffffff817f902d>] SYSC_io_submit x86/../fs/aio.c:1713 [inline]
>> [<ffffffff817f902d>] SyS_io_submit+0x2d/0x40 x86/../fs/aio.c:1710
>> [<ffffffff828b33c3>] tracesys_phase2+0x90/0x95
>>
>> In skcipher_recvmsg_async, we use '!sreq->tsg' to determine does we
>> calloc fail. However, kcalloc may return ZERO_SIZE_PTR, and with this,
>> the latter sg_init_table will trigger the bug. Fix it be use 
>> ZERO_OF_NULL_PTR.
>>
>> This function was introduced with ' commit a596999b7ddf ("crypto:
>> algif - change algif_skcipher to be asynchronous")', and has been removed
>> with 'commit e870456d8e7c ("crypto: algif_skcipher - overhaul memory
>> management")'.
>>
>> Reported-by: Hulk Robot <hulkci@huawei.com>
>> Signed-off-by: yangerkun <yangerkun@huawei.com>
>> ---
>> crypto/algif_skcipher.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> v1->v2:
>> update the commit message
>>
>> diff --git a/crypto/algif_skcipher.c b/crypto/algif_skcipher.c
>> index d12782dc9683..9bd4691cc5c5 100644
>> --- a/crypto/algif_skcipher.c
>> +++ b/crypto/algif_skcipher.c
>> @@ -538,7 +538,7 @@ static int skcipher_recvmsg_async(struct socket 
>> *sock, struct msghdr *msg,
>>     lock_sock(sk);
>>     tx_nents = skcipher_all_sg_nents(ctx);
>>     sreq->tsg = kcalloc(tx_nents, sizeof(*sg), GFP_KERNEL);
>> -    if (unlikely(!sreq->tsg))
>> +    if (unlikely(ZERO_OR_NULL_PTR(sreq->tsg)))
> 
> I'm a bit confused: kcalloc() will return ZERO_SIZE_PTR for allocations
> that ask for 0 bytes, but here we ask for "sizeof(*sg)" bytes, which is
> guaranteed to be more than 0, no?

Actually, the size need to calloc is (tx_nents * sizeof(*sg)), and 
tx_nents is 0.

> 


  reply	other threads:[~2020-03-07  1:49 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-05  8:57 [PATCH 4.4.y v2] crypto: algif_skcipher - use ZERO_OR_NULL_PTR in skcipher_recvmsg_async yangerkun
2020-03-06 13:39 ` Sasha Levin
2020-03-07  1:49   ` yangerkun [this message]
2020-03-08  0:19     ` Sasha Levin
2020-03-09  1:27       ` yangerkun
2020-03-10 12:14         ` Greg KH

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8bb5b0d7-4232-14cb-49c7-a3cc348645ae@huawei.com \
    --to=yangerkun@huawei.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=herbert@gondor.apana.org.au \
    --cc=linux-crypto@vger.kernel.org \
    --cc=sashal@kernel.org \
    --cc=stable@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.