linux-kernel - Re: Bug of dm-crypt?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 27 Feb 2009 17:46:53 +0800
From:	Huang Ying <ying.huang@...el.com>
To:	Milan Broz <mbroz@...hat.com>
Cc:	Herbert Xu <herbert@...dor.apana.org.au>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-crypto@...r.kernel.org" <linux-crypto@...r.kernel.org>
Subject: Re: Bug of dm-crypt?

Hi, Milan,

On Fri, 2009-02-27 at 16:41 +0800, Milan Broz wrote:
> Herbert Xu wrote:
> > On Fri, Feb 27, 2009 at 01:31:56PM +0800, Huang Ying wrote:
> >> I had ever heard from you that the only thing guaranteed in the
> >> completion function of async ablkcipher cryption is the req->data has
> >> the value you set before. The request pointer itself may be changed. But
> >> in dm-crypt, I found they rely on request pointer in completion
> >> function: kcryptd_async_done. This makes my AES-NI cryptd usage panic.
> >>
> >> Do you think that is a bug?
> > 
> > Absolutely.
> > 
> > It should use cc->req instead.
> 
> ok, I'll check it and try to fix that. 
> 
> Can you send me backtrace from that panic?

The panic backtrace is just some random kernel page fault or general
protection fault, because the freed pointer is not the allocated one.

> What's wrong in async callback now - mempool_free using async_req directly?

Yes. I have a fix by storing real allocated async_req in
async_req->data. Can you help me to review that?

> (Btw in some previous discussuion I asked if cryptd can be used
> for some kind of parallel speedup for dm-crypt in async mode and response
> was that cryptd "is only meant to be a demo showing how an async
> implementation should be written".
> 
> So this changed to real working thread for AES-NI?)

Yes. Now AES-NI uses it. And because a Per-CPU thread implementation is
used for cryptd, it can be used to speedup dm-crypt in some situation
too I think.

Best Regards,
Huang Ying


Download attachment "signature.asc" of type "application/pgp-signature" (198 bytes)