CVE-2026-43117

What it actually does

This flaw is a Linux kernel btrfs bug triggered when overlayfs is layered on top of btrfs and the btrfs_sync_file() tracepoint reads the wrong superblock from a dentry. The incorrect superblock reference can cause invalid filesystem identifier handling and a kernel crash. The practical impact is denial of service through kernel panic or system instability on affected systems using btrfs with overlayfs; confidentiality impact from the provided description is not evident despite the high assigned CVSS vector.

Why it matters to the business

Affected Linux systems may crash or become unstable when specific filesystem operations occur on overlayfs backed by btrfs, potentially interrupting workloads, containers, build systems, or services that rely on overlay storage. This is especially relevant for container hosts and developer/build infrastructure that commonly use overlay-style filesystems. The vulnerability is not currently listed in CISA KEV, has no known exploit maturity in the provided data, and has a low, flat EPSS score, so urgency should be driven primarily by exposure to btrfs plus overlayfs rather than broad internet exploitation risk.

How an attack unfolds

An attacker would first need the ability to cause file synchronization activity against an overlayfs mount backed by btrfs on a vulnerable Linux kernel. In a common scenario, this could be through access to a container, workload, or service that can create, modify, and sync files on an overlay-backed filesystem. When the vulnerable kernel tracepoint handles btrfs_sync_file(), it derives the superblock from the overlay dentry rather than the underlying btrfs inode. That mismatch can corrupt the tracepoint's filesystem identifier handling and trigger a kernel crash, resulting in denial of service for the host and its dependent workloads.

How to fix it

Upgrade the Linux kernel to a vendor release that includes the upstream btrfs fix changing btrfs_sync_file() tracepoint handling to use file_inode(file)->i_sb rather than dentry->d_sb. Because no exact fixed versions were provided, use distribution-specific security advisories and kernel changelogs for CVE-2026-43117 or the btrfs tracepoint fix. If immediate patching is not possible, reduce risk by avoiding overlayfs-on-btrfs configurations on vulnerable kernels, moving container overlay storage to a non-btrfs backing filesystem where feasible, disabling unnecessary btrfs tracing/tracepoint collection if operationally acceptable, and restricting untrusted users or workloads from performing arbitrary filesystem activity on affected hosts.

How to confirm the fix worked

Confirm exposure by checking whether the host runs a vulnerable Linux kernel and whether overlayfs is mounted over btrfs. Validate remediation by confirming the installed kernel package includes the btrfs_sync_file() tracepoint fix from the relevant vendor advisory. Operationally, verify that affected systems can run representative overlayfs-backed file create/write/fsync workloads without kernel oops, panic, or btrfs tracepoint errors. Review /proc/mounts, findmnt, or equivalent inventory data to identify overlay mounts whose lowerdir, upperdir, or workdir reside on btrfs.

Typical attack path

1. Identify or gain access to a Linux system using btrfs as the backing filesystem with overlayfs layered on top.
2. Obtain the ability to perform file operations within a container, workload, or user context that writes to the overlay-backed filesystem.
3. Create or modify files and trigger synchronization paths such as fsync(), sync_file_range(), or application-level flush behavior.
4. Cause the vulnerable btrfs_sync_file() tracepoint path to execute while it references the overlay superblock incorrectly.
5. Trigger a kernel crash or system instability, interrupting services running on the host.

How to detect it

Look for signs of prior kernel crashes or instability correlated with btrfs, overlayfs, and file synchronization activity. Useful sources include kernel logs, systemd journal, /var/log/kern.log, /var/log/messages, crash dumps, kdump/vmcore artifacts, container runtime logs, and monitoring alerts for unexpected reboots. Search for kernel oops, panic, BUG, WARNING, or call traces mentioning btrfs_sync_file, btrfs tracepoints, overlayfs, dentry superblock handling, or fsid assignment. Also correlate crashes with container or workload activity that performs heavy file writes, fsync operations, image builds, package installs, database flushes, or CI job execution on overlay-backed filesystems. There are no known network indicators from the provided information; detection should focus on host telemetry and crash forensics.

• btrfs_sync_file
• btrfs: tracepoints
• overlayfs
• overlay
• BTRFS
• kernel BUG
• kernel panic
• Oops:
• Call Trace:
• RIP: btrfs_sync_file
• fsid
• dentry->d_sb
• file_inode(file)->i_sb
• /var/crash/
• /var/lib/systemd/coredump/
• /proc/mounts
• type overlay
• type btrfs

What your security team should do

• Prioritize patching Linux hosts that combine btrfs and overlayfs, especially container hosts, CI/build workers, and multi-tenant systems where less-trusted workloads can trigger filesystem activity.
• Inventory kernel versions and filesystem layouts to identify overlayfs-on-btrfs deployments.
• Apply vendor kernel updates that include the btrfs tracepoint fix; reboot systems where required for the new kernel to take effect.
• If patching is delayed, migrate high-risk overlay workloads away from btrfs-backed storage or restrict access to affected hosts.
• Monitor for kernel oops, panic, btrfs, and overlayfs errors indicating attempted or accidental triggering.
• Because EPSS is low and no KEV listing or known exploit maturity is reported, balance urgency against operational exposure rather than treating all Linux systems as equally at risk.