From: "Stephan Müller" <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: Re: AF_ALG: skb limits
Date: Sat, 13 Jan 2018 15:04:20 +0100 [thread overview]
Message-ID: <2851496.QEPl29WkUh@positron.chronox.de> (raw)
In-Reply-To: <20171212135921.00002630@huawei.com>
Am Dienstag, 12. Dezember 2017, 14:59:21 CET schrieb Jonathan Cameron:
Hi Jonathan,
> On Fri, 8 Dec 2017 13:43:20 +0100
>
> Stephan Mueller <smueller@chronox.de> wrote:
> > 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.
>
> I 'think' there are some cases where you don't get an error to userspace -
> or at least not directly.
>
> In af_alg_get_rsgl, we have an af_alg_readable(sk) call which simply breaks
> out of the loop - leaving us with len set to potentially part of the
> required length - without setting a appropriate return value.
>
> I can't immediately see how this one is reported to userspace.
af_alg_get_rsgl is used to calculate and obtain the length of the buffers
receiving the result (what is called RX buffers). That length is used for the
cipher operation and finally reported to user space.
For example (TX is the buffer given to the kernel during sendmsg, RX during
recvmsg) where the example disregards the alignment to block size:
sendmsg TX: 1000 bytes
recvmsg RX: 100 bytes given by user space, 100 bytes obtained by kernel
=> recvmsg returns 100
recvmsg RX: 1000 bytes given by user space, 900 bytes obtained by kernel
=> recvmsg returns 900
Note, the TX and RX buffer sizes may *not* be identical or even related. User
space may send one large input block as TX, but "process" it with numerous
small recvmsg calls. Each recvmsg call defines the cipher operation size. This
is of particular importance for an AEAD cipher.
>
> At least, with my driver, the first we see is an error returned by the
> processing engine. That ultimately gets reported to userspace the aio
> path.
So, you say that the error is returned. Isn't that what you want or expect?
>
> I'm chasing a particularly evil bug in my driver at the moment that is
> locking up the CPU and IOMMUs - if I ever figure that one out I'll run some
> fuzzing around these limits and see if we can find other cases.
Ciao
Stephan
next prev parent reply other threads:[~2018-01-13 14:05 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 ` AF_ALG: skb limits Stephan Mueller
2017-12-12 13:59 ` Jonathan Cameron
2018-01-13 14:04 ` Stephan Müller [this message]
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=2851496.QEPl29WkUh@positron.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).