Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753172AbeAEVgD (ORCPT + 1 other); Fri, 5 Jan 2018 16:36:03 -0500 Received: from mail-yw0-f195.google.com ([209.85.161.195]:43921 "EHLO mail-yw0-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753131AbeAEVf7 (ORCPT ); Fri, 5 Jan 2018 16:35:59 -0500 X-Google-Smtp-Source: ACJfBotQsYMQSh9ZLBig27L9FiyBCp2iR7jToaucCy1yLWw6TLlt4S5YKmG7/o67+/ES8RRPVYjg8w== Date: Fri, 5 Jan 2018 13:35:55 -0800 From: Eric Biggers To: Steffen Klassert Cc: Dmitry Vyukov , syzbot , LKML , Ingo Molnar , Peter Zijlstra , syzkaller-bugs@googlegroups.com, Herbert Xu , David Miller , linux-crypto@vger.kernel.org Subject: Re: INFO: task hung in aead_recvmsg Message-ID: <20180105213555.GC44929@gmail.com> References: <001a1140b8307b0439055ffc7872@google.com> <20171223202942.GB10162@zzz.localdomain> <20171230083744.vuclnbs677tj7pi2@gauss3.secunet.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20171230083744.vuclnbs677tj7pi2@gauss3.secunet.de> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Return-Path: 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 ] > > > > > > 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 > > #include > > #include > > > > 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