← Back to team overview

group.of.nepali.translators team mailing list archive

[Bug 1630970] Re: crypto/vmx/p8_ghash memory corruption

 

This bug was fixed in the package linux - 4.8.0-30.32

---------------
linux (4.8.0-30.32) yakkety; urgency=low

  * CVE-2016-8655 (LP: #1646318)
    - packet: fix race condition in packet_set_ring

 -- Brad Figg <brad.figg@xxxxxxxxxxxxx>  Thu, 01 Dec 2016 08:02:53 -0800

** Changed in: linux (Ubuntu)
       Status: Fix Committed => Fix Released

** CVE added: http://www.cve.mitre.org/cgi-
bin/cvename.cgi?name=2016-8655

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1630970

Title:
  crypto/vmx/p8_ghash memory corruption

Status in linux package in Ubuntu:
  Fix Released
Status in linux source package in Xenial:
  Fix Released
Status in linux source package in Yakkety:
  Fix Released

Bug description:
  That bug was reported on the linux-crypto mailing list by Jan Stancek.
  The bug is not easily reproduced on Xenial because the crypto API test
  manager is not enabled and the hash test that exorcises this bug is
  not present on the Xenial kernel.

  ---
  Hi,

  I'm chasing a memory corruption with 4.8-rc7 as I'm observing random Oopses
  on ppc BE/LE systems (lpars, KVM guests). About 30% of issues is that
  module list gets corrupted, and "cat /proc/modules" or "lsmod" triggers
  an Oops, for example:

  [   88.486041] Unable to handle kernel paging request for data at address 0x00000020
  ...
  [   88.487658] NIP [c00000000020f820] m_show+0xa0/0x240
  [   88.487689] LR [c00000000020f834] m_show+0xb4/0x240
  [   88.487719] Call Trace:
  [   88.487736] [c0000004b605bbb0] [c00000000020f834] m_show+0xb4/0x240 (unreliable)
  [   88.487796] [c0000004b605bc50] [c00000000045e73c] seq_read+0x36c/0x520
  [   88.487843] [c0000004b605bcf0] [c0000000004e1014] proc_reg_read+0x84/0x120
  [   88.487889] [c0000004b605bd30] [c00000000040df88] vfs_read+0xf8/0x380
  [   88.487934] [c0000004b605bde0] [c00000000040fd40] SyS_read+0x60/0x110
  [   88.487981] [c0000004b605be30] [c000000000009590] system_call+0x38/0xec

  0x20 offset is module_use->source, module_use is NULL because module.source_list
  gets corrupted.

  The source of corruption appears to originate from a 'ahash' test for
  p8_ghash:

  cryptomgr_test
   alg_test
    alg_test_hash
     test_hash
      __test_hash
       ahash_partial_update
        shash_async_export
         memcpy

  With some extra traces [1], I'm seeing that ahash_partial_update() allocates 56 bytes
  for 'state', and then crypto_ahash_export() writes 76 bytes into it:

  [    5.970887] __test_hash alg name p8_ghash, result: c000000004333ac0, key: c0000004b860a500, req: c0000004b860a380
  [    5.970963] state: c000000004333f00, statesize: 56
  [    5.970995] shash_default_export memcpy c000000004333f00 c0000004b860a3e0, len: 76

  This seems to directly correspond with:
    p8_ghash_alg.descsize = sizeof(struct p8_ghash_desc_ctx) == 56
    shash_tfm->descsize = sizeof(struct p8_ghash_desc_ctx) + crypto_shash_descsize(fallback) == 56 + 20
  where 20 is presumably coming from "ghash_alg.descsize".

  My gut feeling was that these 2 should match, but I'd love to hear
  what crypto people think.

  Thank you,
  Jan
  ---

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1630970/+subscriptions