1. 18 Feb, 2019 1 commit
    • Mao Wenan's avatar
      net: crypto set sk to NULL when af_alg_release. · 9060cb71
      Mao Wenan authored
      KASAN has found use-after-free in sockfs_setattr.
      The existed commit 6d8c50dc ("socket: close race condition between sock_close()
      and sockfs_setattr()") is to fix this simillar issue, but it seems to ignore
      that crypto module forgets to set the sk to NULL after af_alg_release.
      KASAN report details as below:
      BUG: KASAN: use-after-free in sockfs_setattr+0x120/0x150
      Write of size 4 at addr ffff88837b956128 by task syz-executor0/4186
      CPU: 2 PID: 4186 Comm: syz-executor0 Not tainted xxx + #1
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
      1.10.2-1ubuntu1 04/01/2014
      Call Trace:
       ? vprintk_func+0x5e/0xf0
       ? sockfs_setattr+0x120/0x150
       ? sock_register+0x2d0/0x2d0
       ? chown_common+0x2ef/0x510
       ? chmod_common+0x3b0/0x3b0
       ? __lock_is_held+0xbc/0x160
       ? __sb_start_write+0x13d/0x2b0
       ? __mnt_want_write+0x19a/0x250
       ? __ia32_sys_chmod+0x80/0x80
       ? trace_hardirqs_on_thunk+0x1a/0x1c
       ? lockdep_hardirqs_on+0x39a/0x5e0
      RIP: 0033:0x462589
      Code: f7 d8 64 89 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 48 89 f8 48 89
      f7 48 89 d6 48 89
      ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3
      48 c7 c1 bc ff ff
      ff f7 d8 64 89 01 48
      RSP: 002b:00007fb4b2c83c58 EFLAGS: 00000246 ORIG_RAX: 0000000000000104
      RAX: ffffffffffffffda RBX: 000000000072bfa0 RCX: 0000000000462589
      RDX: 0000000000000000 RSI: 00000000200000c0 RDI: 0000000000000007
      RBP: 0000000000000005 R08: 0000000000001000 R09: 0000000000000000
      R10: 0000000000000000 R11: 0000000000000246 R12: 00007fb4b2c846bc
      R13: 00000000004bc733 R14: 00000000006f5138 R15: 00000000ffffffff
      Allocated by task 4185:
      Freed by task 4184:
      Syzkaller reproducer:
      r0 = perf_event_open(&(0x7f0000000000)={0x0, 0x70, 0x0, 0x0, 0x0, 0x0,
      0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
      0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
      0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, @perf_config_ext}, 0x0, 0x0,
      0xffffffffffffffff, 0x0)
      r1 = socket$alg(0x26, 0x5, 0x0)
      getrusage(0x0, 0x0)
      bind(r1, &(0x7f00000001c0)=@alg={0x26, 'hash\x00', 0x0, 0x0,
      'sha256-ssse3\x00'}, 0x80)
      r2 = accept(r1, 0x0, 0x0)
      r3 = accept4$unix(r2, 0x0, 0x0, 0x0)
      r4 = dup3(r3, r0, 0x0)
      fchownat(r4, &(0x7f00000000c0)='\x00', 0x0, 0x0, 0x1000)
      Fixes: 6d8c50dc ("socket: close race condition between sock_close() and sockfs_setattr()")
      Signed-off-by: default avatarMao Wenan <maowenan@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
  2. 10 Jan, 2019 4 commits
    • Eric Biggers's avatar
      crypto: sm3 - fix undefined shift by >= width of value · d45a90cb
      Eric Biggers authored
      sm3_compress() calls rol32() with shift >= 32, which causes undefined
      behavior.  This is easily detected by enabling CONFIG_UBSAN.
      Explicitly AND with 31 to make the behavior well defined.
      Fixes: 4f0fc160 ("crypto: sm3 - add OSCCA SM3 secure hash")
      Cc: <stable@vger.kernel.org> # v4.15+
      Cc: Gilad Ben-Yossef <gilad@benyossef.com>
      Signed-off-by: default avatarEric Biggers <ebiggers@google.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
    • Eric Biggers's avatar
      crypto: adiantum - initialize crypto_spawn::inst · 6db43410
      Eric Biggers authored
      crypto_grab_*() doesn't set crypto_spawn::inst, so templates must set it
      beforehand.  Otherwise it will be left NULL, which causes a crash in
      certain cases where algorithms are dynamically loaded/unloaded.  E.g.
      with CONFIG_CRYPTO_CHACHA20_X86_64=m, the following caused a crash:
          insmod chacha-x86_64.ko
          python -c 'import socket; socket.socket(socket.AF_ALG, 5, 0).bind(("skcipher", "adiantum(xchacha12,aes)"))'
          rmmod chacha-x86_64.ko
          python -c 'import socket; socket.socket(socket.AF_ALG, 5, 0).bind(("skcipher", "adiantum(xchacha12,aes)"))'
      Fixes: 059c2a4d ("crypto: adiantum - add Adiantum support")
      Signed-off-by: default avatarEric Biggers <ebiggers@google.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
    • Harsh Jain's avatar
      crypto: authencesn - Avoid twice completion call in decrypt path · a7773363
      Harsh Jain authored
      Authencesn template in decrypt path unconditionally calls aead_request_complete
      after ahash_verify which leads to following kernel panic in after decryption.
      [  338.539800] BUG: unable to handle kernel NULL pointer dereference at 0000000000000004
      [  338.548372] PGD 0 P4D 0
      [  338.551157] Oops: 0000 [#1] SMP PTI
      [  338.554919] CPU: 0 PID: 0 Comm: swapper/0 Kdump: loaded Tainted: G        W I       4.19.7+ #13
      [  338.564431] Hardware name: Supermicro X8ST3/X8ST3, BIOS 2.0        07/29/10
      [  338.572212] RIP: 0010:esp_input_done2+0x350/0x410 [esp4]
      [  338.578030] Code: ff 0f b6 68 10 48 8b 83 c8 00 00 00 e9 8e fe ff ff 8b 04 25 04 00 00 00 83 e8 01 48 98 48 8b 3c c5 10 00 00 00 e9 f7 fd ff ff <8b> 04 25 04 00 00 00 83 e8 01 48 98 4c 8b 24 c5 10 00 00 00 e9 3b
      [  338.598547] RSP: 0018:ffff911c97803c00 EFLAGS: 00010246
      [  338.604268] RAX: 0000000000000002 RBX: ffff911c4469ee00 RCX: 0000000000000000
      [  338.612090] RDX: 0000000000000000 RSI: 0000000000000130 RDI: ffff911b87c20400
      [  338.619874] RBP: 0000000000000000 R08: ffff911b87c20498 R09: 000000000000000a
      [  338.627610] R10: 0000000000000001 R11: 0000000000000004 R12: 0000000000000000
      [  338.635402] R13: ffff911c89590000 R14: ffff911c91730000 R15: 0000000000000000
      [  338.643234] FS:  0000000000000000(0000) GS:ffff911c97800000(0000) knlGS:0000000000000000
      [  338.652047] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [  338.658299] CR2: 0000000000000004 CR3: 00000001ec20a000 CR4: 00000000000006f0
      [  338.666382] Call Trace:
      [  338.669051]  <IRQ>
      [  338.671254]  esp_input_done+0x12/0x20 [esp4]
      [  338.675922]  chcr_handle_resp+0x3b5/0x790 [chcr]
      [  338.680949]  cpl_fw6_pld_handler+0x37/0x60 [chcr]
      [  338.686080]  chcr_uld_rx_handler+0x22/0x50 [chcr]
      [  338.691233]  uldrx_handler+0x8c/0xc0 [cxgb4]
      [  338.695923]  process_responses+0x2f0/0x5d0 [cxgb4]
      [  338.701177]  ? bitmap_find_next_zero_area_off+0x3a/0x90
      [  338.706882]  ? matrix_alloc_area.constprop.7+0x60/0x90
      [  338.712517]  ? apic_update_irq_cfg+0x82/0xf0
      [  338.717177]  napi_rx_handler+0x14/0xe0 [cxgb4]
      [  338.722015]  net_rx_action+0x2aa/0x3e0
      [  338.726136]  __do_softirq+0xcb/0x280
      [  338.730054]  irq_exit+0xde/0xf0
      [  338.733504]  do_IRQ+0x54/0xd0
      [  338.736745]  common_interrupt+0xf/0xf
      Fixes: 104880a6 ("crypto: authencesn - Convert to new AEAD...")
      Signed-off-by: default avatarHarsh Jain <harsh@chelsio.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
    • Eric Biggers's avatar
      crypto: authenc - fix parsing key with misaligned rta_len · 8f9c4693
      Eric Biggers authored
      Keys for "authenc" AEADs are formatted as an rtattr containing a 4-byte
      'enckeylen', followed by an authentication key and an encryption key.
      crypto_authenc_extractkeys() parses the key to find the inner keys.
      However, it fails to consider the case where the rtattr's payload is
      longer than 4 bytes but not 4-byte aligned, and where the key ends
      before the next 4-byte aligned boundary.  In this case, 'keylen -=
      RTA_ALIGN(rta->rta_len);' underflows to a value near UINT_MAX.  This
      causes a buffer overread and crash during crypto_ahash_setkey().
      Fix it by restricting the rtattr payload to the expected size.
      Reproducer using AF_ALG:
      	#include <linux/if_alg.h>
      	#include <linux/rtnetlink.h>
      	#include <sys/socket.h>
      	int main()
      		int fd;
      		struct sockaddr_alg addr = {
      			.salg_type = "aead",
      			.salg_name = "authenc(hmac(sha256),cbc(aes))",
      		struct {
      			struct rtattr attr;
      			__be32 enckeylen;
      			char keys[1];
      		} __attribute__((packed)) key = {
      			.attr.rta_len = sizeof(key),
      			.attr.rta_type = 1 /* CRYPTO_AUTHENC_KEYA_PARAM */,
      		fd = socket(AF_ALG, SOCK_SEQPACKET, 0);
      		bind(fd, (void *)&addr, sizeof(addr));
      		setsockopt(fd, SOL_ALG, ALG_SET_KEY, &key, sizeof(key));
      It caused:
      	BUG: unable to handle kernel paging request at ffff88007ffdc000
      	PGD 2e01067 P4D 2e01067 PUD 2e04067 PMD 2e05067 PTE 0
      	Oops: 0000 [#1] SMP
      	CPU: 0 PID: 883 Comm: authenc Not tainted 4.20.0-rc1-00108-g00c9fe37 #13
      	Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-20181126_142135-anatol 04/01/2014
      	RIP: 0010:sha256_ni_transform+0xb3/0x330 arch/x86/crypto/sha256_ni_asm.S:155
      	Call Trace:
      	 sha256_ni_finup+0x10/0x20 arch/x86/crypto/sha256_ssse3_glue.c:321
      	 crypto_shash_finup+0x1a/0x30 crypto/shash.c:178
      	 shash_digest_unaligned+0x45/0x60 crypto/shash.c:186
      	 crypto_shash_digest+0x24/0x40 crypto/shash.c:202
      	 hmac_setkey+0x135/0x1e0 crypto/hmac.c:66
      	 crypto_shash_setkey+0x2b/0xb0 crypto/shash.c:66
      	 shash_async_setkey+0x10/0x20 crypto/shash.c:223
      	 crypto_ahash_setkey+0x2d/0xa0 crypto/ahash.c:202
      	 crypto_authenc_setkey+0x68/0x100 crypto/authenc.c:96
      	 crypto_aead_setkey+0x2a/0xc0 crypto/aead.c:62
      	 aead_setkey+0xc/0x10 crypto/algif_aead.c:526
      	 alg_setkey crypto/af_alg.c:223 [inline]
      	 alg_setsockopt+0xfe/0x130 crypto/af_alg.c:256
      	 __sys_setsockopt+0x6d/0xd0 net/socket.c:1902
      	 __do_sys_setsockopt net/socket.c:1913 [inline]
      	 __se_sys_setsockopt net/socket.c:1910 [inline]
      	 __x64_sys_setsockopt+0x1f/0x30 net/socket.c:1910
      	 do_syscall_64+0x4a/0x180 arch/x86/entry/common.c:290
      Fixes: e236d4a8 ("[CRYPTO] authenc: Move enckeylen into key itself")
      Cc: <stable@vger.kernel.org> # v2.6.25+
      Signed-off-by: default avatarEric Biggers <ebiggers@google.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
  3. 23 Dec, 2018 4 commits
  4. 21 Dec, 2018 1 commit
  5. 13 Dec, 2018 11 commits
  6. 07 Dec, 2018 11 commits
  7. 29 Nov, 2018 1 commit
  8. 27 Nov, 2018 1 commit
  9. 20 Nov, 2018 6 commits
    • Eric Biggers's avatar
      crypto: adiantum - add Adiantum support · 059c2a4d
      Eric Biggers authored
      Add support for the Adiantum encryption mode.  Adiantum was designed by
      Paul Crowley and is specified by our paper:
          Adiantum: length-preserving encryption for entry-level processors
      See our paper for full details; this patch only provides an overview.
      Adiantum is a tweakable, length-preserving encryption mode designed for
      fast and secure disk encryption, especially on CPUs without dedicated
      crypto instructions.  Adiantum encrypts each sector using the XChaCha12
      stream cipher, two passes of an ε-almost-∆-universal (εA∆U) hash
      function, and an invocation of the AES-256 block cipher on a single
      16-byte block.  On CPUs without AES instructions, Adiantum is much
      faster than AES-XTS; for example, on ARM Cortex-A7, on 4096-byte sectors
      Adiantum encryption is about 4 times faster than AES-256-XTS encryption,
      and decryption about 5 times faster.
      Adiantum is a specialization of the more general HBSH construction.  Our
      earlier proposal, HPolyC, was also a HBSH specialization, but it used a
      different εA∆U hash function, one based on Poly1305 only.  Adiantum's
      εA∆U hash function, which is based primarily on the "NH" hash function
      like that used in UMAC (RFC4418), is about twice as fast as HPolyC's;
      consequently, Adiantum is about 20% faster than HPolyC.
      This speed comes with no loss of security: Adiantum is provably just as
      secure as HPolyC, in fact slightly *more* secure.  Like HPolyC,
      Adiantum's security is reducible to that of XChaCha12 and AES-256,
      subject to a security bound.  XChaCha12 itself has a security reduction
      to ChaCha12.  Therefore, one need not "trust" Adiantum; one need only
      trust ChaCha12 and AES-256.  Note that the εA∆U hash function is only
      used for its proven combinatorical properties so cannot be "broken".
      Adiantum is also a true wide-block encryption mode, so flipping any
      plaintext bit in the sector scrambles the entire ciphertext, and vice
      versa.  No other such mode is available in the kernel currently; doing
      the same with XTS scrambles only 16 bytes.  Adiantum also supports
      arbitrary-length tweaks and naturally supports any length input >= 16
      bytes without needing "ciphertext stealing".
      For the stream cipher, Adiantum uses XChaCha12 rather than XChaCha20 in
      order to make encryption feasible on the widest range of devices.
      Although the 20-round variant is quite popular, the best known attacks
      on ChaCha are on only 7 rounds, so ChaCha12 still has a substantial
      security margin; in fact, larger than AES-256's.  12-round Salsa20 is
      also the eSTREAM recommendation.  For the block cipher, Adiantum uses
      AES-256, despite it having a lower security margin than XChaCha12 and
      needing table lookups, due to AES's extensive adoption and analysis
      making it the obvious first choice.  Nevertheless, for flexibility this
      patch also permits the "adiantum" template to be instantiated with
      XChaCha20 and/or with an alternate block cipher.
      We need Adiantum support in the kernel for use in dm-crypt and fscrypt,
      where currently the only other suitable options are block cipher modes
      such as AES-XTS.  A big problem with this is that many low-end mobile
      devices (e.g. Android Go phones sold primarily in developing countries,
      as well as some smartwatches) still have CPUs that lack AES
      instructions, e.g. ARM Cortex-A7.  Sadly, AES-XTS encryption is much too
      slow to be viable on these devices.  We did find that some "lightweight"
      block ciphers are fast enough, but these suffer from problems such as
      not having much cryptanalysis or being too controversial.
      The ChaCha stream cipher has excellent performance but is insecure to
      use directly for disk encryption, since each sector's IV is reused each
      time it is overwritten.  Even restricting the threat model to offline
      attacks only isn't enough, since modern flash storage devices don't
      guarantee that "overwrites" are really overwrites, due to wear-leveling.
      Adiantum avoids this problem by constructing a
      "tweakable super-pseudorandom permutation"; this is the strongest
      possible security model for length-preserving encryption.
      Of course, storing random nonces along with the ciphertext would be the
      ideal solution.  But doing that with existing hardware and filesystems
      runs into major practical problems; in most cases it would require data
      journaling (like dm-integrity) which severely degrades performance.
      Thus, for now length-preserving encryption is still needed.
      Signed-off-by: default avatarEric Biggers <ebiggers@google.com>
      Reviewed-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
    • Eric Biggers's avatar
      crypto: nhpoly1305 - add NHPoly1305 support · 26609a21
      Eric Biggers authored
      Add a generic implementation of NHPoly1305, an ε-almost-∆-universal hash
      function used in the Adiantum encryption mode.
      CONFIG_NHPOLY1305 is not selectable by itself since there won't be any
      real reason to enable it without also enabling Adiantum support.
      Signed-off-by: default avatarEric Biggers <ebiggers@google.com>
      Acked-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
    • Eric Biggers's avatar
      crypto: poly1305 - add Poly1305 core API · 1b6fd3d5
      Eric Biggers authored
      Expose a low-level Poly1305 API which implements the
      ε-almost-∆-universal (εA∆U) hash function underlying the Poly1305 MAC
      and supports block-aligned inputs only.
      This is needed for Adiantum hashing, which builds an εA∆U hash function
      from NH and a polynomial evaluation in GF(2^{130}-5); this polynomial
      evaluation is identical to the one the Poly1305 MAC does.  However, the
      crypto_shash Poly1305 API isn't very appropriate for this because its
      calling convention assumes it is used as a MAC, with a 32-byte "one-time
      key" provided for every digest.
      But by design, in Adiantum hashing the performance of the polynomial
      evaluation isn't nearly as critical as NH.  So it suffices to just have
      some C helper functions.  Thus, this patch adds such functions.
      Acked-by: default avatarMartin Willi <martin@strongswan.org>
      Signed-off-by: default avatarEric Biggers <ebiggers@google.com>
      Acked-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
    • Eric Biggers's avatar
      crypto: poly1305 - use structures for key and accumulator · 878afc35
      Eric Biggers authored
      In preparation for exposing a low-level Poly1305 API which implements
      the ε-almost-∆-universal (εA∆U) hash function underlying the Poly1305
      MAC and supports block-aligned inputs only, create structures
      poly1305_key and poly1305_state which hold the limbs of the Poly1305
      "r" key and accumulator, respectively.
      These structures could actually have the same type (e.g. poly1305_val),
      but different types are preferable, to prevent misuse.
      Acked-by: default avatarMartin Willi <martin@strongswan.org>
      Signed-off-by: default avatarEric Biggers <ebiggers@google.com>
      Acked-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
    • Eric Biggers's avatar
      crypto: chacha - add XChaCha12 support · aa762409
      Eric Biggers authored
      Now that the generic implementation of ChaCha20 has been refactored to
      allow varying the number of rounds, add support for XChaCha12, which is
      the XSalsa construction applied to ChaCha12.  ChaCha12 is one of the
      three ciphers specified by the original ChaCha paper
      (https://cr.yp.to/chacha/chacha-20080128.pdf: "ChaCha, a variant of
      Salsa20"), alongside ChaCha8 and ChaCha20.  ChaCha12 is faster than
      ChaCha20 but has a lower, but still large, security margin.
      We need XChaCha12 support so that it can be used in the Adiantum
      encryption mode, which enables disk/file encryption on low-end mobile
      devices where AES-XTS is too slow as the CPUs lack AES instructions.
      We'd prefer XChaCha20 (the more popular variant), but it's too slow on
      some of our target devices, so at least in some cases we do need the
      XChaCha12-based version.  In more detail, the problem is that Adiantum
      is still much slower than we're happy with, and encryption still has a
      quite noticeable effect on the feel of low-end devices.  Users and
      vendors push back hard against encryption that degrades the user
      experience, which always risks encryption being disabled entirely.  So
      we need to choose the fastest option that gives us a solid margin of
      security, and here that's XChaCha12.  The best known attack on ChaCha
      breaks only 7 rounds and has 2^235 time complexity, so ChaCha12's
      security margin is still better than AES-256's.  Much has been learned
      about cryptanalysis of ARX ciphers since Salsa20 was originally designed
      in 2005, and it now seems we can be comfortable with a smaller number of
      rounds.  The eSTREAM project also suggests the 12-round version of
      Salsa20 as providing the best balance among the different variants:
      combining very good performance with a "comfortable margin of security".
      Note that it would be trivial to add vanilla ChaCha12 in addition to
      XChaCha12.  However, it's unneeded for now and therefore is omitted.
      As discussed in the patch that introduced XChaCha20 support, I
      considered splitting the code into separate chacha-common, chacha20,
      xchacha20, and xchacha12 modules, so that these algorithms could be
      enabled/disabled independently.  However, since nearly all the code is
      shared anyway, I ultimately decided there would have been little benefit
      to the added complexity.
      Reviewed-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Acked-by: default avatarMartin Willi <martin@strongswan.org>
      Signed-off-by: default avatarEric Biggers <ebiggers@google.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
    • Eric Biggers's avatar
      crypto: chacha20-generic - refactor to allow varying number of rounds · 1ca1b917
      Eric Biggers authored
      In preparation for adding XChaCha12 support, rename/refactor
      chacha20-generic to support different numbers of rounds.  The
      justification for needing XChaCha12 support is explained in more detail
      in the patch "crypto: chacha - add XChaCha12 support".
      The only difference between ChaCha{8,12,20} are the number of rounds
      itself; all other parts of the algorithm are the same.  Therefore,
      remove the "20" from all definitions, structures, functions, files, etc.
      that will be shared by all ChaCha versions.
      Also make ->setkey() store the round count in the chacha_ctx (previously
      chacha20_ctx).  The generic code then passes the round count through to
      chacha_block().  There will be a ->setkey() function for each explicitly
      allowed round count; the encrypt/decrypt functions will be the same.  I
      decided not to do it the opposite way (same ->setkey() function for all
      round counts, with different encrypt/decrypt functions) because that
      would have required more boilerplate code in architecture-specific
      implementations of ChaCha and XChaCha.
      Reviewed-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Acked-by: default avatarMartin Willi <martin@strongswan.org>
      Signed-off-by: default avatarEric Biggers <ebiggers@google.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>