CVE-2024-41016

What it actually does

Missing bounds check before memcmp in ocfs2_xattr_find_entry allows out-of-bounds read when processing non-indexed xattrs from crafted filesystem images, leading to kernel memory access violation and potential crash.

Why it matters to the business

Systems using the ocfs2 filesystem on affected Linux kernels face denial-of-service risk from malicious disk images; widespread kernel deployments increase exposure across servers and containers handling untrusted storage.

How an attack unfolds

An attacker crafts a poisonous ocfs2 filesystem image containing out-of-bounds xattr data, mounts the image on a vulnerable kernel, and triggers ocfs2_xattr_find_entry during xattr lookup, causing the kernel to read beyond allocated memory and crash.

How to fix it

Upgrade the Linux kernel to the fixed commit e2b3d7a9d019d4d1a0da6c3ea64a1ff79c99c090 or later stable releases containing the strict bounds check in ocfs2_xattr_find_entry.

How to confirm the fix worked

Confirm kernel source contains the added bounds check before memcmp, rebuild and boot the patched kernel, then attempt to mount crafted test images to verify no crash occurs.

Typical attack path

1. Craft malicious ocfs2 image with oversized or offset xattr entries
2. Present image to target via removable media, network share, or container volume
3. Victim mounts the image or accesses xattrs on the filesystem
4. ocfs2_xattr_find_entry performs unbounded memcmp
5. Kernel reads invalid memory and panics

How to detect it

Review kernel logs for oops or panic entries mentioning ocfs2_xattr_find_entry or memcmp failures; inspect mount operations of ocfs2 volumes from external or untrusted sources.

What your security team should do

• Prioritize kernel upgrades on any system exposing ocfs2 mounts to untrusted images
• Disable ocfs2 module if the filesystem is not required
• Monitor for kernel oops/panic logs related to ocfs2 xattr processing
• Apply the fix within standard patch windows given low EPSS and no KEV listing