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: Mon, 21 Dec 2015 19:57:37 -0500 From: Sasha Levin <sasha.levin@...cle.com> To: Andrew Morton <akpm@...ux-foundation.org> Cc: "Kirill A. Shutemov" <kirill@...temov.name>, mhocko@...e.com, mgorman@...e.de, linux-mm@...ck.org, linux-kernel@...r.kernel.org Subject: Re: [PATCH] mm, oom: initiallize all new zap_details fields before use On 12/21/2015 05:24 PM, Andrew Morton wrote: >>> Should we use c99 initializer instead to make it future-proof? >> > >> > I didn't do that to make these sort of failures obvious. In this case, if we would have >> > used an initializer and it would default to the "wrong" values it would be much harder >> > to find this bug. >> > > If we're to make that approach useful and debuggable we should poison > the structure at the outset with some well-known and crazy pattern. Or > use kasan. We sort of do. Consider stack garbage as "poison"... This bug was found using UBSan which complained that a bool suddenly had the value of '64'. If we go back to the scenario I've described, and the struct would have been initialized on declaration, you'd have a much harder time finding it rather than letting our existing and future tools find it. Thanks, Sasha -- 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