1. 20 Dec, 2013 1 commit
  2. 12 Dec, 2013 3 commits
    • Shawn Landden's avatar
      net: update consumers of MSG_MORE to recognize MSG_SENDPAGE_NOTLAST · eb050d97
      Shawn Landden authored
      commit d3f7d56a7a4671d395e8af87071068a195257bf6 upstream.
      Commit 35f9c09f (tcp: tcp_sendpages() should call tcp_push() once)
      added an internal flag MSG_SENDPAGE_NOTLAST, similar to
      algif_hash, algif_skcipher, and udp used MSG_MORE from tcp_sendpages()
      and need to see the new flag as identical to MSG_MORE.
      This fixes sendfile() on AF_ALG.
      v3: also fix udp
      Cc: Tom Herbert <therbert@google.com>
      Cc: Eric Dumazet <eric.dumazet@gmail.com>
      Cc: David S. Miller <davem@davemloft.net>
      Reported-and-tested-by: default avatarShawn Landden <shawnlandden@gmail.com>
      Original-patch: Richard Weinberger <richard@nod.at>
      Signed-off-by: default avatarShawn Landden <shawn@churchofgit.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Tom Lendacky's avatar
      crypto: authenc - Find proper IV address in ablkcipher callback · 1c651d36
      Tom Lendacky authored
      commit fc019c7122dfcd69c50142b57a735539aec5da95 upstream.
      When performing an asynchronous ablkcipher operation the authenc
      completion callback routine is invoked, but it does not locate and use
      the proper IV.
      The callback routine, crypto_authenc_encrypt_done, is updated to use
      the same method of calculating the address of the IV as is done in
      crypto_authenc_encrypt function which sets up the callback.
      Signed-off-by: default avatarTom Lendacky <thomas.lendacky@amd.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Horia Geanta's avatar
      crypto: ccm - Fix handling of zero plaintext when computing mac · bf2e5230
      Horia Geanta authored
      commit 5638cabf3e4883f38dfb246c30980cebf694fbda upstream.
      There are cases when cryptlen can be zero in crypto_ccm_auth():
      -encryptiom: input scatterlist length is zero (no plaintext)
      -decryption: input scatterlist contains only the mac
      plus the condition of having different source and destination buffers
      (or else scatterlist length = max(plaintext_len, ciphertext_len)).
      These are not handled correctly, leading to crashes like:
      root@p4080ds:~/crypto# insmod tcrypt.ko mode=45
      ------------[ cut here ]------------
      kernel BUG at crypto/scatterwalk.c:37!
      Oops: Exception in kernel mode, sig: 5 [#1]
      SMP NR_CPUS=8 P4080 DS
      Modules linked in: tcrypt(+) crc32c xts xcbc vmac pcbc ecb gcm ghash_generic gf128mul ccm ctr seqiv
      CPU: 3 PID: 1082 Comm: cryptomgr_test Not tainted 3.11.0 #14
      task: ee12c5b0 ti: eecd0000 task.ti: eecd0000
      NIP: c0204d98 LR: f9225848 CTR: c0204d80
      REGS: eecd1b70 TRAP: 0700   Not tainted  (3.11.0)
      MSR: 00029002 <CE,EE,ME>  CR: 22044022  XER: 20000000
      GPR00: f9225c94 eecd1c20 ee12c5b0 eecd1c28 ee879400 ee879400 00000000 ee607464
      GPR08: 00000001 00000001 00000000 006b0000 c0204d80 00000000 00000002 c0698e20
      GPR16: ee987000 ee895000 fffffff4 ee879500 00000100 eecd1d58 00000001 00000000
      GPR24: ee879400 00000020 00000000 00000000 ee5b2800 ee607430 00000004 ee607460
      NIP [c0204d98] scatterwalk_start+0x18/0x30
      LR [f9225848] get_data_to_compute+0x28/0x2f0 [ccm]
      Call Trace:
      [eecd1c20] [f9225974] get_data_to_compute+0x154/0x2f0 [ccm] (unreliable)
      [eecd1c70] [f9225c94] crypto_ccm_auth+0x184/0x1d0 [ccm]
      [eecd1cb0] [f9225d40] crypto_ccm_encrypt+0x60/0x2d0 [ccm]
      [eecd1cf0] [c020d77c] __test_aead+0x3ec/0xe20
      [eecd1e20] [c020f35c] test_aead+0x6c/0xe0
      [eecd1e40] [c020f420] alg_test_aead+0x50/0xd0
      [eecd1e60] [c020e5e4] alg_test+0x114/0x2e0
      [eecd1ee0] [c020bd1c] cryptomgr_test+0x4c/0x60
      [eecd1ef0] [c0047058] kthread+0xa8/0xb0
      [eecd1f40] [c000eb0c] ret_from_kernel_thread+0x5c/0x64
      Instruction dump:
      0f080000 81290024 552807fe 0f080000 5529003a 4bffffb4 90830000 39400000
      39000001 8124000c 2f890000 7d28579e <0f090000> 81240008 91230004 4e800020
      ---[ end trace 6d652dfcd1be37bd ]---
      Cc: Jussi Kivilinna <jussi.kivilinna@mbnet.fi>
      Signed-off-by: default avatarHoria Geanta <horia.geanta@freescale.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
  3. 08 Dec, 2013 2 commits
    • Shawn Landden's avatar
      net: update consumers of MSG_MORE to recognize MSG_SENDPAGE_NOTLAST · 86a24344
      Shawn Landden authored
      [ Upstream commit d3f7d56a7a4671d395e8af87071068a195257bf6 ]
      Commit 35f9c09f (tcp: tcp_sendpages() should call tcp_push() once)
      added an internal flag MSG_SENDPAGE_NOTLAST, similar to
      algif_hash, algif_skcipher, and udp used MSG_MORE from tcp_sendpages()
      and need to see the new flag as identical to MSG_MORE.
      This fixes sendfile() on AF_ALG.
      v3: also fix udp
      Reported-and-tested-by: default avatarShawn Landden <shawnlandden@gmail.com>
      Cc: Tom Herbert <therbert@google.com>
      Cc: Eric Dumazet <eric.dumazet@gmail.com>
      Cc: David S. Miller <davem@davemloft.net>
      Original-patch: Richard Weinberger <richard@nod.at>
      Signed-off-by: default avatarShawn Landden <shawn@churchofgit.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Hannes Frederic Sowa's avatar
      net: rework recvmsg handler msg_name and msg_namelen logic · 2f73d7fd
      Hannes Frederic Sowa authored
      [ Upstream commit f3d3342602f8bcbf37d7c46641cb9bca7618eb1c ]
      This patch now always passes msg->msg_namelen as 0. recvmsg handlers must
      set msg_namelen to the proper size <= sizeof(struct sockaddr_storage)
      to return msg_name to the user.
      This prevents numerous uninitialized memory leaks we had in the
      recvmsg handlers and makes it harder for new code to accidentally leak
      uninitialized memory.
      Optimize for the case recvfrom is called with NULL as address. We don't
      need to copy the address at all, so set it to NULL before invoking the
      recvmsg handler. We can do so, because all the recvmsg handlers must
      cope with the case a plain read() is called on them. read() also sets
      msg_name to NULL.
      Also document these changes in include/linux/net.h as suggested by David
      Changes since RFC:
      Set msg->msg_name = NULL if user specified a NULL in msg_name but had a
      non-null msg_namelen in verify_iovec/verify_compat_iovec. This doesn't
      affect sendto as it would bail out earlier while trying to copy-in the
      address. It also more naturally reflects the logic by the callers of
      With this change in place I could remove "
      if (!uaddr || msg_sys->msg_namelen == 0)
      	msg->msg_name = NULL
      This change does not alter the user visible error logic as we ignore
      msg_namelen as long as msg_name is NULL.
      Also remove two unnecessary curly brackets in ___sys_recvmsg and change
      comments to netdev style.
      Cc: David Miller <davem@davemloft.net>
      Suggested-by: default avatarEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: default avatarHannes Frederic Sowa <hannes@stressinduktion.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
  4. 04 Dec, 2013 1 commit
    • David Howells's avatar
      X.509: Remove certificate date checks · d8f0a31a
      David Howells authored
      commit 124df926090b32a998483f6e43ebeccdbe5b5302 upstream.
      Remove the certificate date checks that are performed when a certificate is
      parsed.  There are two checks: a valid from and a valid to.  The first check is
      causing a lot of problems with system clocks that don't keep good time and the
      second places an implicit expiry date upon the kernel when used for module
      signing, so do we really need them?
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      cc: David Woodhouse <dwmw2@infradead.org>
      cc: Rusty Russell <rusty@rustcorp.com.au>
      cc: Josh Boyer <jwboyer@redhat.com>
      cc: Alexander Holler <holler@ahsoftware.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
  5. 29 Nov, 2013 1 commit
  6. 27 Sep, 2013 1 commit
  7. 13 Jul, 2013 1 commit
  8. 25 Jun, 2013 1 commit
    • Herbert Xu's avatar
      crypto: algboss - Hold ref count on larval · 939e1779
      Herbert Xu authored
      On Thu, Jun 20, 2013 at 10:00:21AM +0200, Daniel Borkmann wrote:
      > After having fixed a NULL pointer dereference in SCTP 1abd165e ("net:
      > sctp: fix NULL pointer dereference in socket destruction"), I ran into
      > the following NULL pointer dereference in the crypto subsystem with
      > the same reproducer, easily hit each time:
      > BUG: unable to handle kernel NULL pointer dereference at (null)
      > IP: [<ffffffff81070321>] __wake_up_common+0x31/0x90
      > PGD 0
      > Oops: 0000 [#1] SMP
      > Modules linked in: padlock_sha(F-) sha256_generic(F) sctp(F) libcrc32c(F) [..]
      > CPU: 6 PID: 3326 Comm: cryptomgr_probe Tainted: GF            3.10.0-rc5+ #1
      > Hardware name: Dell Inc. PowerEdge T410/0H19HD, BIOS 1.6.3 02/01/2011
      > task: ffff88007b6cf4e0 ti: ffff88007b7cc000 task.ti: ffff88007b7cc000
      > RIP: 0010:[<ffffffff81070321>]  [<ffffffff81070321>] __wake_up_common+0x31/0x90
      > RSP: 0018:ffff88007b7cde08  EFLAGS: 00010082
      > RAX: ffffffffffffffe8 RBX: ffff88003756c130 RCX: 0000000000000000
      > RDX: 0000000000000000 RSI: 0000000000000003 RDI: ffff88003756c130
      > RBP: ffff88007b7cde48 R08: 0000000000000000 R09: ffff88012b173200
      > R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000282
      > R13: ffff88003756c138 R14: 0000000000000000 R15: 0000000000000000
      > FS:  0000000000000000(0000) GS:ffff88012fc60000(0000) knlGS:0000000000000000
      > CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
      > CR2: 0000000000000000 CR3: 0000000001a0b000 CR4: 00000000000007e0
      > DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      > DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
      > Stack:
      >  ffff88007b7cde28 0000000300000000 ffff88007b7cde28 ffff88003756c130
      >  0000000000000282 ffff88003756c128 ffffffff81227670 0000000000000000
      >  ffff88007b7cde78 ffffffff810722b7 ffff88007cdcf000 ffffffff81a90540
      > Call Trace:
      >  [<ffffffff81227670>] ? crypto_alloc_pcomp+0x20/0x20
      >  [<ffffffff810722b7>] complete_all+0x47/0x60
      >  [<ffffffff81227708>] cryptomgr_probe+0x98/0xc0
      >  [<ffffffff81227670>] ? crypto_alloc_pcomp+0x20/0x20
      >  [<ffffffff8106760e>] kthread+0xce/0xe0
      >  [<ffffffff81067540>] ? kthread_freezable_should_stop+0x70/0x70
      >  [<ffffffff815450dc>] ret_from_fork+0x7c/0xb0
      >  [<ffffffff81067540>] ? kthread_freezable_should_stop+0x70/0x70
      > Code: 41 56 41 55 41 54 53 48 83 ec 18 66 66 66 66 90 89 75 cc 89 55 c8
      >       4c 8d 6f 08 48 8b 57 08 41 89 cf 4d 89 c6 48 8d 42 e
      > RIP  [<ffffffff81070321>] __wake_up_common+0x31/0x90
      >  RSP <ffff88007b7cde08>
      > CR2: 0000000000000000
      > ---[ end trace b495b19270a4d37e ]---
      > My assumption is that the following is happening: the minimal SCTP
      > tool runs under ``echo 1 > /proc/sys/net/sctp/auth_enable'', hence
      > it's making use of crypto_alloc_hash() via sctp_auth_init_hmacs().
      > It forks itself, heavily allocates, binds, listens and waits in
      > accept on sctp sockets, and then randomly kills some of them (no
      > need for an actual client in this case to hit this). Then, again,
      > allocating, binding, etc, and then killing child processes.
      > The problem that might be happening here is that cryptomgr requests
      > the module to probe/load through cryptomgr_schedule_probe(), but
      > before the thread handler cryptomgr_probe() returns, we return from
      > the wait_for_completion_interruptible() function and probably already
      > have cleared up larval, thus we run into a NULL pointer dereference
      > when in cryptomgr_probe() complete_all() is being called.
      > If we wait with wait_for_completion() instead, this panic will not
      > occur anymore. This is valid, because in case a signal is pending,
      > cryptomgr_probe() returns from probing anyway with properly calling
      > complete_all().
      The use of wait_for_completion_interruptible is intentional so that
      we don't lock up the thread if a bug causes us to never wake up.
      This bug is caused by the helper thread using the larval without
      holding a reference count on it.  If the helper thread completes
      after the original thread requesting for help has gone away and
      destroyed the larval, then we get the crash above.
      So the fix is to hold a reference count on the larval.
      Cc: <stable@vger.kernel.org> # 3.6+
      Reported-by: default avatarDaniel Borkmann <dborkman@redhat.com>
      Tested-by: default avatarDaniel Borkmann <dborkman@redhat.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
  9. 05 Jun, 2013 2 commits
  10. 30 Apr, 2013 1 commit
  11. 25 Apr, 2013 16 commits
  12. 22 Apr, 2013 1 commit
    • Chun-Yi Lee's avatar
      X.509: Support parse long form of length octets in Authority Key Identifier · 04b00bdb
      Chun-Yi Lee authored
      Per X.509 spec in section, the structure of Authority Key
      Identifier Extension is:
         AuthorityKeyIdentifier ::= SEQUENCE {
            keyIdentifier             [0] KeyIdentifier           OPTIONAL,
            authorityCertIssuer       [1] GeneralNames            OPTIONAL,
            authorityCertSerialNumber [2] CertificateSerialNumber OPTIONAL  }
         KeyIdentifier ::= OCTET STRING
      When a certificate also provides
      authorityCertIssuer and authorityCertSerialNumber then the length of
      AuthorityKeyIdentifier SEQUENCE is likely to long form format.
         The example certificate demos/tunala/A-server.pem in openssl source:
      X509v3 Authority Key Identifier:
          DirName:/C=NZ/L=Wellington/O=Really Irresponsible Authorisation Authority (RIAA)/OU=Cert-stamping/CN=Jackov al-Trades/emailAddress=none@fake.domain
      Current parsing rule of OID_authorityKeyIdentifier only take care the
      short form format, it causes load certificate to modsign_keyring fail:
      [   12.061147] X.509: Extension: 47
      [   12.075121] MODSIGN: Problem loading in-kernel X.509 certificate (-74)
      So, this patch add the parsing rule for support long form format against
      Authority Key Identifier.
      Changed the size check in "Short Form length" case, we allow v[3] smaller
      then (vlen - 4) because authorityCertIssuer and authorityCertSerialNumber
      are also possible attach in AuthorityKeyIdentifier sequence.
       - Removed comma from author's name.
       - Moved 'Short Form length' comment inside the if-body.
       - Changed the type of sub to size_t.
       - Use ASN1_INDEFINITE_LENGTH rather than writing 0x80 and 127.
       - Moved the key_len's value assignment before alter v.
       - Fixed the typo of octets.
       - Add 2 to v before entering the loop for calculate the length.
       - Removed the comment of check vlen.
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Cc: Josh Boyer <jwboyer@redhat.com>
      Cc: Randy Dunlap <rdunlap@xenotime.net>
      Cc: Herbert Xu <herbert@gondor.apana.org.au>
      Cc: "David S. Miller" <davem@davemloft.net>
      Acked-by: default avatarDavid Howells <dhowells@redhat.com>
      Signed-off-by: default avatarChun-Yi Lee <jlee@suse.com>
      Signed-off-by: default avatarRusty Russell <rusty@rustcorp.com.au>
  13. 10 Apr, 2013 1 commit
  14. 03 Apr, 2013 1 commit
  15. 02 Apr, 2013 1 commit
  16. 10 Mar, 2013 1 commit
  17. 28 Feb, 2013 1 commit
    • Sasha Levin's avatar
      hlist: drop the node parameter from iterators · b67bfe0d
      Sasha Levin authored
      I'm not sure why, but the hlist for each entry iterators were conceived
              list_for_each_entry(pos, head, member)
      The hlist ones were greedy and wanted an extra parameter:
              hlist_for_each_entry(tpos, pos, head, member)
      Why did they need an extra pos parameter? I'm not quite sure. Not only
      they don't really need it, it also prevents the iterator from looking
      exactly like the list iterator, which is unfortunate.
      Besides the semantic patch, there was some manual work required:
       - Fix up the actual hlist iterators in linux/list.h
       - Fix up the declaration of other iterators based on the hlist ones.
       - A very small amount of places were using the 'node' parameter, this
       was modified to use 'obj->member' instead.
       - Coccinelle didn't handle the hlist_for_each_entry_safe iterator
       properly, so those had to be fixed up manually.
      The semantic patch which is mostly the work of Peter Senna Tschudin is here:
      iterator name hlist_for_each_entry, hlist_for_each_entry_continue, hlist_for_each_entry_from, hlist_for_each_entry_rcu, hlist_for_each_entry_rcu_bh, hlist_for_each_entry_continue_rcu_bh, for_each_busy_worker, ax25_uid_for_each, ax25_for_each, inet_bind_bucket_for_each, sctp_for_each_hentry, sk_for_each, sk_for_each_rcu, sk_for_each_from, sk_for_each_safe, sk_for_each_bound, hlist_for_each_entry_safe, hlist_for_each_entry_continue_rcu, nr_neigh_for_each, nr_neigh_for_each_safe, nr_node_for_each, nr_node_for_each_safe, for_each_gfn_indirect_valid_sp, for_each_gfn_sp, for_each_host;
      type T;
      expression a,c,d,e;
      identifier b;
      statement S;
      -T b;
          <+... when != b
      - b,
      c, d) S
      - b,
      c) S
      - b,
      c) S
      - b,
      c, d) S
      - b,
      c, d) S
      - b,
      c) S
      for_each_busy_worker(a, c,
      - b,
      d) S
      - b,
      c) S
      - b,
      c) S
      - b,
      c) S
      - b,
      c) S
      - b,
      c) S
      - b,
      c) S
      -(a, b)
      + sk_for_each_from(a) S
      - b,
      c, d) S
      - b,
      c) S
      - b,
      c, d, e) S
      - b,
      c) S
      - b,
      c) S
      - b,
      c, d) S
      - b,
      c) S
      - b,
      c, d) S
      - for_each_gfn_sp(a, c, d, b) S
      + for_each_gfn_sp(a, c, d) S
      - for_each_gfn_indirect_valid_sp(a, c, d, b) S
      + for_each_gfn_indirect_valid_sp(a, c, d) S
      - b,
      c) S
      - b,
      c, d) S
      - b,
      c, d) S
      [akpm@linux-foundation.org: drop bogus change from net/ipv4/raw.c]
      [akpm@linux-foundation.org: drop bogus hunk from net/ipv6/raw.c]
      [akpm@linux-foundation.org: checkpatch fixes]
      [akpm@linux-foundation.org: fix warnings]
      [akpm@linux-foudnation.org: redo intrusive kvm changes]
      Tested-by: default avatarPeter Senna Tschudin <peter.senna@gmail.com>
      Acked-by: default avatarPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      Cc: Wu Fengguang <fengguang.wu@intel.com>
      Cc: Marcelo Tosatti <mtosatti@redhat.com>
      Cc: Gleb Natapov <gleb@redhat.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
  18. 26 Feb, 2013 1 commit
  19. 20 Feb, 2013 1 commit
  20. 19 Feb, 2013 2 commits