# CVE-2025-37760: mm/vma: add give_up_on_oom option on modify/merge, use in uffd release > A flaw in the Linux kernel's memory management allows an attacker to trigger a null pointer dereference via userfaultfd, causing a system crash. - **Severity:** Medium 5.5 (`CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H`) - **Exploited in the wild:** Not known - **Login needed:** Any signed-in user - **Attackable:** Local or same network only - **Victim action needed:** Not needed - **Fix available:** Yes - **Published:** 1 May 2025 - **Updated:** 23 May 2026 - **Also known as:** BELL-CVE-2025-37760, DEBIAN-CVE-2025-37760, GHSA-p4vj-hhfc-5j8x, UBUNTU-CVE-2025-37760 ## What is CVE-2025-37760? CVE-2025-37760 is a medium-severity vulnerability in Linux kernel, published on 1 May 2025. It can only be exploited from the same machine or local network, with no action from the victim. ### Official description In the Linux kernel, the following vulnerability has been resolved: mm/vma: add give_up_on_oom option on modify/merge, use in uffd release Currently, if a VMA merge fails due to an OOM condition arising on commit merge or a failure to duplicate anon_vma's, we report this so the caller can handle it. However there are cases where the caller is only ostensibly trying a merge, and doesn't mind if it fails due to this condition. Since we do not want to introduce an implicit assumption that we only actually modify VMAs after OOM conditions might arise, add a 'give up on oom' option and make an explicit contract that, should this flag be set, we absolutely will not modify any VMAs should OOM arise and just bail out. Since it'd be very unusual for a user to try to vma_modify() with this flag set but be specifying a range within a VMA which ends up being split (which can fail due to rlimit issues, not only OOM), we add a debug warning for this condition. The motivating reason for this is uffd release - syzkaller (and Pedro Falcato's VERY astute analysis) found a way in which an injected fault on allocation, triggering an OOM condition on commit merge, would result in uffd code becoming confused and treating an error value as if it were a VMA pointer. To avoid this, we make use of this new VMG flag to ensure that this never occurs, utilising the fact that, should we be clearing entire VMAs, we do not wish an OOM event to be reported to us. Many thanks to Pedro Falcato for his excellent analysis and Jann Horn for his insightful and intelligent analysis of the situation, both of whom were instrumental in this fix. ## Which versions are affected by CVE-2025-37760? It affects 1 product. Products: Linux kernel. ## How do I fix CVE-2025-37760? Apply the vendor's patch. ## Is CVE-2025-37760 being exploited? There is no known exploitation of CVE-2025-37760 in the wild and no public exploit code. ## Other vulnerabilities in Linux kernel - [CVE-2026-53266](https://insights.sbomify.com/CVE-2026-53266/): Linux Kernel Out-of-Bounds Write (high 8.8, exploited in the wild) - [CVE-2013-6282](https://insights.sbomify.com/CVE-2013-6282/): Linux Kernel Improper Input Validation (high 8.8, exploited in the wild) - [CVE-2022-0185](https://insights.sbomify.com/CVE-2022-0185/): Linux Kernel Heap-Based Buffer Overflow (high 8.4, exploited in the wild) - [CVE-2013-2094](https://insights.sbomify.com/CVE-2013-2094/): Linux Kernel Privilege Escalation (high 8.4, exploited in the wild) - [CVE-2026-53362](https://insights.sbomify.com/CVE-2026-53362/): Linux Kernel Unspecified (high 7.8, exploited in the wild) ## Fix prompt for AI coding agents ```text Check this codebase for CVE-2025-37760 and fix it if it is affected. What it is: CVE-2025-37760 is a medium-severity vulnerability in Linux kernel, published on 1 May 2025. It can only be exploited from the same machine or local network, with no action from the victim. Exploitation: There is no known exploitation of CVE-2025-37760 in the wild and no public exploit code. Affected product: Linux kernel. No package-level version data is available, so check the vendor advisory linked from the reference page. Task: 1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies. 2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it. 3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead. 4. Run the tests and summarise what changed and why. 5. If nothing in the project is affected, say so and change nothing. Reference: https://insights.sbomify.com/CVE-2025-37760/ (Markdown: https://insights.sbomify.com/CVE-2025-37760/index.md) ``` ## Sources - CVE record: https://www.cve.org/CVERecord?id=CVE-2025-37760 - NVD: https://nvd.nist.gov/vuln/detail/CVE-2025-37760 - OSV: https://osv.dev/vulnerability/CVE-2025-37760 --- From sbomify Insights: https://insights.sbomify.com/CVE-2025-37760/ Summaries are generated and may contain mistakes; the official description above is the record.