** 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 नेपाली भाषा समायोजकहरुको समूह, 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: 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 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 _______________________________________________ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp