What is the CVSS score of CVE-2026-63812?

CVE-2026-63812 has a CVSS 3.1 base score of 7.8 (High). CVSS vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H. EPSS exploitation probability: 0.2%.

Which versions of Linux Kernel are affected by CVE-2026-63812?

Linux kernel F2FS driver vulnerability threatens data confidentiality and system availability on affected infrastructure running versions 6.6-7.x.. A patch is available.

How to fix or mitigate CVE-2026-63812?

Within 24 hours, inventory systems running affected Linux kernel versions (6.6.x-6.18.x, 7.x pre-releases) with F2FS-formatted storage to determine organizational exposure; no public exploit identified at time of analysis, so this can follow standard patching procedures. Over the following 7 days, deploy patched kernel versions through your distribution's official channels, prioritizing systems with sensitive data or direct user access. Complete the rollout across all affected systems within 30 days and validate that F2FS filesystems operate without cache consistency errors.

Linux Kernel CVE-2026-63812

EUVD-2026-45478 HIGH

2026-07-19 Linux

GHSA-7w3g-6v3x-44mp

Information Disclosure Linux

7.8

CVSS 3.1 · Vendor: Linux

Severity by source

Vendor (Linux) PRIMARY

7.8 HIGH

AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

vuln.today AI

5.3 MEDIUM

Local F2FS user with low privileges (AV:L/PR:L); real demonstrated impact is a cache-consistency error with possible stale-block reads, so C/I/A are Low rather than High.

3.1 AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L

4.0 AV:L/AC:L/AT:N/PR:L/UI:N/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N

SUSE

5.5 MEDIUM

AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

Primary rating from Vendor (Linux).

CVSS VectorVendor: Linux

Attack Vector

Local

Attack Complexity

Low

Privileges Required

Low

User Interaction

None

Scope

Unchanged

Confidentiality

High

Integrity

High

Availability

High

Lifecycle Timeline

Analysis Generated

Jul 20, 2026 - 15:38 vuln.today

CVSS changed

Jul 20, 2026 - 15:22 NVD

7.8 (HIGH)

Patch available

Jul 19, 2026 - 14:17 EUVD

CVE Published

Jul 19, 2026 - 12:02 cve.org

HIGH 7.8

CVE Published

Jul 19, 2026 - 12:02 cve.org

UNKNOWN (no severity yet)

DescriptionCVE.org

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

f2fs: fix incorrect FI_NO_EXTENT handling in __destroy_extent_node()

When __destroy_extent_node() sets the inode flag FI_NO_EXTENT, it does not reset the length of the largest extent to 0 and update the inode folio. Since modifications to the extent tree are disallowed afterward, the cached largest extent may become stale. This can trigger the following error in xfstests generic/388:

F2FS-fs (dm-0): sanity_check_extent_cache: inode (ino=1761) extent info [220057, 57, 6] is incorrect, run fsck to fix

In the f2fs_drop_inode path, __destroy_extent_node() does not need to guarantee that et->node_cnt is 0, because concurrency with writeback is expected in this path, and writeback may update the extent cache.

This patch reverts commit ed78aeebef05 ("f2fs: fix node_cnt race between extent node destroy and writeback"), and remove the unnecessary zero check of et->node_cnt.

AnalysisAI

Filesystem cache-consistency flaw in the Linux kernel's F2FS (Flash-Friendly File System) driver leaves a stale 'largest extent' entry cached when __destroy_extent_node() sets the FI_NO_EXTENT inode flag without resetting the extent length or updating the inode folio, causing the extent tree to diverge from on-disk metadata. Affected are local users of F2FS-formatted volumes across many stable kernel lines (6.6.x through 6.18.x and 7.x pre-releases); the bug surfaces as a sanity_check_extent_cache error (reproduced by xfstests generic/388) and, per source tagging, carries an information-disclosure angle because stale block mappings can point reads at the wrong physical blocks. No public exploit identified at time of analysis; EPSS is 0.16% (5th percentile), and it is not on CISA KEV.

Technical ContextAI

F2FS is a log-structured filesystem optimized for NAND flash, widely used on Android and embedded/flash storage. It maintains an in-memory extent cache (an extent tree plus a cached 'largest extent') that maps logical file offsets to physical block addresses to accelerate lookups. The bug lives in __destroy_extent_node(): when it raises the FI_NO_EXTENT inode flag - which forbids any further modification of that inode's extent tree - it fails to zero the cached largest-extent length and flush the inode folio. The result is a stale mapping that can no longer be corrected, so f2fs's sanity_check_extent_cache() later detects that the cached extent info (offset, length, block) is inconsistent and demands an fsck. The change also reverts commit ed78aeebef05 ('f2fs: fix node_cnt race between extent node destroy and writeback') and removes an unnecessary et->node_cnt==0 assertion in the f2fs_drop_inode path, where concurrency with writeback is legitimately expected. CWE is not assigned in the source data; the root-cause class is best described as incorrect state/synchronization of a cached data structure (stale cache leading to metadata inconsistency).

RemediationAI

Patch available per vendor advisory - upgrade to a fixed stable kernel: 6.6.144, 6.12.95, 6.18.38, 7.1.3, or later (fix also landed for 7.2-rc1). The corrective commits are published on git.kernel.org, e.g. https://git.kernel.org/stable/c/7e4d8f98be63f98856a5176b9188dada6e7ba9ee, https://git.kernel.org/stable/c/58a5deb220bcac4c73bf58954c0845644c997487, https://git.kernel.org/stable/c/20190e498057997532c7f186d081011f18e0a462, https://git.kernel.org/stable/c/edf12cbeeeabe799bd2ee21fdb5c336cce6fbad7, and https://git.kernel.org/stable/c/1f70ddb28a3c71df124da5fa4040c808116d6bb9. If you cannot rebuild the kernel immediately, the practical compensating control is to avoid F2FS for sensitive volumes on unpatched hosts (use ext4/xfs instead), since the flaw is inherent to the F2FS extent cache and cannot be toggled off by a mount option; the trade-off is losing F2FS's flash-optimized behavior. If a system already logged 'sanity_check_extent_cache ... is incorrect, run fsck to fix', run fsck.f2fs on the affected volume to repair the on-disk inconsistency. Because exploitation requires local access, restricting local/untrusted accounts on affected hosts reduces exposure until patching.

Same technique Information Disclosure

View all

CVE-2019-2725 CRITICAL POC

9.8

CVE-2021-34523 CRITICAL POC

9.0

CVE-2013-2251 CRITICAL POC

9.8

CVE-2017-5638 CRITICAL POC

9.8

CVE-2025-24813 CRITICAL POC

9.8

CVE-2015-1701 HIGH POC

7.8

CVE-2017-0147 HIGH POC

7.5

CVE-2014-6324 HIGH POC

8.8

Vendor StatusVendor

SUSE

Severity: Moderate

Product	Status
SUSE Linux Enterprise Desktop 15 SP7	Not-Affected
SUSE Linux Enterprise Desktop 15 SP7	Not-Affected
SUSE Linux Enterprise High Availability Extension 15 SP7	Not-Affected
SUSE Linux Enterprise High Availability Extension 15 SP7	Not-Affected
SUSE Linux Enterprise High Availability Extension 16.0	Not-Affected

CVE-2026-63812 vulnerability details – vuln.today

Back

Linux Kernel CVE-2026-63812

Severity by source

CVSS VectorVendor: Linux

Lifecycle Timeline

DescriptionCVE.org

AnalysisAI

Technical ContextAI

RemediationAI

Same technique Information Disclosure

Vendor StatusVendor

SUSE

Share

External POC / Exploit Code