CVE-2026-63796

What it actually does

This flaw is a Linux kernel OCFS2 filesystem use-after-free/out-of-bounds bitmap access caused by insufficient validation of on-disk group bitmap descriptor metadata. A malicious OCFS2 group descriptor can advertise bg_size/bg_bits values that are consistent with allocator chain geometry but larger than the bitmap bytes that physically fit in the descriptor block. When the kernel later scans or updates allocation bitmaps, OCFS2 code can read or write past bg_bitmap, producing kernel memory corruption. Depending on kernel configuration, memory layout, and attacker control over the filesystem image or shared storage metadata, impact can range from a kernel crash to potential kernel-context code execution or privilege escalation.

Why it matters to the business

Systems that mount or operate on untrusted or attacker-modifiable OCFS2 filesystems may be exposed to high-impact kernel compromise or denial of service. Because this is in kernel filesystem code, a successful exploit can affect the entire host rather than only one application. OCFS2 is commonly associated with clustered Linux deployments and shared storage, so disruption may affect multiple nodes or shared workloads if a crafted or corrupted filesystem is used. The issue is not currently listed in CISA KEV, has no known public exploit maturity in the provided data, and has a low EPSS score, but the CVSS impact is high and remediation should be prioritized for systems using OCFS2 or accepting filesystem images from less-trusted sources.

How an attack unfolds

An attacker first needs a path to influence OCFS2 filesystem metadata, such as providing a crafted OCFS2 image, modifying shared block storage, compromising a lower-privileged account that can write to or trigger operations on an OCFS2 mount, or otherwise causing a vulnerable kernel to process malicious OCFS2 group descriptors. The attacker constructs a group bitmap descriptor whose bg_size or bg_bits claims more bitmap capacity than fits in the physical group descriptor block while still satisfying older allocator chain-geometry checks. When the vulnerable kernel mounts or uses the filesystem and performs allocation-related operations such as writes, cluster allocation, or bitmap scans, OCFS2 trusts the oversized descriptor and later scans or updates past the end of bg_bitmap. This can trigger a KASAN-detectable use-after-free/out-of-bounds access, crash the kernel, or potentially corrupt kernel memory in a way that enables privilege escalation or arbitrary kernel code execution.

How to fix it

Upgrade to a Linux kernel version that includes the OCFS2 fix rejecting oversized group bitmap descriptors using the physical-capacity check based on ocfs2_group_bitmap_size(), while retaining allocator chain-geometry validation. If vendor kernels are used, apply the relevant distribution kernel security update rather than relying only on upstream version numbers. Where immediate patching is not possible, reduce exposure by avoiding mounts of untrusted OCFS2 images, restricting who can attach or modify shared storage backing OCFS2 filesystems, disabling or unloading OCFS2 support where it is not required, and applying normal least-privilege controls to users and services that can write to OCFS2-mounted filesystems. Treat any OCFS2 filesystem with unexpected corruption reports or kernel crashes in allocation paths as potentially hostile until inspected offline.

How to confirm the fix worked

Confirm remediation by verifying that installed kernel packages include the vendor fix for oversized OCFS2 group bitmap descriptors. Check running kernel versions on all systems that can mount OCFS2 and ensure they have been rebooted into the patched kernel. Validate exposure by inventorying loaded modules and mounted filesystems for OCFS2 usage, for example by checking lsmod, /proc/filesystems, /proc/mounts, findmnt, or distribution package inventories. Functional validation can include mounting known-good OCFS2 filesystems and confirming normal allocation/write operations succeed after patching. Security validation should avoid testing crafted malicious images on production hosts; if exploit reproduction is required, use an isolated lab VM with crash dumps enabled.

Typical attack path

1. Identify a Linux system running a vulnerable kernel with OCFS2 support and an accessible OCFS2 filesystem or shared storage path.
2. Gain the ability to supply, mount, or modify an OCFS2 filesystem image or its underlying block-device metadata.
3. Create or alter an OCFS2 group descriptor so bg_size/bg_bits exceed the bitmap capacity physically available in the descriptor block.
4. Cause the target kernel to mount or operate on the malicious filesystem.
5. Trigger allocation activity, such as file writes or cluster allocation, that reaches OCFS2 bitmap scanning and update paths.
6. Abuse the resulting kernel memory corruption for denial of service, privilege escalation, or further kernel compromise, depending on exploit reliability and protections.

How to detect it

Look for evidence that vulnerable OCFS2 code paths crashed or detected memory corruption during filesystem allocation activity. Primary sources include kernel logs, journalctl -k output, dmesg, crash dumps, kdump/vmcore artifacts, syslog, distribution kernel-oops collectors, EDR telemetry for kernel panics, and storage cluster logs showing OCFS2 errors or unexpected filesystem corruption. Search for KASAN use-after-free reports involving _find_next_bit, ocfs2_find_max_contig_free_bits, ocfs2_block_group_set_bits, ocfs2_cluster_group_search, ocfs2_claim_suballoc_bits, __ocfs2_claim_clusters, ocfs2_add_clusters_in_btree, ocfs2_write_begin, or ocfs2_file_write_iter. Also investigate unexpected reboots, kernel panics, remounted read-only filesystems, or OCFS2 errors occurring shortly after new filesystem images were attached, shared storage was modified, or unusual write-heavy activity occurred on OCFS2 mounts. If a suspicious event is found, preserve kernel logs, vmcore, the OCFS2 block device or image, mount history, storage management logs, and administrative command history related to mount, losetup, modprobe, tunefs.ocfs2, fsck.ocfs2, and shared disk operations.

• KASAN use-after-free in _find_next_bit
• Read of size 8
• ocfs2_find_max_contig_free_bits
• ocfs2_block_group_set_bits
• ocfs2_cluster_group_search
• ocfs2_bg_discontig_fix_result
• ocfs2_search_chain
• ocfs2_claim_suballoc_bits
• __ocfs2_claim_clusters
• ocfs2_add_clusters_in_btree
• ocfs2_add_inode_data
• ocfs2_write_begin_nolock
• ocfs2_write_begin
• ocfs2_file_write_iter
• fs/ocfs2/suballoc.c
• ocfs2_validate_gd_parent
• bg_bitmap
• bg_bits
• bg_size
• ocfs2_group_bitmap_size
• kernel BUG at fs/ocfs2
• BUG: KASAN: use-after-free
• BUG: unable to handle kernel paging request
• general protection fault
• Kernel panic - not syncing
• OCFS2

What your security team should do

• Prioritize patching Linux systems that use OCFS2, clustered filesystems, or shared block storage, especially where less-trusted users or services can influence filesystem contents.
• Inventory OCFS2 usage across servers by checking mounted filesystems, loaded kernel modules, storage cluster configurations, and kernel package versions.
• Restrict the ability to mount filesystem images or modify shared block devices to trusted administrators only.
• Disable or remove OCFS2 support on systems that do not require it.
• Review recent kernel crashes, oops reports, KASAN reports, and storage/filesystem corruption events for OCFS2 allocation-path indicators.
• If suspicious OCFS2 corruption or matching kernel traces are found, preserve the affected disk image or block-device snapshot for offline forensic analysis before repair attempts.
• Monitor vendor advisories for exact fixed kernel package versions and deploy distribution-supported updates promptly.