Linux: NULL Pointer Dereference
CVE-2026-63950 is a high-severity NULL pointer dereference vulnerability in Linux, with a CVSS 3.1 base score of 7.8 out of 10. It can be exploited with local access to the system by an attacker with a low-privileged account, without any action from a user. The record lists versions 0fcc34d0d8fefca4fea349e45c10e3a3d90350eb, f611db9b771b2b6775357555d2517af044fca4f0, 3f8968e9cbf95d5d87d32218906cab0b9b9eddbe as the first without the flaw, so updating Linux to one of those releases or later removes the exposure. There is no confirmed exploitation so far. EPSS estimates a 0.17% chance of exploitation within 30 days, which is low compared with other CVEs.
High severity with no evidence of exploitation so far.
What to do
- Update Linux to 0fcc34d0d8fefca4fea349e45c10e3a3d90350eb or f611db9b771b2b6775357555d2517af044fca4f0 or 3f8968e9cbf95d5d87d32218906cab0b9b9eddbe, whichever matches your release line, or a later version.
- Update Linux Kernel to 6.18.35 or 7.0.12, whichever matches your release line, or a later version.
Affected products and versions
| Vendor | Product | Affected versions | Fixed in |
|---|---|---|---|
| Linux | Linux | 354dffd29575cdf13154e8fb787322354aa9efc4 up to, but not including, 0fcc34d0d8fefca4fea349e45c10e3a3d90350eb; 354dffd29575cdf13154e8fb787322354aa9efc4 up to, but not including, f611db9b771b2b6775357555d2517af044fca4f0; 354dffd29575cdf13154e8fb787322354aa9efc4 up to, but not including, 3f8968e9cbf95d5d87d32218906cab0b9b9eddbe; 6.15 | 0fcc34d0d8fefca4fea349e45c10e3a3d90350eb, f611db9b771b2b6775357555d2517af044fca4f0, 3f8968e9cbf95d5d87d32218906cab0b9b9eddbe |
| Linux | Linux Kernel | 6.15 up to, but not including, 6.18.35; 6.19 up to, but not including, 7.0.12; 7.1 | 6.18.35, 7.0.12 |
Version data comes from the organisation that assigned the CVE. Confirm against the vendor advisory before deciding you are unaffected.
How the severity score breaks down
- Attack vector
- LocalThe attacker needs local access or must trick a user into running something.
- Attack complexity
- LowNo special conditions are needed; the attack works reliably.
- Privileges required
- LowA basic user account is enough.
- User interaction
- NoneNo action by a victim is required.
- Scope
- UnchangedImpact stays within the vulnerable component.
- Confidentiality
- HighAll data handled by the component can be read.
- Integrity
- HighData or code can be modified at will.
- Availability
- HighThe component can be taken down completely.
Vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H. Scored by CNA.
Official description
In the Linux kernel, the following vulnerability has been resolved: mm/rmap: initialize nr_pages to 1 at loop start in try_to_unmap_one Initialize nr_pages to 1 at the start of each loop iteration, like folio_referenced_one() does. Without this, nr_pages computed by a previous folio_unmap_pte_batch() call can be reused on a later iteration that does not run folio_unmap_pte_batch() again. mmap a 64K large folio with MAP_ANONYMOUS | MAP_DROPPABLE, then call madvise(MADV_FREE), then make the last page device-exclusive via HMM_DMIRROR_EXCLUSIVE. Trigger node reclaim through sysfs. Now, in try_to_unmap_one(), we will first clear the first 15 out of 16 entries mapping the lazyfree folio. This will set nr_pages to 15. In the next pvmw walk, this nr_pages gets reused on a device-exclusive pte, thus potentially corrupting folio refcount/mapcount. At the moment, I have a userspace program which can make the kernel spit out a trace, but the blow up is in folio_referenced_one(), because there are existing bugs in the interaction between device-private and rmap (which too I am investigating). I did a one liner kernel change to avoid going into folio_referenced_one(), and the kernel blows up at folio_remove_rmap_ptes in try_to_unmap_one which is what I wanted. Note that the bug is there not since file folio batching but lazyfree folio batching, since device-exclusive only works for anonymous folios. Userspace visible effect is simply kernel crashing somewhere due to refcount/mapcount corruption.
Source: the CVE record as published by its numbering authority, via NVD and CVE.org.
The underlying weakness: NULL Pointer Dereference
The product dereferences a pointer that it expects to be valid but is NULL.
How developers prevent this class of flaw
- For any pointers that could have been modified or provided from a function that can return NULL, check the pointer for NULL before use. When working with a multithreaded or otherwise asynchronous environment, ensure that proper locking APIs are used to lock before the check, and unlock when it has finished.
- Select a programming language that is not susceptible to these issues.
- Check the results of all functions that return a value and verify that the value is non-null before acting upon it.
Timeline
- CVE record published.
- Record last changed materially (score, affected products, status or references).
References
Patches and release notes
Recent NULL Pointer Dereference vulnerabilities
- 7.5 High severity
- 7.5 High severity
- 7.8 High severity
- 7.5 High severity
- 7.5 High severity
- 8.4 High severity
Spotted an error? Tell us.