linux-kernel - Re: INFO: task hung in aead

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:   Sat, 30 Dec 2017 09:37:44 +0100
From:   Steffen Klassert <steffen.klassert@...unet.com>
To:     Eric Biggers <ebiggers3@...il.com>
CC:     Dmitry Vyukov <dvyukov@...gle.com>,
        syzbot 
        <bot+56c7151cad94eec37c521f0e47d2eee53f9361c4@...kaller.appspotmail.com>,
        LKML <linux-kernel@...r.kernel.org>,
        Ingo Molnar <mingo@...hat.com>,
        "Peter Zijlstra" <peterz@...radead.org>,
        <syzkaller-bugs@...glegroups.com>,
        "Herbert Xu" <herbert@...dor.apana.org.au>,
        David Miller <davem@...emloft.net>,
        <linux-crypto@...r.kernel.org>
Subject: Re: INFO: task hung in aead_recvmsg

On Sat, Dec 23, 2017 at 02:29:42PM -0600, Eric Biggers wrote:
> [+Cc Steffen Klassert <steffen.klassert@...unet.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?