Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Organization: Red Hat UK Ltd. Registered Address: Red Hat UK Ltd, Amberley
        Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United
        Kingdom.
        Registered in England and Wales under Company Registration No. 3798903
From:   David Howells <dhowells@redhat.com>
In-Reply-To: <ZIhD53a/6Svmn1aS@gondor.apana.org.au>
References: <ZIhD53a/6Svmn1aS@gondor.apana.org.au> <0000000000000cb2c305fdeb8e30@google.com>
To:     Herbert Xu <herbert@gondor.apana.org.au>
Cc:     dhowells@redhat.com,
        syzbot <syzbot+e79818f5c12416aba9de@syzkaller.appspotmail.com>,
        davem@davemloft.net, linux-crypto@vger.kernel.org,
        linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
        pabeni@redhat.com, syzkaller-bugs@googlegroups.com
Subject: Re: [syzbot] [crypto?] general protection fault in cryptd_hash_export
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1521346.1686744278.1@warthog.procyon.org.uk>
Date:   Wed, 14 Jun 2023 13:04:38 +0100
Message-ID: <1521347.1686744278@warthog.procyon.org.uk>
Precedence: bulk

Herbert Xu <herbert@gondor.apana.org.au> wrote:

> David, the logic for calling hash_alloc_result looks quite different
> from that on whether you do the hash finalisation.  I'd suggest that
> you change them to use the same check, and also set use NULL instead
> of ctx->result if you didn't call hash_alloc_result.

I don't fully understand what the upstream hash_sendmsg() is doing.  Take this
bit for example:

	if (!ctx->more) {
		if ((msg->msg_flags & MSG_MORE))
			hash_free_result(sk, ctx);

Why is it freeing the old result only if MSG_MORE is now set, but wasn't set
on the last sendmsg()?

David