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: Fri, 6 Jan 2017 01:11:02 +0100 From: Richard Weinberger <richard@....at> To: Michal Hocko <mhocko@...nel.org> Cc: linux-kernel@...r.kernel.org, akpm@...ux-foundation.org, vbabka@...e.cz, kirill.shutemov@...ux.intel.com, jmarchan@...hat.com, gerald.schaefer@...ibm.com, hannes@...xchg.org, luto@...nel.org Subject: Re: [PATCH] proc: Fix integer overflow of VmLib Michal, Am 05.01.2017 um 14:49 schrieb Michal Hocko: > If you just read the documentation: > VmLib size of shared library code > > then 0 might suggest there are no shared libraries used and the code is > statically linked Which is IMHO not correct. So, the documentation needs a fix too. >> Unless I misread the code, VmLib will honour any PROT_EXEC mapping. >> So, a statically linked JIT will have VmLib > 0. > > yes the code behaves differently and that's why I've said that the > reported number is not correct no matter how. > > Anyway, as I've said I do not see any solution without risk of > regression while the current code is clearly wrong. If the general > consensus is that 0 is better than explicitly documenting VmLib as the > size of executable code and report it that way then I have no objections > and won't stay in the way. I am not sure which poison is worse. > Agreed. :-) Thanks, //richard
Powered by blists - more mailing lists