<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux/crypto, branch v4.3</title>
<subtitle>Mirror of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/
</subtitle>
<id>https://git.shady.money/linux/atom?h=v4.3</id>
<link rel='self' href='https://git.shady.money/linux/atom?h=v4.3'/>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/'/>
<updated>2015-10-27T22:20:10Z</updated>
<entry>
<title>Merge branch 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6</title>
<updated>2015-10-27T22:20:10Z</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2015-10-27T22:20:10Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=dc5bc3f1e3d886ce1193281bb2bfb2b44f4aeae4'/>
<id>urn:sha1:dc5bc3f1e3d886ce1193281bb2bfb2b44f4aeae4</id>
<content type='text'>
Pull crypto fix from Herbert Xu:
 "This fixes a problem in the Crypto API that may cause spurious errors
  when signals are received by the process that made the orignal system
  call into the kernel"

* 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6:
  crypto: api - Only abort operations on fatal signal
</content>
</entry>
<entry>
<title>crypto: api - Only abort operations on fatal signal</title>
<updated>2015-10-20T13:59:25Z</updated>
<author>
<name>Herbert Xu</name>
<email>herbert@gondor.apana.org.au</email>
</author>
<published>2015-10-19T10:23:57Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=3fc89adb9fa4beff31374a4bf50b3d099d88ae83'/>
<id>urn:sha1:3fc89adb9fa4beff31374a4bf50b3d099d88ae83</id>
<content type='text'>
Currently a number of Crypto API operations may fail when a signal
occurs.  This causes nasty problems as the caller of those operations
are often not in a good position to restart the operation.

In fact there is currently no need for those operations to be
interrupted by user signals at all.  All we need is for them to
be killable.

This patch replaces the relevant calls of signal_pending with
fatal_signal_pending, and wait_for_completion_interruptible with
wait_for_completion_killable, respectively.

Cc: stable@vger.kernel.org
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
</content>
</entry>
<entry>
<title>Merge git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6</title>
<updated>2015-10-13T17:18:54Z</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2015-10-13T17:18:54Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=6006d4521b158e5ef48620e8c9028bba91bf985d'/>
<id>urn:sha1:6006d4521b158e5ef48620e8c9028bba91bf985d</id>
<content type='text'>
Pull crypto fixes from Herbert Xu:
 "This fixes the following issues:

   - Fix AVX detection to prevent use of non-existent AESNI.

   - Some SPARC ciphers did not set their IV size which may lead to
     memory corruption"

* git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6:
  crypto: ahash - ensure statesize is non-zero
  crypto: camellia_aesni_avx - Fix CPU feature checks
  crypto: sparc - initialize blkcipher.ivsize
</content>
</entry>
<entry>
<title>crypto: ahash - ensure statesize is non-zero</title>
<updated>2015-10-13T14:28:10Z</updated>
<author>
<name>Russell King</name>
<email>rmk+kernel@arm.linux.org.uk</email>
</author>
<published>2015-10-09T19:43:33Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=8996eafdcbad149ac0f772fb1649fbb75c482a6a'/>
<id>urn:sha1:8996eafdcbad149ac0f772fb1649fbb75c482a6a</id>
<content type='text'>
Unlike shash algorithms, ahash drivers must implement export
and import as their descriptors may contain hardware state and
cannot be exported as is.  Unfortunately some ahash drivers did
not provide them and end up causing crashes with algif_hash.

This patch adds a check to prevent these drivers from registering
ahash algorithms until they are fixed.

Cc: stable@vger.kernel.org
Signed-off-by: Russell King &lt;rmk+kernel@arm.linux.org.uk&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
</content>
</entry>
<entry>
<title>X.509: Don't strip leading 00's from key ID when constructing key description</title>
<updated>2015-09-25T15:31:46Z</updated>
<author>
<name>David Howells</name>
<email>dhowells@redhat.com</email>
</author>
<published>2015-09-25T15:31:46Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=e7c87bef7de2417b219d4dbfe8d33a0098a8df54'/>
<id>urn:sha1:e7c87bef7de2417b219d4dbfe8d33a0098a8df54</id>
<content type='text'>
Don't strip leading zeros from the crypto key ID when using it to construct
the struct key description as the signature in kernels up to and including
4.2 matched this aspect of the key.  This means that 1 in 256 keys won't
actually match if their key ID begins with 00.

The key ID is stored in the module signature as binary and so must be
converted to text in order to invoke request_key() - but it isn't stripped
at this point.

Something like this is likely to be observed in dmesg when the key is loaded:

[    1.572423] Loaded X.509 cert 'Build time autogenerated kernel
    key: 62a7c3d2da278be024da4af8652c071f3fea33'

followed by this when we try and use it:

  [    1.646153] Request for unknown module key 'Build time autogenerated
    kernel key: 0062a7c3d2da278be024da4af8652c071f3fea33' err -11

The 'Loaded' line should show an extra '00' on the front of the hex string.

This problem should not affect 4.3-rc1 and onwards because there the key
should be matched on one of its auxiliary identities rather than the key
struct's description string.

Reported-by: Arjan van de Ven &lt;arjan@linux.intel.com&gt;
Reported-by: Andy Whitcroft &lt;apw@canonical.com&gt;
Signed-off-by: David Howells &lt;dhowells@redhat.com&gt;
</content>
</entry>
<entry>
<title>Merge git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6</title>
<updated>2015-09-16T14:53:33Z</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2015-09-16T14:53:33Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=aa57e0b281453334267e836d15cfdb933f6d6f97'/>
<id>urn:sha1:aa57e0b281453334267e836d15cfdb933f6d6f97</id>
<content type='text'>
Pull crypto fixes from Herbert Xu:
 "This fixes the following issues:

   - The selftest overreads the IV test vector.

  - Fix potential infinite loop in sunxi-ss driver.

   - Fix powerpc build failure when VMX is set without VSX"

* git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6:
  crypto: testmgr - don't copy from source IV too much
  crypto: sunxi-ss - Fix a possible driver hang with ciphers
  crypto: vmx - VMX crypto should depend on CONFIG_VSX
</content>
</entry>
<entry>
<title>crypto: testmgr - don't copy from source IV too much</title>
<updated>2015-09-11T14:09:43Z</updated>
<author>
<name>Andrey Ryabinin</name>
<email>aryabinin@virtuozzo.com</email>
</author>
<published>2015-09-10T10:11:55Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=84cba178a3b88efe2668a9039f70abda072faa21'/>
<id>urn:sha1:84cba178a3b88efe2668a9039f70abda072faa21</id>
<content type='text'>
While the destination buffer 'iv' is MAX_IVLEN size,
the source 'template[i].iv' could be smaller, thus
memcpy may read read invalid memory.
Use crypto_skcipher_ivsize() to get real ivsize
and pass it to memcpy.

Signed-off-by: Andrey Ryabinin &lt;aryabinin@virtuozzo.com&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
</content>
</entry>
<entry>
<title>Merge branch 'next' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security</title>
<updated>2015-09-08T19:41:25Z</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2015-09-08T19:41:25Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=b793c005ceabf6db0b17494b0ec67ade6796bb34'/>
<id>urn:sha1:b793c005ceabf6db0b17494b0ec67ade6796bb34</id>
<content type='text'>
Pull security subsystem updates from James Morris:
 "Highlights:

   - PKCS#7 support added to support signed kexec, also utilized for
     module signing.  See comments in 3f1e1bea.

     ** NOTE: this requires linking against the OpenSSL library, which
        must be installed, e.g.  the openssl-devel on Fedora **

   - Smack
      - add IPv6 host labeling; ignore labels on kernel threads
      - support smack labeling mounts which use binary mount data

   - SELinux:
      - add ioctl whitelisting (see
        http://kernsec.org/files/lss2015/vanderstoep.pdf)
      - fix mprotect PROT_EXEC regression caused by mm change

   - Seccomp:
      - add ptrace options for suspend/resume"

* 'next' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security: (57 commits)
  PKCS#7: Add OIDs for sha224, sha284 and sha512 hash algos and use them
  Documentation/Changes: Now need OpenSSL devel packages for module signing
  scripts: add extract-cert and sign-file to .gitignore
  modsign: Handle signing key in source tree
  modsign: Use if_changed rule for extracting cert from module signing key
  Move certificate handling to its own directory
  sign-file: Fix warning about BIO_reset() return value
  PKCS#7: Add MODULE_LICENSE() to test module
  Smack - Fix build error with bringup unconfigured
  sign-file: Document dependency on OpenSSL devel libraries
  PKCS#7: Appropriately restrict authenticated attributes and content type
  KEYS: Add a name for PKEY_ID_PKCS7
  PKCS#7: Improve and export the X.509 ASN.1 time object decoder
  modsign: Use extract-cert to process CONFIG_SYSTEM_TRUSTED_KEYS
  extract-cert: Cope with multiple X.509 certificates in a single file
  sign-file: Generate CMS message as signature instead of PKCS#7
  PKCS#7: Support CMS messages also [RFC5652]
  X.509: Change recorded SKID &amp; AKID to not include Subject or Issuer
  PKCS#7: Check content type and versions
  MAINTAINERS: The keyrings mailing list has moved
  ...
</content>
</entry>
<entry>
<title>Merge branch 'for-4.3/sg' of git://git.kernel.dk/linux-block</title>
<updated>2015-09-02T20:22:38Z</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2015-09-02T20:22:38Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=d975f309a8b250e67b66eabeb56be6989c783629'/>
<id>urn:sha1:d975f309a8b250e67b66eabeb56be6989c783629</id>
<content type='text'>
Pull SG updates from Jens Axboe:
 "This contains a set of scatter-gather related changes/fixes for 4.3:

   - Add support for limited chaining of sg tables even for
     architectures that do not set ARCH_HAS_SG_CHAIN.  From Christoph.

   - Add sg chain support to target_rd.  From Christoph.

   - Fixup open coded sg-&gt;page_link in crypto/omap-sham.  From
     Christoph.

   - Fixup open coded crypto -&gt;page_link manipulation.  From Dan.

   - Also from Dan, automated fixup of manual sg_unmark_end()
     manipulations.

   - Also from Dan, automated fixup of open coded sg_phys()
     implementations.

   - From Robert Jarzmik, addition of an sg table splitting helper that
     drivers can use"

* 'for-4.3/sg' of git://git.kernel.dk/linux-block:
  lib: scatterlist: add sg splitting function
  scatterlist: use sg_phys()
  crypto/omap-sham: remove an open coded access to -&gt;page_link
  scatterlist: remove open coded sg_unmark_end instances
  crypto: replace scatterwalk_sg_chain with sg_chain
  target/rd: always chain S/G list
  scatterlist: allow limited chaining without ARCH_HAS_SG_CHAIN
</content>
</entry>
<entry>
<title>PKCS#7: Add OIDs for sha224, sha284 and sha512 hash algos and use them</title>
<updated>2015-08-31T23:59:20Z</updated>
<author>
<name>David Howells</name>
<email>dhowells@redhat.com</email>
</author>
<published>2015-08-30T15:59:57Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=07f081fb5057b2ea98baeca3a47bf0eb33e94aa1'/>
<id>urn:sha1:07f081fb5057b2ea98baeca3a47bf0eb33e94aa1</id>
<content type='text'>
Add OIDs for sha224, sha284 and sha512 hash algos and use them to select
the hashing algorithm.  Without this, something like the following error
might get written to dmesg:

[   31.829322] PKCS7: Unknown OID: [32] 2.16.840.1.101.3.4.2.3
[   31.829328] PKCS7: Unknown OID: [180] 2.16.840.1.101.3.4.2.3
[   31.829330] Unsupported digest algo: 55

Where the 55 on the third line is OID__NR indicating an unknown OID.

Reported-by: Valdis Kletnieks &lt;Valdis.Kletnieks@vt.edu&gt;
Signed-off-by: David Howells &lt;dhowells@redhat.com&gt;
Tested-By: Valdis Kletnieks &lt;valdis.kletnieks@vt.edu&gt;
Signed-off-by: James Morris &lt;james.l.morris@oracle.com&gt;
</content>
</entry>
</feed>
