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, 11 Aug 2017 11:28:52 +0900 From: Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp> To: mhocko@...nel.org, akpm@...ux-foundation.org Cc: andrea@...nel.org, kirill@...temov.name, oleg@...hat.com, wenwei.tww@...baba-inc.com, linux-mm@...ck.org, linux-kernel@...r.kernel.org, mhocko@...e.com Subject: Re: [PATCH 2/2] mm, oom: fix potential data corruption when oom_reaper races with writer Michal Hocko wrote: > +/* > + * Checks whether a page fault on the given mm is still reliable. > + * This is no longer true if the oom reaper started to reap the > + * address space which is reflected by MMF_UNSTABLE flag set in > + * the mm. At that moment any !shared mapping would lose the content > + * and could cause a memory corruption (zero pages instead of the > + * original content). > + * > + * User should call this before establishing a page table entry for > + * a !shared mapping and under the proper page table lock. > + * > + * Return 0 when the PF is safe VM_FAULT_SIGBUS otherwise. > + */ > +static inline int check_stable_address_space(struct mm_struct *mm) > +{ > + if (unlikely(test_bit(MMF_UNSTABLE, &mm->flags))) > + return VM_FAULT_SIGBUS; > + return 0; > +} > + Will you explain the mechanism why random values are written instead of zeros so that this patch can actually fix the race problem? I consider that writing random values (though it seems like portion of process image) instead of zeros to a file might cause a security problem, and the patch that fixes it should be able to be backported to stable kernels.
Powered by blists - more mailing lists