Linux - System Preferences - Ensure Mounting of Freevxfs Filesystems is Disabled

What the freevxfs filesystem disabler does

This Automox Worklet™ disables the freevxfs filesystem driver on Linux endpoints where the module is currently loaded. The Worklet writes the line install freevxfs /bin/true into /etc/modprobe.d/freevxfs.conf, which tells modprobe to substitute /bin/true for any future load attempt and silently no-op the request. The Worklet then runs rmmod freevxfs to unload the module from the running kernel so the endpoint returns to the desired state without waiting for a reboot.

The freevxfs driver is a legacy read-only reimplementation of the Veritas VxFS filesystem. The driver is shipped in the upstream Linux kernel but is almost never needed on a modern RHEL, Ubuntu, Debian, SUSE, Rocky, Alma, or Amazon Linux endpoint. CIS Distribution Independent Linux Benchmark control 1.1.1.2 names freevxfs as one of the unused filesystem types that should be unloadable on a hardened server, alongside cramfs, jffs2, hfs, hfsplus, squashfs, and udf.

The Worklet is safe to run on a recurring policy. Endpoints where freevxfs is not currently resident in the kernel report as compliant on the next evaluation and skip remediation, including endpoints where the install rule has already done its job and prevented future loads. Endpoints that drift back into a freevxfs-loaded state, for example after a userspace process triggers an automount of a VxFS volume, are caught on the next policy run and corrected.

Why disable freevxfs across the Linux fleet

Every kernel driver loaded on an endpoint is reachable code. A user with the right privileges, or an attacker who lands a foothold and can hand-craft a filesystem image, can mount a malicious freevxfs volume and try to trigger a parser bug in driver code that almost no one audits. Filesystem drivers have a long history of CVEs reachable from a user-controlled image, including parser bugs in cramfs, hfs, hfsplus, and udf. The freevxfs driver belongs to the same low-attention tier. The defensive answer is the one CIS 1.1.1.2 recommends: keep the module unloadable on every server that does not need to mount VxFS volumes.

A recurring Automox policy against your Linux server, container host, and workstation groups detects endpoints where the freevxfs module is currently loaded, writes the install freevxfs /bin/true rule to /etc/modprobe.d/freevxfs.conf, and unloads the module from the running kernel. The same policy catches the module being reloaded later and corrects it on the next evaluation, so CIS 1.1.1.2 holds across RHEL, Debian, Ubuntu, and SUSE hosts without per-host modprobe inspection.

How freevxfs module removal works

1. Evaluation phase: The Worklet runs modprobe -n -v freevxfs to confirm the kernel knows about the freevxfs module. If that command fails, the driver is not present and the script exits 0 as compliant. If the driver is known, the Worklet runs lsmod | grep freevxfs to test whether the module is currently resident in the running kernel. A non-empty result flags the endpoint non-compliant with exit 1 and schedules remediation.

2. Remediation phase: The Worklet touches /etc/modprobe.d/freevxfs.conf and writes the line install freevxfs /bin/true into it. The install directive instructs modprobe to run /bin/true in place of the real module load, which exits 0 without inserting any code into the kernel. The Worklet then runs rmmod freevxfs to evict the copy already in the running kernel and re-checks lsmod | grep freevxfs to confirm the module is unloaded before exiting 0.

Freevxfs hardening requirements

• Linux endpoint running RHEL, CentOS, Rocky, Alma, Fedora, Ubuntu, Debian, SUSE, or Amazon Linux with the standard modprobe toolchain (kmod) installed

• Root privileges for the Automox agent, which is the default agent context on Linux

• Write access to /etc/modprobe.d/ (the standard configuration path used by both systemd-modules-load and the kernel module loader)

• No production workloads currently mounting freevxfs volumes; complete legacy VxFS migrations before applying the Worklet to the affected hosts

• Coordination with any container, virtualization, or backup tooling that may load filesystem modules dynamically at mount time

Expected freevxfs state after remediation

On endpoints that triggered remediation, /etc/modprobe.d/freevxfs.conf contains the line install freevxfs /bin/true, modprobe -n -v freevxfs reports install /bin/true rather than a real load path, and lsmod no longer lists freevxfs. Attempts to mount a freevxfs volume return mount: unknown filesystem type 'freevxfs'. On endpoints where the module was never loaded, the Worklet exits 0 without touching the filesystem, and no /etc/modprobe.d/freevxfs.conf file is written.

Validate the change by running cat /etc/modprobe.d/freevxfs.conf and lsmod | grep freevxfs on a remediated endpoint. The file should contain the install rule and lsmod should return no matches. For CIS Benchmark audit evidence, capture those outputs along with the Automox policy run identifier. The configuration persists across reboots because /etc/modprobe.d/ is consulted by both the initramfs build process and the runtime module loader. Subsequent Automox evaluations report the endpoint as compliant without applying remediation again, because lsmod no longer shows the freevxfs module.