From: Eric Biggers <ebiggers3@gmail.com>
To: Steffen Klassert <steffen.klassert@secunet.com>
Cc: Dmitry Vyukov <dvyukov@google.com>,
syzbot
<bot+56c7151cad94eec37c521f0e47d2eee53f9361c4@syzkaller.appspotmail.com>,
LKML <linux-kernel@vger.kernel.org>,
Ingo Molnar <mingo@redhat.com>,
Peter Zijlstra <peterz@infradead.org>,
syzkaller-bugs@googlegroups.com,
Herbert Xu <herbert@gondor.apana.org.au>,
David Miller <davem@davemloft.net>,
linux-crypto@vger.kernel.org
Subject: Re: INFO: task hung in aead_recvmsg
Date: Fri, 5 Jan 2018 13:35:55 -0800 [thread overview]
Message-ID: <20180105213555.GC44929@gmail.com> (raw)
In-Reply-To: <20171230083744.vuclnbs677tj7pi2@gauss3.secunet.de>
On Sat, Dec 30, 2017 at 09:37:44AM +0100, Steffen Klassert wrote:
> On Sat, Dec 23, 2017 at 02:29:42PM -0600, Eric Biggers wrote:
> > [+Cc Steffen Klassert <steffen.klassert@secunet.com>]
> >
> >
> > I was able to reproduce this by trying to use 'pcrypt' recursively. I am not
> > 100% sure it is the exact same bug, but it probably is. Here is a C reproducer:
> >
> > #include <linux/if_alg.h>
> > #include <sys/socket.h>
> > #include <unistd.h>
> >
> > int main()
> > {
> > struct sockaddr_alg addr = {
> > .salg_type = "aead",
> > .salg_name = "pcrypt(pcrypt(rfc4106-gcm-aesni))",
> > };
> > int algfd, reqfd;
> > char buf[32] = { 0 };
> >
> > algfd = socket(AF_ALG, SOCK_SEQPACKET, 0);
> > bind(algfd, (void *)&addr, sizeof(addr));
> > setsockopt(algfd, SOL_ALG, ALG_SET_KEY, buf, 20);
> >
> > reqfd = accept(algfd, 0, 0);
> > write(reqfd, buf, 32);
> > read(reqfd, buf, 16);
> > }
> >
> > It seems the problem is that all 'pcrypt' instances use the same
> > 'padata_instance', which completes works in the order they are submitted. But
> > with nested use, the outer work is submitted before the inner work, so the inner
> > work isn't allowed to complete until the outer work does, which deadlocks
> > because actually the inner work needs to complete first.
> >
> > What a mess. Maybe there should be a separate 'padata_instance' per pcrypt
> > instance? Or maybe there should be a way for an algorithm to declare that it
> > can only appear in the stack one time?
>
> Having two nested pcrypt templates in one algorithm instance
> does not make so much sense in the first place. I thought
> that the crypto layer would refuse to build an instance
> with two nested templates of the same type.
>
> At least for pcrypt, refusing such instantiations would
> be the correct behaviour. Are there any other templates
> where a nested use would make sense?
Maybe. But either way, I don't see a straightforward way to prevent it
currently. In particular, the links from an instance to its inner algorithms
are stored in the crypto_instance_ctx() which has a template-specific format, so
it isn't currently possible to recursively search an instance to check whether a
particular template is present. We could perhaps add such links in a standard
format, though...
Eric
next prev parent reply other threads:[~2018-01-05 21:35 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <001a1140b8307b0439055ffc7872@google.com>
2017-12-12 16:46 ` INFO: task hung in aead_recvmsg Dmitry Vyukov
2017-12-23 20:29 ` Eric Biggers
2017-12-30 8:37 ` Steffen Klassert
2018-01-05 21:35 ` Eric Biggers [this message]
[not found] ` <20180310232231.19191-1-ebiggers3@gmail.com>
[not found] ` <20180323002152.GA30497@gondor.apana.org.au>
[not found] ` <20180408225528.GH685@sol.localdomain>
[not found] ` <20180409085807.2cwvr5cocz6gfbmv@gauss3.secunet.de>
[not found] ` <20180409190739.GC203367@gmail.com>
[not found] ` <20180418053533.wuo6bj2okqdu2hrf@gauss3.secunet.de>
2019-02-20 4:06 ` [RFC PATCH] crypto: pcrypt - forbid recursive instantiation Herbert Xu
2019-02-20 11:42 ` Steffen Klassert
2019-03-01 3:38 ` Herbert Xu
2018-07-21 12:37 ` INFO: task hung in aead_recvmsg syzbot
2019-12-01 7:58 ` syzbot
2019-12-01 17:58 ` Stephan Müller
2019-12-01 19:22 ` Eric Biggers
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180105213555.GC44929@gmail.com \
--to=ebiggers3@gmail.com \
--cc=bot+56c7151cad94eec37c521f0e47d2eee53f9361c4@syzkaller.appspotmail.com \
--cc=davem@davemloft.net \
--cc=dvyukov@google.com \
--cc=herbert@gondor.apana.org.au \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=steffen.klassert@secunet.com \
--cc=syzkaller-bugs@googlegroups.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).