Skip to main content

Linux Kernel EUVDEUVD-2026-48961

| CVE-2026-64417 MEDIUM
NULL Pointer Dereference (CWE-476)
2026-07-25 Linux GHSA-fmww-fwc4-2q32
Denial Of Service Linux Null Pointer Dereference Red Hat Suse
5.5
CVSS 3.1 · NVD
Share

Severity by source

NVD PRIMARY
5.5 MEDIUM
AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
vuln.today AI
5.5 MEDIUM

Local access with low privileges required to write debugfs; pure kernel-crash availability impact, no confidentiality or integrity effect.

3.1 AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
4.0 AV:L/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
SUSE
MEDIUM
qualitative
Red Hat
5.5 LOW
qualitative

Primary rating from NVD.

CVSS VectorNVD

Attack Vector
Local
Attack Complexity
Low
Privileges Required
Low
User Interaction
None
Scope
Unchanged
Confidentiality
None
Integrity
None
Availability
High

Lifecycle Timeline

5
Analysis Generated
Sep 04, 2026 - 16:07 vuln.today
CVSS changed
Sep 04, 2026 - 15:37 NVD
5.5 (MEDIUM)
Patch available
Jul 25, 2026 - 11:18 EUVD
CVE Published
Jul 25, 2026 - 08:50 nvd
MEDIUM 5.5
CVE Published
Jul 25, 2026 - 08:50 cve.org
UNKNOWN (no severity yet)

DescriptionNVD

In the Linux kernel, the following vulnerability has been resolved:

mm: shrinker: fix NULL pointer dereference in debugfs

shrinker_debugfs_add() creates both "count" and "scan" debugfs files unconditionally.

That assumes every shrinker implements both count_objects() and scan_objects(), which is not guaranteed. For example, the xen-backend shrinker sets count_objects() but leaves scan_objects() NULL, so writing to its scan file calls through a NULL function pointer and panics the kernel:

BUG: kernel NULL pointer dereference, address: 0000000000000000 RIP: 0010:0x0 Code: Unable to access opcode bytes at 0xffffffffffffffd6. Call Trace: <TASK> shrinker_debugfs_scan_write+0x12e/0x270 full_proxy_write+0x5f/0x90 vfs_write+0xde/0x420 ? filp_flush+0x75/0x90 ? filp_close+0x1d/0x30 ? do_dup2+0xb8/0x120 ksys_write+0x68/0xf0 ? filp_flush+0x75/0x90 do_syscall_64+0xb3/0x5b0 entry_SYSCALL_64_after_hwframe+0x76/0x7e

The count path has the same issue in principle if a shrinker omits count_objects().

To fix it, only create "count" and "scan" debugfs files when the corresponding callbacks are present.

AnalysisAI

Kernel panic via NULL pointer dereference in the Linux kernel's memory shrinker debugfs interface allows a local attacker to crash the system. The shrinker_debugfs_add() function unconditionally creates 'count' and 'scan' debugfs files for all registered shrinkers, but some shrinkers - notably the xen-backend shrinker - only implement one of the two required callbacks (count_objects or scan_objects). Writing to the exposed 'scan' debugfs file on such a shrinker dispatches through a NULL function pointer, triggering a kernel panic. No public exploit has been identified at time of analysis, and EPSS score of 0.21% reflects low exploitation probability. Patches are available across multiple stable kernel branches.

Technical ContextAI

The Linux kernel memory management subsystem provides a shrinker framework that allows subsystems to register custom memory reclaim callbacks (count_objects and scan_objects). Since kernel commit bbf535fd6f06, shrinker_debugfs_add() creates debugfs entries for both operations unconditionally, assuming all registered shrinkers implement both callbacks - an assumption that is not enforced by the API contract. CWE-476 (NULL Pointer Dereference) applies directly: when a user writes to the debugfs scan file of a shrinker that registered only count_objects, the kernel dispatches through a NULL scan_objects pointer at address 0x0, resulting in a BUG trap at RIP 0x0. The xen-backend shrinker is the confirmed triggering case, meaning this is practically exploitable only on Xen virtualization hosts or guests with appropriate debugfs access. The fix conditionally creates each debugfs file only when the corresponding callback is non-NULL.

RemediationAI

Vendor-released patch: Linux 6.1.178, 6.6.145, 6.12.96, 6.18.39, 7.1.4, or 7.2-rc3. Update to the appropriate patched stable kernel for your distribution. As a compensating control where patching is delayed, restrict mount-time debugfs access by mounting debugfs with restrictive permissions (mount -o uid=0,gid=0,mode=700) or disabling user access via kernel.dmesg_restrict and AppArmor/SELinux policy that prevents unprivileged access to /sys/kernel/debug/. On non-Xen deployments, ensure the xen-backend module is not loaded (lsmod | grep xen_backend) to eliminate the primary vulnerable code path. Note that disabling debugfs access may impact kernel developer tooling and performance monitoring utilities that rely on it.

Same weakness CWE-476 – NULL Pointer Dereference

View all
CVE-2016-0742 HIGH
7.5
CVE-2014-3470 MEDIUM
4.3
CVE-2017-3730 HIGH POC
7.5
CVE-2017-3169 CRITICAL POC
9.8
CVE-2016-4957 HIGH
7.5
CVE-2015-3194 HIGH
7.5
CVE-2026-21525 MEDIUM
6.2
CVE-2017-0016 MEDIUM
5.9

Same technique Denial Of Service

View all
CVE-2015-5119 CRITICAL POC
9.8
CVE-2011-2462 CRITICAL POC
9.8
CVE-2011-0611 HIGH POC
8.8
CVE-2012-1889 HIGH POC
8.8
CVE-2012-0507 CRITICAL POC
9.8
CVE-2014-1761 HIGH POC
7.8
CVE-2015-5122 CRITICAL POC
9.8
CVE-2011-0609 HIGH POC
7.8

Vendor StatusVendor

SUSE

Severity: Moderate
Product Status
openSUSE Tumbleweed Fixed
SUSE Linux Enterprise Desktop 15 SP7 Affected
SUSE Linux Enterprise Desktop 15 SP7 Affected
SUSE Linux Enterprise High Availability Extension 15 SP7 Affected
SUSE Linux Enterprise High Availability Extension 15 SP7 Affected

Share

EUVD-2026-48961 vulnerability details – vuln.today
Back

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy