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

2016-12-07 Thread Launchpad Bug Tracker 
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   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 Kernel
Packages, which is subscribed to linux in Ubuntu.
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 
0x0020
  ...
  [   88.487658] NIP [c020f820] m_show+0xa0/0x240
  [   88.487689] LR [c020f834] m_show+0xb4/0x240
  [   88.487719] Call Trace:
  [   88.487736] [c004b605bbb0] [c020f834] m_show+0xb4/0x240 
(unreliable)
  [   88.487796] [c004b605bc50] [c045e73c] seq_read+0x36c/0x520
  [   88.487843] [c004b605bcf0] [c04e1014] proc_reg_read+0x84/0x120
  [   88.487889] [c004b605bd30] [c040df88] vfs_read+0xf8/0x380
  [   88.487934] [c004b605bde0] [c040fd40] SyS_read+0x60/0x110
  [   88.487981] [c004b605be30] [c0009590] 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: c4333ac0, key: 
c004b860a500, req: c004b860a380
  [5.970963] state: c4333f00, statesize: 56
  [5.970995] shash_default_export memcpy c4333f00 c004b860a3e0, 
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

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

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

2016-11-09 Thread Launchpad Bug Tracker 
This bug was fixed in the package linux - 4.4.0-47.68

---
linux (4.4.0-47.68) xenial; urgency=low

  [ Kamal Mostafa ]

  * Release Tracking Bug
- LP: #1636941

  * Add a driver for Amazon Elastic Network Adapters (ENA) (LP: #1635721)
- lib/bitmap.c: conversion routines to/from u32 array
- net: ethtool: add new ETHTOOL_xLINKSETTINGS API
- net: ena: Add a driver for Amazon Elastic Network Adapters (ENA)
- [config] enable CONFIG_ENA_ETHERNET=m (Amazon ENA driver)

  * unexpectedly large memory usage of mounted snaps (LP: #1636847)
- [Config] switch squashfs to single threaded decode

 -- Kamal Mostafa   Wed, 26 Oct 2016 10:47:55 -0700

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

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

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1630970

Title:
  crypto/vmx/p8_ghash memory corruption

Status in linux package in Ubuntu:
  Fix Committed
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 
0x0020
  ...
  [   88.487658] NIP [c020f820] m_show+0xa0/0x240
  [   88.487689] LR [c020f834] m_show+0xb4/0x240
  [   88.487719] Call Trace:
  [   88.487736] [c004b605bbb0] [c020f834] m_show+0xb4/0x240 
(unreliable)
  [   88.487796] [c004b605bc50] [c045e73c] seq_read+0x36c/0x520
  [   88.487843] [c004b605bcf0] [c04e1014] proc_reg_read+0x84/0x120
  [   88.487889] [c004b605bd30] [c040df88] vfs_read+0xf8/0x380
  [   88.487934] [c004b605bde0] [c040fd40] SyS_read+0x60/0x110
  [   88.487981] [c004b605be30] [c0009590] 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: c4333ac0, key: 
c004b860a500, req: c004b860a380
  [5.970963] state: c4333f00, statesize: 56
  [5.970995] shash_default_export memcpy c4333f00 c004b860a3e0, 
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

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

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

2016-11-09 Thread Launchpad Bug Tracker 
This bug was fixed in the package linux - 4.8.0-27.29

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

  [ Seth Forshee ]

  * Release Tracking Bug
- LP: #1635377

  * proc_keys_show crash when reading /proc/keys (LP: #1634496)
- SAUCE: KEYS: ensure xbuf is large enough to fix buffer overflow in
  proc_keys_show (LP: #1634496)

  * Revert "If zone is so small that watermarks are the same, stop zone balance"
in yakkety (LP: #1632894)
- Revert "UBUNTU: SAUCE: (no-up) If zone is so small that watermarks are the
  same, stop zone balance."

  * lts-yakkety 4.8 cannot mount lvm raid1 (LP: #1631298)
- SAUCE: (no-up) dm raid: fix compat_features validation

  * kswapd0 100% CPU usage (LP: #1518457)
- SAUCE: (no-up) If zone is so small that watermarks are the same, stop zone
  balance.

  * [Trusty->Yakkety] powerpc/64: Fix incorrect return value from
__copy_tofrom_user (LP: #1632462)
- SAUCE: (no-up) powerpc/64: Fix incorrect return value from
  __copy_tofrom_user

  * Ubuntu 16.10: Oops panic in move_page_tables/page_remove_rmap after running
memory_stress_ng. (LP: #1628976)
- SAUCE: (no-up) powerpc/pseries: Fix stack corruption in htpe code

  * Paths not failed properly when unmapping virtual FC ports in VIOS (using
ibmvfc) (LP: #1632116)
- scsi: ibmvfc: Fix I/O hang when port is not mapped

  * [Ubuntu16.10]KV4.8: kernel livepatch config options are not set
(LP: #1626983)
- [Config] Enable live patching on powerpc/ppc64el

  * CONFIG_AUFS_XATTR is not set (LP: #1557776)
- [Config] CONFIG_AUFS_XATTR=y

  * Yakkety update to 4.8.1 stable release (LP: #1632445)
- arm64: debug: avoid resetting stepping state machine when TIF_SINGLESTEP
- Using BUG_ON() as an assert() is _never_ acceptable
- usb: misc: legousbtower: Fix NULL pointer deference
- Staging: fbtft: Fix bug in fbtft-core
- usb: usbip: vudc: fix left shift overflow
- USB: serial: cp210x: Add ID for a Juniper console
- Revert "usbtmc: convert to devm_kzalloc"
- ALSA: hda - Adding one more ALC255 pin definition for headset problem
- ALSA: hda - Fix headset mic detection problem for several Dell laptops
- ALSA: hda - Add the top speaker pin config for HP Spectre x360
- Linux 4.8.1

  * PSL data cache should be flushed before resetting CAPI adapter
(LP: #1632049)
- cxl: Flush PSL cache before resetting the adapter

  * thunder nic: avoid link delays due to RX_PACKET_DIS (LP: #1630038)
- net: thunderx: Don't set RX_PACKET_DIS while initializing

  * crypto/vmx/p8_ghash memory corruption (LP: #1630970)
- crypto: ghash-generic - move common definitions to a new header file
- crypto: vmx - Fix memory corruption caused by p8_ghash
- crypto: vmx - Ensure ghash-generic is enabled

  * arm64: SPCR console not autodetected (LP: #1630311)
- of/serial: move earlycon early_param handling to serial
- [Config] CONFIG_ACPI_SPCR_TABLE=y
- ACPI: parse SPCR and enable matching console
- ARM64: ACPI: enable ACPI_SPCR_TABLE
- serial: pl011: add console matching function

  * include/linux/security.h header syntax error with !CONFIG_SECURITYFS
(LP: #1630990)
- SAUCE: (no-up) include/linux/security.h -- fix syntax error with
  CONFIG_SECURITYFS=n

  * sha1-powerpc returning wrong results (LP: #1629977)
- crypto: sha1-powerpc - little-endian support

 -- Seth Forshee   Thu, 20 Oct 2016 14:09:37
-0500

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1630970

Title:
  crypto/vmx/p8_ghash memory corruption

Status in linux package in Ubuntu:
  Fix Committed
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 
0x0020
  ...
  [   88.487658] NIP [c020f820] m_show+0xa0/0x240
  [   88.487689] LR [c020f834] m_show+0xb4/0x240
  [   88.487719] Call Trace:
  [   88.487736] [c004b605bbb0] [c020f834] m_show+0xb4/0x240 
(unreliable)
  [   88.487796] [c004b605bc50] [c045e73c] seq_read+0x36c/0x520
  [   88.487843] [c004b605bcf0] [c04e1014] proc_reg_read+0x84/0x120
  [   88.487889] [c004b605bd30] [c040df88] vfs_read+0xf8/0x380
  [   88.487934]

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

2016-11-07 Thread Marcelo Cerri 
** Tags removed: verification-needed-xenial verification-needed-yakkety
** Tags added: verification-done-xenial verification-done-yakkety

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1630970

Title:
  crypto/vmx/p8_ghash memory corruption

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

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 
0x0020
  ...
  [   88.487658] NIP [c020f820] m_show+0xa0/0x240
  [   88.487689] LR [c020f834] m_show+0xb4/0x240
  [   88.487719] Call Trace:
  [   88.487736] [c004b605bbb0] [c020f834] m_show+0xb4/0x240 
(unreliable)
  [   88.487796] [c004b605bc50] [c045e73c] seq_read+0x36c/0x520
  [   88.487843] [c004b605bcf0] [c04e1014] proc_reg_read+0x84/0x120
  [   88.487889] [c004b605bd30] [c040df88] vfs_read+0xf8/0x380
  [   88.487934] [c004b605bde0] [c040fd40] SyS_read+0x60/0x110
  [   88.487981] [c004b605be30] [c0009590] 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: c4333ac0, key: 
c004b860a500, req: c004b860a380
  [5.970963] state: c4333f00, statesize: 56
  [5.970995] shash_default_export memcpy c4333f00 c004b860a3e0, 
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

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

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

2016-10-18 Thread Seth Forshee 
This bug is awaiting verification that the kernel in -proposed solves
the problem. Please test the kernel and update this bug with the
results. If the problem is solved, change the tag 'verification-needed-
yakkety' to 'verification-done-yakkety'.

If verification is not done by 5 working days from today, this fix will
be dropped from the source code, and this bug will be closed.

See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how
to enable and use -proposed. Thank you!

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1630970

Title:
  crypto/vmx/p8_ghash memory corruption

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

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 
0x0020
  ...
  [   88.487658] NIP [c020f820] m_show+0xa0/0x240
  [   88.487689] LR [c020f834] m_show+0xb4/0x240
  [   88.487719] Call Trace:
  [   88.487736] [c004b605bbb0] [c020f834] m_show+0xb4/0x240 
(unreliable)
  [   88.487796] [c004b605bc50] [c045e73c] seq_read+0x36c/0x520
  [   88.487843] [c004b605bcf0] [c04e1014] proc_reg_read+0x84/0x120
  [   88.487889] [c004b605bd30] [c040df88] vfs_read+0xf8/0x380
  [   88.487934] [c004b605bde0] [c040fd40] SyS_read+0x60/0x110
  [   88.487981] [c004b605be30] [c0009590] 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: c4333ac0, key: 
c004b860a500, req: c004b860a380
  [5.970963] state: c4333f00, statesize: 56
  [5.970995] shash_default_export memcpy c4333f00 c004b860a3e0, 
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

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

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

2016-10-18 Thread Seth Forshee 
This bug is awaiting verification that the kernel in -proposed solves
the problem. Please test the kernel and update this bug with the
results. If the problem is solved, change the tag 'verification-needed-
xenial' to 'verification-done-xenial'.

If verification is not done by 5 working days from today, this fix will
be dropped from the source code, and this bug will be closed.

See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how
to enable and use -proposed. Thank you!


** Tags added: verification-needed-xenial

** Tags added: verification-needed-yakkety

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1630970

Title:
  crypto/vmx/p8_ghash memory corruption

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

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 
0x0020
  ...
  [   88.487658] NIP [c020f820] m_show+0xa0/0x240
  [   88.487689] LR [c020f834] m_show+0xb4/0x240
  [   88.487719] Call Trace:
  [   88.487736] [c004b605bbb0] [c020f834] m_show+0xb4/0x240 
(unreliable)
  [   88.487796] [c004b605bc50] [c045e73c] seq_read+0x36c/0x520
  [   88.487843] [c004b605bcf0] [c04e1014] proc_reg_read+0x84/0x120
  [   88.487889] [c004b605bd30] [c040df88] vfs_read+0xf8/0x380
  [   88.487934] [c004b605bde0] [c040fd40] SyS_read+0x60/0x110
  [   88.487981] [c004b605be30] [c0009590] 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: c4333ac0, key: 
c004b860a500, req: c004b860a380
  [5.970963] state: c4333f00, statesize: 56
  [5.970995] shash_default_export memcpy c4333f00 c004b860a3e0, 
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

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

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

2016-10-07 Thread Tim Gardner 
** Changed in: linux (Ubuntu Xenial)
   Status: Confirmed => Fix Committed

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1630970

Title:
  crypto/vmx/p8_ghash memory corruption

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

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 
0x0020
  ...
  [   88.487658] NIP [c020f820] m_show+0xa0/0x240
  [   88.487689] LR [c020f834] m_show+0xb4/0x240
  [   88.487719] Call Trace:
  [   88.487736] [c004b605bbb0] [c020f834] m_show+0xb4/0x240 
(unreliable)
  [   88.487796] [c004b605bc50] [c045e73c] seq_read+0x36c/0x520
  [   88.487843] [c004b605bcf0] [c04e1014] proc_reg_read+0x84/0x120
  [   88.487889] [c004b605bd30] [c040df88] vfs_read+0xf8/0x380
  [   88.487934] [c004b605bde0] [c040fd40] SyS_read+0x60/0x110
  [   88.487981] [c004b605be30] [c0009590] 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: c4333ac0, key: 
c004b860a500, req: c004b860a380
  [5.970963] state: c4333f00, statesize: 56
  [5.970995] shash_default_export memcpy c4333f00 c004b860a3e0, 
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

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

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

2016-10-07 Thread Tim Gardner 
** Changed in: linux (Ubuntu Yakkety)
   Status: Confirmed => Fix Committed

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1630970

Title:
  crypto/vmx/p8_ghash memory corruption

Status in linux package in Ubuntu:
  Fix Committed
Status in linux source package in Xenial:
  Confirmed
Status in linux source package in Yakkety:
  Fix Committed

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 
0x0020
  ...
  [   88.487658] NIP [c020f820] m_show+0xa0/0x240
  [   88.487689] LR [c020f834] m_show+0xb4/0x240
  [   88.487719] Call Trace:
  [   88.487736] [c004b605bbb0] [c020f834] m_show+0xb4/0x240 
(unreliable)
  [   88.487796] [c004b605bc50] [c045e73c] seq_read+0x36c/0x520
  [   88.487843] [c004b605bcf0] [c04e1014] proc_reg_read+0x84/0x120
  [   88.487889] [c004b605bd30] [c040df88] vfs_read+0xf8/0x380
  [   88.487934] [c004b605bde0] [c040fd40] SyS_read+0x60/0x110
  [   88.487981] [c004b605be30] [c0009590] 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: c4333ac0, key: 
c004b860a500, req: c004b860a380
  [5.970963] state: c4333f00, statesize: 56
  [5.970995] shash_default_export memcpy c4333f00 c004b860a3e0, 
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

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

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

2016-10-06 Thread Marcelo Cerri 
** Changed in: linux (Ubuntu Xenial)
 Assignee: (unassigned) => Marcelo Cerri (mhcerri)

** Changed in: linux (Ubuntu Xenial)
   Status: New => Confirmed

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1630970

Title:
  crypto/vmx/p8_ghash memory corruption

Status in linux package in Ubuntu:
  Confirmed
Status in linux source package in Xenial:
  Confirmed
Status in linux source package in Yakkety:
  Confirmed

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 
0x0020
  ...
  [   88.487658] NIP [c020f820] m_show+0xa0/0x240
  [   88.487689] LR [c020f834] m_show+0xb4/0x240
  [   88.487719] Call Trace:
  [   88.487736] [c004b605bbb0] [c020f834] m_show+0xb4/0x240 
(unreliable)
  [   88.487796] [c004b605bc50] [c045e73c] seq_read+0x36c/0x520
  [   88.487843] [c004b605bcf0] [c04e1014] proc_reg_read+0x84/0x120
  [   88.487889] [c004b605bd30] [c040df88] vfs_read+0xf8/0x380
  [   88.487934] [c004b605bde0] [c040fd40] SyS_read+0x60/0x110
  [   88.487981] [c004b605be30] [c0009590] 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: c4333ac0, key: 
c004b860a500, req: c004b860a380
  [5.970963] state: c4333f00, statesize: 56
  [5.970995] shash_default_export memcpy c4333f00 c004b860a3e0, 
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

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

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

2016-10-06 Thread Andy Whitcroft 
** Also affects: linux (Ubuntu Yakkety)
   Importance: Undecided
 Assignee: Marcelo Cerri (mhcerri)
   Status: Confirmed

** Also affects: linux (Ubuntu Xenial)
   Importance: Undecided
   Status: New

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1630970

Title:
  crypto/vmx/p8_ghash memory corruption

Status in linux package in Ubuntu:
  Confirmed
Status in linux source package in Xenial:
  New
Status in linux source package in Yakkety:
  Confirmed

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 
0x0020
  ...
  [   88.487658] NIP [c020f820] m_show+0xa0/0x240
  [   88.487689] LR [c020f834] m_show+0xb4/0x240
  [   88.487719] Call Trace:
  [   88.487736] [c004b605bbb0] [c020f834] m_show+0xb4/0x240 
(unreliable)
  [   88.487796] [c004b605bc50] [c045e73c] seq_read+0x36c/0x520
  [   88.487843] [c004b605bcf0] [c04e1014] proc_reg_read+0x84/0x120
  [   88.487889] [c004b605bd30] [c040df88] vfs_read+0xf8/0x380
  [   88.487934] [c004b605bde0] [c040fd40] SyS_read+0x60/0x110
  [   88.487981] [c004b605be30] [c0009590] 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: c4333ac0, key: 
c004b860a500, req: c004b860a380
  [5.970963] state: c4333f00, statesize: 56
  [5.970995] shash_default_export memcpy c4333f00 c004b860a3e0, 
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

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp