Blacklist the squashfs Kernel Module to Mitigate CVE-2026-23388 on Linux

What the CVE-2026-23388 squashfs blacklist Worklet does

This Automox Worklet™ adds a modprobe blacklist entry for the squashfs kernel module on Linux endpoints, based on Red Hat's mitigation guidance for CVE-2026-23388. It targets endpoints that don't use squashfs. The blacklist is a temporary workaround until you install a fixed kernel.

The Worklet writes one line, blacklist squashfs, to /etc/modprobe.d/cve-2026-23388-squashfs.conf. That entry tells modprobe not to load squashfs automatically, such as when something tries to mount a Squashfs image. When /etc/modprobe.d exists, evaluation and remediation log the running kernel version and its squashfs support state: module, builtin, absent, or unknown. Rollback runs don't log either value.

The CIS hardening Worklet for squashfs in the System Preferences category takes a different approach. When squashfs is loaded, it writes install squashfs /bin/true to /etc/modprobe.d/squashfs.conf and unloads the module with rmmod. If you've already applied that rule, the endpoint reports compliant here and gets no change.

Why blacklist squashfs until you can install a fixed kernel

CVE-2026-23388 is an out-of-bounds read in the kernel Squashfs code. NVD scores it 7.1 (High), and Red Hat rates it Moderate. A crafted Squashfs image with a corrupted index lookup table triggers it. A local user who can get the kernel to mount that image can crash the endpoint. On a production server, that's an unplanned outage.

Tenable detects the flaw with plugin 303673, an unpatched-vulnerability check that flags kernels with no vendor fix. Where your distribution ships a fixed kernel, that's the preferred fix. Fix status by kernel line:

• Upstream stable kernels: 5.10.253, 5.15.203, 6.1.167, 6.6.130, 6.12.77, 6.18.17, and 6.19.7, plus mainline 7.0

• Ubuntu generic kernels: 5.15.0-186 on 22.04 and 6.8.0-136 on 24.04

• Ubuntu cloud, low-latency, and hardware enablement (HWE) kernels: check Ubuntu's CVE page for your flavor's fixed version

• RHEL 7 through 10: Red Hat lists the fix as deferred

The snapd service mounts every snap package as a Squashfs image. On kernels that load squashfs as a module, a blanket blacklist would break all snaps on the next reboot. The Worklet skips endpoints with snapd, along with any that have a Squashfs filesystem mounted or squashfs built in. You can scope one policy to a mixed Linux fleet and let each endpoint's state decide whether it gets the change.

How the squashfs blacklist mitigation works

1. Evaluation phase: Checks for /etc/modprobe.d first and exits 0 as not applicable if it's missing. It then reads /lib/modules/$(uname -r) for the running kernel.

   A squashfs entry in modules.builtin means the driver is built into the kernel image. It isn't a module that modprobe loads. An entry in modules.dep, or a squashfs.ko file on disk, means a loadable module. With no match and modules.dep present, the kernel has no squashfs support. A missing module directory or modules.dep leaves the state undetermined.

   For a built-in driver, the Worklet logs the fixed kernel versions and NO ACTION POSSIBLE. It logs NOT APPLICABLE for a kernel without squashfs support and UNDETERMINED for an unknown state. All three exit 0 with no remediation scheduled.

   For a loadable module, the Worklet scans the .conf files in /etc/modprobe.d for blacklist squashfs, or for an install squashfs rule pointing at /bin/false or /bin/true. On a match, it logs the file that holds the entry and reports COMPLIANT.

   Without a match, it looks for the snap command, the /var/lib/snapd directory, or a squashfs entry in /proc/mounts. If it finds any of these, it logs a WARN with the reason and the fixed kernel versions, then exits 0 as SKIPPED FOR SAFETY. If it finds none of them, the Worklet reports NON-COMPLIANT and exits 1 to schedule remediation.

2. Remediation phase: Writes blacklist squashfs to /etc/modprobe.d/cve-2026-23388-squashfs.conf on endpoints that pass the applicability checks. It runs those checks itself, in the same order, so you can launch it directly with FixNow or Run Policy.

   The Worklet exits 0 with no change for absent or undetermined squashfs support, or for an existing block. It exits 1 with no change for a built-in driver, snapd, or a mounted Squashfs filesystem.

   Before the write, it records in /var/lib/automox/workletcache/ee6dc758-7117-5e04-92cc-e379c82ebbd3/prior-state.txt whether cve-2026-23388-squashfs.conf already existed, and backs up any existing copy. A post-write check then confirms the block and logs COMPLIANT. If /proc/modules lists squashfs as loaded, it also logs a WARN.

   Setting dryrun=yes logs each planned change without writing. Setting rollback=yes deletes the file or restores the backup, based on the recorded prior state.

   After you install a fixed kernel and reboot, a rollback lets squashfs load automatically again. Set rollback=yes at the top of the remediation code and run it directly with FixNow (Remediation Only) or Run Policy. Scheduled runs call remediation only when evaluation reports non-compliant.

CVE-2026-23388 squashfs mitigation requirements

• Linux servers or workstations whose running kernel ships squashfs as a loadable module, such as RHEL 7 or later

• Module loading through modprobe and /etc/modprobe.d

• A fixed kernel from your distribution for endpoints with squashfs built into the kernel, such as standard Ubuntu 22.04 and 24.04 kernels. The Worklet makes no change on those endpoints and logs the fixed versions.

• Root privileges for the Automox agent, which writes to /etc/modprobe.d

• Standard utilities on the PATH: grep, find, uname, awk, wc, tr, date, mkdir, cp, rm, cat, and tee

• No snapd installation and no mounted Squashfs filesystems at remediation time

• Optional remediation variables dryrun and rollback, which default to no

Expected squashfs module state after remediation

The blacklist blocks future automatic loads. The next evaluation on any remediated endpoint logs COMPLIANT and names /etc/modprobe.d/cve-2026-23388-squashfs.conf as the block entry. If squashfs was loaded during remediation, you'll see a WARN in the Activity Log. The module stays in memory until you reboot the endpoint. You can also unload it with modprobe -r squashfs once nothing uses it.

Endpoints with snapd, a mounted Squashfs filesystem, or a built-in squashfs driver keep their current modprobe configuration. For those endpoints, you'll find the reason and the fixed kernel versions to install in the Activity Log.