[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <48b3624d-ef0c-96e7-ff3d-9f34eb1caad8@gmail.com>
Date: Fri, 6 Oct 2023 14:03:35 +0300
From: Tatu Heikkilä <tatu.heikkila@...il.com>
To: herbert@...dor.apana.org.au
Cc: agk@...hat.com, bagasdotme@...il.com, dm-devel@...hat.com,
linux-crypto@...r.kernel.org, linux-kernel@...r.kernel.org,
regressions@...ts.linux.dev, snitzer@...nel.org
Subject: Re: [PATCH] dm crypt: Fix reqsize in crypt_iv_eboiv_gen
On Fri, Oct 06, 2023 at 09:41:55 +0800, Herbert Xu wrote:
>
> On Fri, Oct 06, 2023 at 08:04:18AM +0700, Bagas Sanjaya wrote:
> >
> > > Git bisect lead me to:
> > > # first bad commit: [e3023094dffb41540330fb0c74cd3a019cd525c2] dm crypt:
> > > Avoid using MAX_CIPHER_BLOCKSIZE
> > >
> > > If I git revert e3023094dffb41540330fb0c74cd3a019cd525c2 on current Linus'
> > > git master, the issue goes away. So I'm personally not all that affected
> > > anymore (if I'm ready to compile my kernels from now on), and I understand
> > > that you have no clear way to reproduce this as it seems strongly bound to
> > > hardware, but seems like this could point to a potentially serious security
> > > issue since it involves both crypto and undefined behaviour.
>
> Thanks for the report. Sorry this is indeed my fault. The allocated
> buffer is too small as it's missing the size for the request object
> itself.
Thank you for your prompt fix, I can access the volume without issue now. :-)
-Tatu
Powered by blists - more mailing lists