linux-kernel - AF_ALG: skb limits

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <3071479.2PrSHYvzOR@tauon.chronox.de>
Date:   Fri, 08 Dec 2017 13:43:20 +0100
From:   Stephan Mueller <smueller@...onox.de>
To:     Jonathan Cameron <Jonathan.Cameron@...wei.com>
Cc:     herbert@...dor.apana.org.au, davem@...emloft.net,
        linux-crypto@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: AF_ALG: skb limits

Am Freitag, 8. Dezember 2017, 12:39:06 CET schrieb Jonathan Cameron:

Hi Jonathan,

> 
> As a heads up, the other nasties we've found so far are around hitting
> limits on the various socket buffers.  When you run into those you can end
> up with parts of the data to be encrypted going through without it being
> obvious.
> 

The entire code uses sock_alloc to prevent user space to chew up kernel 
memory. I am aware that if you have a too low skb buffer limit, parts of the 
cipher operation will not succeed as a malloc will fail.

But that is returned with an error to user space. If you observe such an 
error, the entire message you wanted to read with recvmsg must be considered 
tainted (i.e. you do not know which part of the message has been encrypted or 
not). Thus, the recvmsg must be invoked again on the same buffer sent to the 
kernel if you want to ensure you encrypted the data.

Could you please help me understand where that functionality fails?

PS: If you want to give more memory to your sockets, you have to tweak /proc/
sys/net/core/optmem_max.

Ciao
Stephan