| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Date: Sun, 22 Mar 2015 22:19:06 -0400 (EDT) From: David Miller <davem@...emloft.net> To: david.ahern@...cle.com Cc: torvalds@...ux-foundation.org, sparclinux@...r.kernel.org, linux-mm@...ck.org, linux-kernel@...r.kernel.org, bpicco@...oft.net Subject: Re: 4.0.0-rc4: panic in free_block Nevermind I think I figured out the problem. It's the cache initializing stores, we can't do overlapping copies where dst <= src in all cases because of them. A store to a address modulo the cache line size (which for these instructions is 64 bytes), clears that whole line. But when we're doing these memmove() calls in SLAB/SLUB, we can clear some bytes at the end of the line before they've been read in. And reading over NG4memcpy, this _can_ happen, the main unrolled loop begins like this: load src + 0x00 load src + 0x08 load src + 0x10 load src + 0x18 load src + 0x20 store dst + 0x00 Assume dst is 64 byte aligned and let's say that dst is src - 8 for this memcpy() call, right? That store at the end there is the one to the first line in the cache line, thus clearing the whole line, which thus clobbers "src + 0x28" before it even gets loaded. I'm pretty sure this is what's happening. And it's only going to trigger if the memcpy() is 128 bytes or larger. I'll work on a fix. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists