Cloudanix VulnDB

CVE-2026-98636

None

CVSS

—

EPSS

0.2%

Published

Oct 18, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A specially made compressed file archive can crash the computer when the system tries to open it, so organizations should update their systems and avoid opening suspicious archives.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Moderate
Impact
Denial Of Service
Component
OS kernel
Class
Improper Input Validation
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Missing dictionary-size range validation in squashfs_xz_comp_opts allows a zero value (when COMP_OPTS flag is set) to reach ffs() and subsequent left-shift operations, producing a negative shift count and out-of-bounds shift.

Why it matters to the business

Mounting a malicious SquashFS image can trigger a kernel oops or panic, causing denial of service on any system that processes untrusted images; the flaw is five days old with negligible exploit probability and no known in-the-wild use.

How an attack unfolds

An attacker crafts a SquashFS filesystem whose compression-options block sets the COMP_OPTS flag but leaves dict_size zero; when the image is mounted, squashfs_comp_opts calls squashfs_xz_comp_opts, which performs ffs(0)-1 yielding -1 and then evaluates the malformed dict_size against shifted constants, triggering the undefined shift behavior.

How to fix it

Upgrade to a Linux kernel containing the upstream commit that adds the dictionary-size range check before the shift operations; rebuild and reboot any systems or containers that use the affected kernel; until patched, avoid mounting SquashFS images from untrusted sources.

How to confirm the fix worked

Confirm the running kernel contains the range-check patch by inspecting the squashfs_xz_comp_opts function or matching the kernel version against the fixed release; attempt to mount a test image that sets COMP_OPTS=1 with dict_size=0 and verify the mount fails gracefully with EINVAL rather than oopsing.

Typical attack path

  1. Create or modify a SquashFS image to contain a COMP_OPTS block with dict_size set to zero
  2. Place the image on a system or deliver it to a target that will mount it (local media, loopback, network share, container image, etc.)
  3. Trigger mount of the image via mount(2), systemd mount units, container runtime, or automated unpacker
  4. Kernel executes squashfs_xz_comp_opts on the malformed options, performs the out-of-bounds shift, and crashes

How to detect it

Search kernel logs (dmesg, /var/log/kern.log, journalctl) for oops traces or UBSAN reports mentioning squashfs, ffs, shift-out-of-bounds, or squashfs_xz_comp_opts; correlate with mount syscalls or loop-device creation involving .squashfs or squashfs filesystem type.

What your security team should do

  • Apply the kernel update containing the SquashFS dictionary-size check at the earliest maintenance window
  • Add policy or tooling to block or quarantine untrusted SquashFS images until systems are patched
  • Monitor kernel logs for shift-out-of-bounds warnings or oopses referencing squashfs_xz_comp_opts
  • Review any automated workflows that mount SquashFS images from external or user-supplied sources

The record

In the Linux kernel, the following vulnerability has been resolved: squashfs: Add dictionary size range check to prevent shift-out-of-bounds When an abnormal SquashFS image (COMP_OPTS flag is 1 but dictionary size is 0) is mounted, and performs shift operations using dictionarysize, the shift exponent is -1, causing a shift-out-of-bounds. Detail as below: squashfs_comp_opts(msblk, buffer, length) squashfs_xz_comp_opts() if (comp_opts) n = ffs(opts->dict_size) - 1;<----opts->dict_size=0, n=-1 if (opts->dict_size != (1 << n) && opts->dict_size != (1 << n) + (1 << (n + 1))) <----shift-out-of-bounds Fix it by adding a dictionary size range check before the shift operation.

Affected packages

Ecosystem Package Introduced Fixed