CVE-2026-63793

What it actually does

This is a local Linux kernel use-after-free in the NTFS filesystem driver involving concurrent access to the in-memory volume label. A privileged local user who can issue filesystem label ioctl operations against an NTFS volume can race a label update with a label read: one path frees or replaces the volume_label pointer while another path copies from it to user space. Successful exploitation can corrupt kernel memory or read freed memory, potentially leading to kernel crash, information disclosure, or local privilege escalation to kernel-level execution. The upstream fix serializes volume label access with a mutex and snapshots the label before copying it to user space.

Why it matters to the business

Systems that mount NTFS volumes are exposed to a local attacker or compromised low-privileged account escalating privileges or causing denial of service. This is most relevant to Linux desktops, file-transfer hosts, forensic workstations, removable-media workflows, dual-boot systems, and servers that mount NTFS-formatted storage. The vulnerability is not currently listed in CISA KEV, has no known public exploit maturity in the provided data, and has a low EPSS score, so internet-scale exploitation is unlikely; however, the CVSS impact is high because successful exploitation affects confidentiality, integrity, and availability at the kernel level.

How an attack unfolds

An attacker first obtains local code execution with enough privileges to interact with an NTFS-mounted filesystem and issue filesystem label ioctl calls. They then repeatedly trigger concurrent label-setting and label-reading operations against the same NTFS volume to win a race condition in the kernel driver. If the timing is successful, the read path uses memory that has already been freed or replaced by the write path. Depending on kernel build, allocator behavior, mitigations, and attacker control over memory layout, this may result in a kernel panic, disclosure of stale kernel memory, or a more advanced privilege-escalation primitive. There is no indication from the supplied intelligence that this vulnerability is currently exploited in the wild or used by named threat actors or ransomware campaigns.

How to fix it

Upgrade to a Linux kernel version from the relevant distribution or vendor that includes the NTFS fix which serializes volume label access and snapshots the label before copy_to_user. Because exact fixed package versions were not provided, use vendor security advisories for the deployed distribution and kernel branch to identify the corrected kernel package. Reboot into the patched kernel after installation; merely installing the package is not sufficient if the vulnerable kernel remains running. Where immediate patching is not possible, reduce exposure by preventing untrusted users from mounting or interacting with NTFS filesystems, disabling unnecessary NTFS support, restricting removable media workflows, and limiting local shell access on systems that process NTFS volumes.

How to confirm the fix worked

Confirm that each affected system is running a vendor kernel build that contains the NTFS volume label serialization fix, not just that the package is installed. Validate with uname -a, package manager metadata, and the distribution’s security advisory for this issue. Check whether NTFS support is present or loaded by reviewing kernel configuration, loaded modules, and mounted filesystems. Where feasible in a controlled test environment, verify that concurrent filesystem label get/set operations against an NTFS volume no longer trigger KASAN, kernel warnings, crashes, or use-after-free reports. Confirm that untrusted users cannot mount NTFS volumes or issue relevant filesystem label ioctl operations unless explicitly required.

Typical attack path

1. Gain local access to a Linux system that mounts or can mount an NTFS filesystem.
2. Identify an NTFS mount point where filesystem label ioctl operations are permitted.
3. Run code that repeatedly invokes concurrent filesystem label set and get operations against the same NTFS volume.
4. Attempt to win the race between replacing the NTFS volume label and reading the old label.
5. Leverage the resulting use-after-free for kernel memory disclosure, kernel crash, or potential privilege escalation.
6. If privilege escalation succeeds, execute follow-on actions with elevated local privileges.

How to detect it

Retrospective detection is difficult because successful exploitation may not leave a unique artifact unless kernel debugging, audit, EDR, or crash logging captured the activity. Review kernel logs, crash dumps, pstore, journald, syslog, auditd, and endpoint telemetry for NTFS-related kernel warnings, use-after-free reports, general protection faults, kernel panics, or suspicious processes repeatedly issuing filesystem label ioctl calls. Focus on the period since publication and on systems with NTFS mounts or removable-media activity. Useful log sources include /var/log/kern.log, /var/log/syslog, journalctl -k, audit logs for ioctl syscalls, EDR process telemetry, crash dump directories, pstore records, and kernel sanitizer output if enabled. Look for high-frequency or concurrent filesystem label operations involving FS_IOC_SETFSLABEL and FS_IOC_GETFSLABEL, especially from unexpected user processes. Absence of these artifacts does not prove non-exploitation because a successful local privilege escalation may be quiet and kernel memory corruption may not be logged.

• FS_IOC_SETFSLABEL
• FS_IOC_GETFSLABEL
• BUG: KASAN: use-after-free
• use-after-free
• ntfs
• general protection fault
• kernel panic
• Oops:
• copy_to_user
• volume_label

What your security team should do

• Prioritize patching Linux systems that mount NTFS volumes, especially desktops, file-ingest systems, removable-media processing systems, forensic workstations, and shared multi-user hosts.
• Reboot systems after kernel updates and verify they are running the patched kernel version.
• Restrict or disable NTFS mounting for untrusted users until patching is complete.
• Review local access controls because exploitation requires local privileges; reduce unnecessary shell access and sudo-capable paths.
• Enable or review kernel crash, audit, and endpoint telemetry for suspicious ioctl activity against NTFS mount points.
• If kernel warnings, KASAN reports, or unexplained crashes involving NTFS occurred since publication, preserve logs and investigate for possible exploitation attempts.
• Do not treat the low EPSS score as a reason to ignore the issue on high-risk local multi-user or removable-media systems; the technical impact is kernel-level.