The async path cannot use MAY_BACKLOG because it is not meant to
block, which is what MAY_BACKLOG does.  On the other hand, both
the sync and async paths can make use of MAY_SLEEP.

Cc: stable@vger.kernel.org
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

Any access to non-constant bits of the private context must be
done under the socket lock, in particular, this includes ctx->req.

This patch moves such accesses under the lock, and fetches the
tfm from the parent socket which is guaranteed to be constant,
rather than from ctx->req.

Cc: stable@vger.kernel.org
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

The async path in algif_skcipher assumes that the crypto completion
function will be called with the original request.  This is not
necessarily the case.  In fact there is no need for this anyway
since we already embed information into the request with struct
skcipher_async_req.

This patch adds a pointer to that struct and then passes it as
the data to the callback function.

Cc: stable@vger.kernel.org
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
Tested-by: NTadeusz Struk <tadeusz.struk@intel.com>

We miss to take the crypto_alg_sem semaphore when traversing the
crypto_alg_list for CRYPTO_MSG_GETALG dumps. This allows a race with
crypto_unregister_alg() removing algorithms from the list while we're
still traversing it, thereby leading to a use-after-free as show below:

[ 3482.071639] general protection fault: 0000 [#1] SMP
[ 3482.075639] Modules linked in: aes_x86_64 glue_helper lrw ablk_helper cryptd gf128mul ipv6 pcspkr serio_raw virtio_net microcode virtio_pci virtio_ring virtio sr_mod cdrom [last unloaded: aesni_intel]
[ 3482.075639] CPU: 1 PID: 11065 Comm: crconf Not tainted 4.3.4-grsec+ #126
[ 3482.075639] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.7.5-20140531_083030-gandalf 04/01/2014
[ 3482.075639] task: ffff88001cd41a40 ti: ffff88001cd422c8 task.ti: ffff88001cd422c8
[ 3482.075639] RIP: 0010:[<ffffffff93722bd3>]  [<ffffffff93722bd3>] strncpy+0x13/0x30
[ 3482.075639] RSP: 0018:ffff88001f713b60  EFLAGS: 00010202
[ 3482.075639] RAX: ffff88001f6c4430 RBX: ffff88001f6c43a0 RCX: ffff88001f6c4430
[ 3482.075639] RDX: 0000000000000040 RSI: fefefefefefeff16 RDI: ffff88001f6c4430
[ 3482.075639] RBP: ffff88001f713b60 R08: ffff88001f6c4470 R09: ffff88001f6c4480
[ 3482.075639] R10: 0000000000000002 R11: 0000000000000246 R12: ffff88001ce2aa28
[ 3482.075639] R13: ffff880000093700 R14: ffff88001f5e4bf8 R15: 0000000000003b20
[ 3482.075639] FS:  0000033826fa2700(0000) GS:ffff88001e900000(0000) knlGS:0000000000000000
[ 3482.075639] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 3482.075639] CR2: ffffffffff600400 CR3: 00000000139ec000 CR4: 00000000001606f0
[ 3482.075639] Stack:
[ 3482.075639]  ffff88001f713bd8 ffffffff936ccd00 ffff88001e5c4200 ffff880000093700
[ 3482.075639]  ffff88001f713bd0 ffffffff938ef4bf 0000000000000000 0000000000003b20
[ 3482.075639]  ffff88001f5e4bf8 ffff88001f5e4848 0000000000000000 0000000000003b20
[ 3482.075639] Call Trace:
[ 3482.075639]  [<ffffffff936ccd00>] crypto_report_alg+0xc0/0x3e0
[ 3482.075639]  [<ffffffff938ef4bf>] ? __alloc_skb+0x16f/0x300
[ 3482.075639]  [<ffffffff936cd08a>] crypto_dump_report+0x6a/0x90
[ 3482.075639]  [<ffffffff93935707>] netlink_dump+0x147/0x2e0
[ 3482.075639]  [<ffffffff93935f99>] __netlink_dump_start+0x159/0x190
[ 3482.075639]  [<ffffffff936ccb13>] crypto_user_rcv_msg+0xc3/0x130
[ 3482.075639]  [<ffffffff936cd020>] ? crypto_report_alg+0x3e0/0x3e0
[ 3482.075639]  [<ffffffff936cc4b0>] ? alg_test_crc32c+0x120/0x120
[ 3482.075639]  [<ffffffff93933145>] ? __netlink_lookup+0xd5/0x120
[ 3482.075639]  [<ffffffff936cca50>] ? crypto_add_alg+0x1d0/0x1d0
[ 3482.075639]  [<ffffffff93938141>] netlink_rcv_skb+0xe1/0x130
[ 3482.075639]  [<ffffffff936cc4f8>] crypto_netlink_rcv+0x28/0x40
[ 3482.075639]  [<ffffffff939375a8>] netlink_unicast+0x108/0x180
[ 3482.075639]  [<ffffffff93937c21>] netlink_sendmsg+0x541/0x770
[ 3482.075639]  [<ffffffff938e31e1>] sock_sendmsg+0x21/0x40
[ 3482.075639]  [<ffffffff938e4763>] SyS_sendto+0xf3/0x130
[ 3482.075639]  [<ffffffff93444203>] ? bad_area_nosemaphore+0x13/0x20
[ 3482.075639]  [<ffffffff93444470>] ? __do_page_fault+0x80/0x3a0
[ 3482.075639]  [<ffffffff939d80cb>] entry_SYSCALL_64_fastpath+0x12/0x6e
[ 3482.075639] Code: 88 4a ff 75 ed 5d 48 0f ba 2c 24 3f c3 66 66 2e 0f 1f 84 00 00 00 00 00 55 48 85 d2 48 89 f8 48 89 f9 4c 8d 04 17 48 89 e5 74 15 <0f> b6 16 80 fa 01 88 11 48 83 de ff 48 83 c1 01 4c 39 c1 75 eb
[ 3482.075639] RIP  [<ffffffff93722bd3>] strncpy+0x13/0x30

To trigger the race run the following loops simultaneously for a while:
  $ while : ; do modprobe aesni-intel; rmmod aesni-intel; done
  $ while : ; do crconf show all > /dev/null; done

Fix the race by taking the crypto_alg_sem read lock, thereby preventing
crypto_unregister_alg() from modifying the algorithm list during the
dump.

This bug has been detected by the PaX memory sanitize feature.

Cc: stable@vger.kernel.org
Signed-off-by: NMathias Krause <minipli@googlemail.com>
Cc: Steffen Klassert <steffen.klassert@secunet.com>
Cc: PaX Team <pageexec@freemail.hu>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

hash_sendmsg/sendpage() need to wait for the completion
of crypto_ahash_init() otherwise it can cause panic.

Cc: stable@vger.kernel.org
Signed-off-by: NRui Wang <rui.y.wang@intel.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

The has_key logic is wrong for shash algorithms as they always
have a setkey function.  So we should instead be testing against
shash_no_setkey.

Fixes: a5596d63 ("crypto: hash - Add crypto_ahash_has_setkey")
Cc: stable@vger.kernel.org
Reported-by: NStephan Mueller <smueller@chronox.de>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
Tested-by: NStephan Mueller <smueller@chronox.de>

The ghash and poly1305 hash implementations can be enabled when
CONFIG_CRYPTO_HASH is turned off, causing a link error:

crypto/built-in.o: In function `ghash_mod_init':
(.init.text+0xd0): undefined reference to `crypto_register_shash'
crypto/built-in.o: In function `ghash_mod_exit':
(.exit.text+0xb4): undefined reference to `crypto_unregister_shash'
crypto/built-in.o: In function `poly1305_mod_init':
(.init.text+0xb4): undefined reference to `crypto_register_shash'
crypto/built-in.o: In function `poly1305_mod_exit':
(.exit.text+0x98): undefined reference to `crypto_unregister_shash'

This adds an explicit 'select', like all other hashes have it.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

Dave Young reported:
> Hi,
>
> I saw the warning "Missing required AuthAttr" when testing kexec,
> known issue?  Idea about how to fix it?
>
> The kernel is latest linus tree plus sevral patches from Toshi to
> cleanup io resource structure.
>
> in function pkcs7_sig_note_set_of_authattrs():
>         if (!test_bit(sinfo_has_content_type, &sinfo->aa_set) ||
>             !test_bit(sinfo_has_message_digest, &sinfo->aa_set) ||
>             (ctx->msg->data_type == OID_msIndirectData &&
>              !test_bit(sinfo_has_ms_opus_info, &sinfo->aa_set))) {
>                 pr_warn("Missing required AuthAttr\n");
>                 return -EBADMSG;
>         }
>
> The third condition below is true:
> (ctx->msg->data_type == OID_msIndirectData &&
>              !test_bit(sinfo_has_ms_opus_info, &sinfo->aa_set))
>
> I signed the kernel with redhat test key like below:
> pesign -c 'Red Hat Test Certificate' -i arch/x86/boot/bzImage -o /boot/vmlinuz-4.4.0-rc8+ -s --force

And right he is!  The Authenticode specification is a paragon amongst
technical documents, and has this pearl of wisdom to offer:

---------------------------------
Authenticode-Specific SignerInfo UnauthenticatedAttributes Structures

  The following Authenticode-specific data structures are present in
  SignerInfo authenticated attributes.

  SpcSpOpusInfo
  SpcSpOpusInfo is identified by SPC_SP_OPUS_INFO_OBJID
  (1.3.6.1.4.1.311.2.1.12) and is defined as follows:
  SpcSpOpusInfo ::= SEQUENCE {
    programName  [0] EXPLICIT SpcString OPTIONAL,
    moreInfo     [1] EXPLICIT SpcLink OPTIONAL,
  } --#public--

  SpcSpOpusInfo has two fields:
    programName
      This field contains the program description:
      If publisher chooses not to specify a description, the SpcString
      structure contains a zero-length program name.
      If the publisher chooses to specify a
      description, the SpcString structure contains a Unicode string.
    moreInfo
      This field is set to an SPCLink structure that contains a URL for
      a Web site with more information about the signer. The URL is an
      ASCII string.
---------------------------------

Which is to say that this is an optional *unauthenticated* field which
may be present in the Authenticated Attribute list.  This is not how
pkcs7 is supposed to work, so when David implemented this, he didn't
appreciate the subtlety the original spec author was working with, and
missed the part of the sublime prose that says this Authenticated
Attribute is an Unauthenticated Attribute.  As a result, the code in
question simply takes as given that the Authenticated Attributes should
be authenticated.

But this one should not, individually.  Because it says it's not
authenticated.

It still has to hash right so the TBS digest is correct.  So it is both
authenticated and unauthenticated, all at once.  Truly, a wonder of
technical accomplishment.

Additionally, pesign's implementation has always attempted to be
compatible with the signatures emitted from contemporary versions of
Microsoft's signtool.exe.  During the initial implementation, Microsoft
signatures always produced the same values for SpcSpOpusInfo -
{U"Microsoft Windows", "http://www.microsoft.com"} - without regard to
who the signer was.

Sometime between Windows 8 and Windows 8.1 they stopped including the
field in their signatures altogether, and as such pesign stopped
producing them in commits c0c4da6 and d79cb0c, sometime around June of
2012.  The theory here is that anything that breaks with
pesign signatures would also be breaking with signtool.exe sigs as well,
and that'll be a more noticed problem for firmwares parsing it, so it'll
get fixed.  The fact that we've done exactly this bug in Linux code is
first class, grade A irony.

So anyway, we should not be checking this field for presence or any
particular value: if the field exists, it should be at the right place,
but aside from that, as long as the hash matches the field is good.
Signed-off-by: NPeter Jones <pjones@redhat.com>
Tested-by: NDave Young <dyoung@redhat.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

We mark the end of the SG list in sendmsg and sendpage and unmark
it on the next send call.  Unfortunately the unmarking in sendmsg
is off-by-one, leading to an SG list that is too short.

Fixes: 0f477b65 ("crypto: algif - Mark sgl end at the end of data")
Cc: stable@vger.kernel.org
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

I don't think it makes sense for a module to have a soft dependency
on itself. This seems quite cyclic by nature and I can't see what
purpose it could serve.

OTOH libcrc32c calls crypto_alloc_shash("crc32c", 0, 0) so it pretty
much assumes that some incarnation of the "crc32c" hash algorithm has
been loaded. Therefore it makes sense to have the soft dependency
there (as crc-t10dif does.)

Cc: stable@vger.kernel.org
Cc: Tim Chen <tim.c.chen@linux.intel.com>
Cc: "David S. Miller" <davem@davemloft.net>
Signed-off-by: NJean Delvare <jdelvare@suse.de>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

We need to load the TX SG list in sendmsg(2) after waiting for
incoming data, not before.

Cc: stable@vger.kernel.org
Reported-by: NDmitry Vyukov <dvyukov@google.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
Tested-by: NDmitry Vyukov <dvyukov@google.com>

We need to lock the child socket in skcipher_check_key as otherwise
two simultaneous calls can cause the parent socket to be freed.

Cc: stable@vger.kernel.org
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

We need to lock the child socket in hash_check_key as otherwise
two simultaneous calls can cause the parent socket to be freed.

Cc: stable@vger.kernel.org
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

This patch forbids the calling of bind(2) when there are child
sockets created by accept(2) in existence, even if they are created
on the nokey path.

This is needed as those child sockets have references to the tfm
object which bind(2) will destroy.

Cc: stable@vger.kernel.org
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

This patch removes the custom release parent function as the
generic af_alg_release_parent now works for nokey sockets too.

Cc: stable@vger.kernel.org
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

This patch removes the custom release parent function as the
generic af_alg_release_parent now works for nokey sockets too.

Cc: stable@vger.kernel.org
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

This patch allows af_alg_release_parent to be called even for
nokey sockets.

Cc: stable@vger.kernel.org
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

This patch adds an exception to the key check so that cipher_null
users may continue to use algif_skcipher without setting a key.

Cc: stable@vger.kernel.org
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

This patch adds a way for skcipher users to determine whether a key
is required by a transform.

Cc: stable@vger.kernel.org
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

Hash implementations that require a key may crash if you use
them without setting a key.  This patch adds the necessary checks
so that if you do attempt to use them without a key that we return
-ENOKEY instead of proceeding.

This patch also adds a compatibility path to support old applications
that do acept(2) before setkey.

Cc: stable@vger.kernel.org
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

This patch adds a way for ahash users to determine whether a key
is required by a crypto_ahash transform.

Cc: stable@vger.kernel.org
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

This patch adds a compatibility path to support old applications
that do acept(2) before setkey.

Cc: stable@vger.kernel.org
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

This patch adds a compatibility path to support old applications
that do acept(2) before setkey.

Cc: stable@vger.kernel.org
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

When we fail an accept(2) call we will end up freeing the socket
twice, once due to the direct sk_free call and once again through
newsock.

This patch fixes this by removing the sk_free call.

Cc: stable@vger.kernel.org
Reported-by: NDmitry Vyukov <dvyukov@google.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

Each af_alg parent socket obtained by socket(2) corresponds to a
tfm object once bind(2) has succeeded.  An accept(2) call on that
parent socket creates a context which then uses the tfm object.

Therefore as long as any child sockets created by accept(2) exist
the parent socket must not be modified or freed.

This patch guarantees this by using locks and a reference count
on the parent socket.  Any attempt to modify the parent socket will
fail with EBUSY.

Cc: stable@vger.kernel.org
Reported-by: NDmitry Vyukov <dvyukov@google.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

Some cipher implementations will crash if you try to use them
without calling setkey first.  This patch adds a check so that
the accept(2) call will fail with -ENOKEY if setkey hasn't been
done on the socket yet.

Cc: stable@vger.kernel.org
Reported-by: NDmitry Vyukov <dvyukov@google.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
Tested-by: NDmitry Vyukov <dvyukov@google.com>

These async_XX functions are called from md/raid5 in an atomic
section, between get_cpu() and put_cpu(), so they must not sleep.
So use GFP_NOWAIT rather than GFP_IO.

Dan Williams writes: Longer term async_tx needs to be merged into md
directly as we can allocate this unmap data statically per-stripe
rather than per request.

Fixed: 7476bd79 ("async_pq: convert to dmaengine_unmap_data")
Cc: stable@vger.kernel.org (v3.13+)
Reported-and-tested-by: NStanislav Samsonov <slava@annapurnalabs.com>
Acked-by: NDan Williams <dan.j.williams@intel.com>
Signed-off-by: NNeilBrown <neilb@suse.com>
Signed-off-by: NVinod Koul <vinod.koul@intel.com>

Some crypto drivers cannot process empty data message and return a
precalculated hash for md5/sha1/sha224/sha256.

This patch add thoses precalculated hash in include/crypto.
Signed-off-by: NLABBE Corentin <clabbe.montjoie@gmail.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

Avoid the s390 compile "warning: 'pkcs1pad_encrypt_sign_complete'
uses dynamic stack allocation" reported by kbuild test robot.  Don't
use a flat zero-filled buffer, instead zero the contents of the SGL.
Signed-off-by: NAndrew Zaborowski <andrew.zaborowski@intel.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

This patch replaces uses of ablkcipher with the new skcipher
interface.

Cc: stable@vger.kernel.org
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
Tested-by: <smueller@chronox.de>

Added 'hash=' option for selecting the hash algorithm for add_key()
syscall and documentation for it.

Added entry for sm3-256 to the following tables in order to support
TPM_ALG_SM3_256:

* hash_algo_name
* hash_digest_size

Includes support for the following hash algorithms:

* sha1
* sha256
* sha384
* sha512
* sm3-256
Signed-off-by: NJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Tested-by: NColin Ian King <colin.king@canonical.com>
Reviewed-by: NJames Morris <james.l.morris@oracle.com>
Reviewed-by: NMimi Zohar <zohar@linux.vnet.ibm.com>
Acked-by: NPeter Huewe <peterhuewe@gmx.de>

This option creates IMA MOK and blacklist keyrings.  IMA MOK is an
intermediate keyring that sits between .system and .ima keyrings,
effectively forming a simple CA hierarchy.  To successfully import a key
into .ima_mok it must be signed by a key which CA is in .system keyring.
On turn any key that needs to go in .ima keyring must be signed by CA in
either .system or .ima_mok keyrings. IMA MOK is empty at kernel boot.

IMA blacklist keyring contains all revoked IMA keys.  It is consulted
before any other keyring.  If the search is successful the requested
operation is rejected and error is returned to the caller.
Signed-off-by: NPetko Manolov <petkan@mip-labs.com>
Signed-off-by: NMimi Zohar <zohar@linux.vnet.ibm.com>

This file does not contain any modular related function calls.  So get
rid of module.h since it drags in a lot of other headers and adds to
the preprocessing load.  It does export some symbols though, so we'll
need to ensure it has export.h present instead.

Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: linux-crypto@vger.kernel.org
Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

The drbg_state_ops structures are never modified, so declare them as const.

Done with the help of Coccinelle.
Signed-off-by: NJulia Lawall <Julia.Lawall@lip6.fr>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

Some ciphers actually support encrypting zero length plaintexts. For
example, many AEAD modes support this. The resulting ciphertext for
those winds up being only the authentication tag, which is a result of
the key, the iv, the additional data, and the fact that the plaintext
had zero length. The blkcipher constructors won't copy the IV to the
right place, however, when using a zero length input, resulting in
some significant problems when ciphers call their initialization
routines, only to find that the ->iv parameter is uninitialized. One
such example of this would be using chacha20poly1305 with a zero length
input, which then calls chacha20, which calls the key setup routine,
which eventually OOPSes due to the uninitialized ->iv member.
Signed-off-by: NJason A. Donenfeld <Jason@zx2c4.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

If the length of the plaintext is zero, there's no need to waste cycles
on encryption and decryption. Using the chacha20poly1305 construction
for zero-length plaintexts is a common way of using a shared encryption
key for AAD authentication.
Signed-off-by: NJason A. Donenfeld <Jason@zx2c4.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

This patch adds PKCS#1 v1.5 standard RSA padding as a separate template.
This way an RSA cipher with padding can be obtained by instantiating
"pkcs1pad(rsa)".  The reason for adding this is that RSA is almost
never used without this padding (or OAEP) so it will be needed for
either certificate work in the kernel or the userspace, and I also hear
that it is likely implemented by hardware RSA in which case hardware
implementations of the whole of pkcs1pad(rsa) can be provided.
Signed-off-by: NAndrew Zaborowski <andrew.zaborowski@intel.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

Add a struct akcipher_instance and struct akcipher_spawn similar to
how AEAD declares them and the macros for converting to/from
crypto_instance/crypto_spawn.  Also add register functions to
avoid exposing crypto_akcipher_type.
Signed-off-by: NAndrew Zaborowski <andrew.zaborowski@intel.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

cryptd_create_hash() fails by returning -EINVAL.  It is because after
8996eafd ("crypto: ahash - ensure statesize is non-zero") all ahash
drivers must have a non-zero statesize.

This patch fixes the problem by properly assigning the statesize.
Signed-off-by: NRui Wang <rui.y.wang@intel.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

This patch is a cleanup to make following patch easier to
review.

Goal is to move SOCK_ASYNC_NOSPACE and SOCK_ASYNC_WAITDATA
from (struct socket)->flags to a (struct socket_wq)->flags
to benefit from RCU protection in sock_wake_async()

To ease backports, we rename both constants.

Two new helpers, sk_set_bit(int nr, struct sock *sk)
and sk_clear_bit(int net, struct sock *sk) are added so that
following patch can change their implementation.
Signed-off-by: NEric Dumazet <edumazet@google.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>