[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <Yc45ZPItDFcDaCNv@quark>
Date: Thu, 30 Dec 2021 16:57:40 -0600
From: Eric Biggers <ebiggers@...nel.org>
To: Jiasheng Jiang <jiasheng@...as.ac.cn>
Cc: herbert@...dor.apana.org.au, davem@...emloft.net,
linux-crypto@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] crypto: af_alg - check possible NULL pointer
On Wed, Dec 29, 2021 at 05:32:16PM +0800, Jiasheng Jiang wrote:
> And then it will cause the BUG_ON() in sg_assign_page().
That's not true. The two BUG_ON()'s in sg_assign_page() are:
BUG_ON((unsigned long) page & (SG_CHAIN | SG_END));
#ifdef CONFIG_DEBUG_SG
BUG_ON(sg_is_chain(sg));
#endif
Neither will trigger due to page == NULL.
> do {
> + struct page *pg;
> unsigned int i = sgl->cur;
>
> plen = min_t(size_t, len, PAGE_SIZE);
>
> - sg_assign_page(sg + i, alloc_page(GFP_KERNEL));
> + pg = alloc_page(GFP_KERNEL);
> + if (!pg) {
> + err = -ENOMEM;
> + goto unlock;
> + }
> +
> + sg_assign_page(sg + i, pg);
> if (!sg_page(sg + i)) {
> err = -ENOMEM;
> goto unlock;
The NULL check is already done, just below the redundant one you're adding.
I do think it would be more logical to do the NULL check before
sg_assign_page(). So you could send a patch that moves it there. But it would
be a cleanup, not a fix.
- Eric
Powered by blists - more mailing lists