linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Stephan Mueller <smueller@chronox.de>
To: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: herbert@gondor.apana.org.au, davem@davemloft.net,
	linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: AF_ALG: skb limits
Date: Fri, 08 Dec 2017 13:43:20 +0100	[thread overview]
Message-ID: <3071479.2PrSHYvzOR@tauon.chronox.de> (raw)
In-Reply-To: <20171208113906.000050aa@huawei.com>

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

  reply	other threads:[~2017-12-08 12:43 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-04 15:57 KASAN: use-after-free Write in aead_recvmsg syzbot
2017-12-08 10:50 ` [PATCH] crypto: AF_ALG - fix race accessing cipher request Stephan Müller
2017-12-08 11:39   ` Jonathan Cameron
2017-12-08 12:43     ` Stephan Mueller [this message]
2017-12-12 13:59       ` AF_ALG: skb limits Jonathan Cameron
2018-01-13 14:04         ` Stephan Müller
2018-01-15  9:46           ` Jonathan Cameron
2017-12-11 11:52   ` [PATCH] crypto: AF_ALG - fix race accessing cipher request Herbert Xu
2017-12-11 19:03 ` KASAN: use-after-free Write in aead_recvmsg 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=3071479.2PrSHYvzOR@tauon.chronox.de \
    --to=smueller@chronox.de \
    --cc=Jonathan.Cameron@huawei.com \
    --cc=davem@davemloft.net \
    --cc=herbert@gondor.apana.org.au \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    /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).