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]
Message-ID: <CAHk-=wi+xewHz=BH7LcZAxrj9JXi66s9rp+kBqRchVG3a-b2BA@mail.gmail.com>
Date:   Mon, 28 Feb 2022 17:12:20 -0800
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Herbert Xu <herbert@...dor.apana.org.au>
Cc:     Giovanni Cabiddu <giovanni.cabiddu@...el.com>,
        Kyle Sanderson <kyle.leet@...il.com>,
        Dave Chinner <david@...morbit.com>, qat-linux@...el.com,
        Linux-Kernal <linux-kernel@...r.kernel.org>,
        linux-xfs <linux-xfs@...r.kernel.org>,
        Linux Crypto Mailing List <linux-crypto@...r.kernel.org>,
        device-mapper development <dm-devel@...hat.com>,
        Greg KH <gregkh@...uxfoundation.org>
Subject: Re: Intel QAT on A2SDi-8C-HLN4F causes massive data corruption with
 dm-crypt + xfs

On Mon, Feb 28, 2022 at 3:26 PM Herbert Xu <herbert@...dor.apana.org.au> wrote:
>
> Indeed, qat has been disabled for dm-crypt since
>
> commit b8aa7dc5c7535f9abfca4bceb0ade9ee10cf5f54
> Author: Mikulas Patocka <mpatocka@...hat.com>
> Date:   Thu Jul 9 23:20:41 2020 -0700
>
>     crypto: drivers - set the flag CRYPTO_ALG_ALLOCATES_MEMORY
>
> So this should no longer be an issue with an up-to-date kernel.

Ok, that commit message doesn't exactly make it clear that it also
fixes a major disk corruption issue.

It sounds like it was incidental and almost accidental that it fixed
that thing, and nobody realized it should perhaps be also moved to
stable.

Oh, except I think you *also* need commit cd74693870fb ("dm crypt:
don't use drivers that have CRYPTO_ALG_ALLOCATES_MEMORY") that
actually reacts to that flag.

Which also wasn't marked for stable, and which is why 5.10 is ok, but
5.9 (which has that first commit, but not the second) is not ok.

Of course, maybe they got marked for stable separately and actually
have been back-ported, but it doesn't sound like that happened.. I
didn't actually check.

                  Linus

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ