CVE-2025-38715

What it actually does

Unbounded offset and length parameters in HFS bnode functions (hfs_bnode_read, write, clear, copy, move) allow slab-out-of-bounds memory access, enabling kernel memory corruption or crashes.

Why it matters to the business

Systems mounting HFS volumes, including container workloads on affected MinimOS/containerd setups, risk denial of service or local privilege escalation with potential data integrity loss; low exploit prevalence but high impact on kernel stability.

How an attack unfolds

A local attacker supplies a crafted HFS image or performs specific bnode operations that supply invalid offsets or lengths; without the new validation methods the kernel reads or writes beyond allocated slab memory, leading to corruption. Threat actors such as VMSCAPE and campaigns targeting Container-Optimized OS have shown interest in similar Linux kernel memory issues for container escape.

How to fix it

Upgrade affected packages to the listed fixed versions: containerd-1 and related MinimOS components to 1.7.27-r4; Linux kernel trees to commit e7d2dc2421e821e4045775e6dc226378328de6f6 or later stable releases containing the is_bnode_offset_valid and check_and_correct_requested_length checks.

How to confirm the fix worked

Verify kernel and containerd package versions match or exceed the fixed releases; confirm presence of the new validation functions in hfs_bnode.c; test HFS mount and bnode operations with boundary values.

Typical attack path

1. Obtain local access on a system with HFS support enabled
2. Mount or interact with a maliciously crafted HFS filesystem image
3. Trigger hfs_bnode_read/write/clear/copy/move with out-of-range offset or length
4. Cause slab corruption leading to crash or escalation

How to detect it

Review kernel logs for HFS-related slab-out-of-bounds warnings or oops after the patch date; inspect audit logs for unexpected HFS mount attempts by non-root users; correlate with container runtime activity on MinimOS/containerd hosts.

What your security team should do

• Prioritize patching Linux kernel and containerd packages on all systems that may encounter HFS volumes
• Restrict local user access to untrusted HFS images until updated
• Monitor for kernel oops or slab corruption logs related to HFS