[lvc-project] [PATCH] crypto: keembay-ocs: prevent underflow in sg_data_total - remainder

[Дмитрий Окунев]

You're right. Initially, I considered the case where sg_data_total +
buf_cnt < blk_sz, in which the subtraction could underflow. But such
a state is unreachable in kmb_ocs_dma_prepare():

  - kmb_ocs_hcu_update() calls into the DMA path only when
    sg_data_total + buf_cnt > sizeof(rctx->buffer) = 256; otherwise
    it goes through flush_sg_to_ocs_buffer().
  - flush_sg_to_ocs_buffer() rejects buf_cnt > 256.

Since 256 is a multiple of both supported block sizes (64 and 128),
for sg_data_total < blk_sz the modulo (sg_data_total + buf_cnt) % blk_sz
reduces to sg_data_total + buf_cnt - 256. For sg_data_total >= blk_sz,
underflow is impossible anyway. In both cases,

    sg_data_total - remainder = 256 - buf_cnt >= 0.

Thus, the subtraction cannot underflow, regardless of whether
sg_data_total is less than, equal to, or greater than blk_sz. The
added check is dead code. No patch is needed.

Thanks for the review.

пт, 18 сент. 2026 г. в 11:49, Herbert Xu <herbert at gondor.apana.org.au>:

> On Tue, Sep 08, 2026 at 05:34:47PM +0300, Dmitriy Okunev wrote:
> > In the kmb_ocs_dma_prepare() function, the `remainder` is calculated
> > as `total % blk_sz`, where `total = sg_data_total + buf_cnt`. In
> > update requests, if `buf_cnt` is large and `total` is less than
> > `rctx->blk_sz`, the `remainder` may exceed `sg_data_total`, which
> > will lead to an overflow of `sg_data_total - remainder`. This results
> > in an incorrect large value being passed to the `sg_nents_for_len()`
> > function, which can lead to memory corruption.
> >
> > Add a check to return -EINVAL if `sg_data_total < remainder`,
> > so that the subtraction is always safe.
> >
> > Found by Linux Verification Center (linuxtesting.org) with SVACE.
> >
> > Fixes: 472b04444cd3 ("crypto: keembay - Add Keem Bay OCS HCU driver")
> > Signed-off-by: Dmitriy Okunev <dokunevdmitriy at gmail.com>
> > ---
> >  drivers/crypto/intel/keembay/keembay-ocs-hcu-core.c | 5 ++++-
> >  1 file changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/crypto/intel/keembay/keembay-ocs-hcu-core.c
> b/drivers/crypto/intel/keembay/keembay-ocs-hcu-core.c
> > index 9a67bb4ecc82..92f2d9ff6f83 100644
> > --- a/drivers/crypto/intel/keembay/keembay-ocs-hcu-core.c
> > +++ b/drivers/crypto/intel/keembay/keembay-ocs-hcu-core.c
> > @@ -246,8 +246,11 @@ static int kmb_ocs_dma_prepare(struct ahash_request
> *req)
> >        * HCU must be aligned to the block size; compute the remainder
> data to
> >        * be processed in the next request.
> >        */
> > -     if (!(rctx->flags & REQ_FINAL))
> > +     if (!(rctx->flags & REQ_FINAL)) {
> >               remainder = total % rctx->blk_sz;
> > +             if (rctx->sg_data_total < remainder)
> > +                     return -EINVAL;
> > +     }
>
> This driver buffers data less than block size, so how can it get
> here with sg_data_total less than block size?
>
> Thanks,
> --
> Email: Herbert Xu <herbert at gondor.apana.org.au>
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linuxtesting.org/pipermail/lvc-project/attachments/20260924/de667c80/attachment.html>