CVE-2025-37760

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/vma: add give_up_on_oom option on modify/merge, use in uffd release<br /> <br /> Currently, if a VMA merge fails due to an OOM condition arising on commit<br /> merge or a failure to duplicate anon_vma&amp;#39;s, we report this so the caller<br /> can handle it.<br /> <br /> However there are cases where the caller is only ostensibly trying a<br /> merge, and doesn&amp;#39;t mind if it fails due to this condition.<br /> <br /> Since we do not want to introduce an implicit assumption that we only<br /> actually modify VMAs after OOM conditions might arise, add a &amp;#39;give up on<br /> oom&amp;#39; option and make an explicit contract that, should this flag be set, we<br /> absolutely will not modify any VMAs should OOM arise and just bail out.<br /> <br /> Since it&amp;#39;d be very unusual for a user to try to vma_modify() with this flag<br /> set but be specifying a range within a VMA which ends up being split (which<br /> can fail due to rlimit issues, not only OOM), we add a debug warning for<br /> this condition.<br /> <br /> The motivating reason for this is uffd release - syzkaller (and Pedro<br /> Falcato&amp;#39;s VERY astute analysis) found a way in which an injected fault on<br /> allocation, triggering an OOM condition on commit merge, would result in<br /> uffd code becoming confused and treating an error value as if it were a VMA<br /> pointer.<br /> <br /> To avoid this, we make use of this new VMG flag to ensure that this never<br /> occurs, utilising the fact that, should we be clearing entire VMAs, we do<br /> not wish an OOM event to be reported to us.<br /> <br /> Many thanks to Pedro Falcato for his excellent analysis and Jann Horn for<br /> his insightful and intelligent analysis of the situation, both of whom were<br /> instrumental in this fix.