CVE-2024-26972

What it actually does

In UBIFS symlink creation under fscrypt encryption, an error path calls make_bad_inode after i_link allocation via fscrypt_encrypt_symlink, bypassing the free in ubifs_free_inode and leaving an unreferenced kernel memory object.

Why it matters to the business

Systems using encrypted UBIFS filesystems may experience gradual kernel memory exhaustion from repeated symlink operations that encounter journal errors, degrading performance and stability until reboot.

How an attack unfolds

A local attacker triggers symlink creation on an encrypted UBIFS volume while inducing an error in ubifs_jnl_update, causing the kernel to leak the allocated i_link buffer without freeing it.

How to fix it

Upgrade the Linux kernel package to version 6.8.9-1 or later on Debian 13 systems; apply the upstream fix that frees inode->i_link before calling make_bad_inode.

How to confirm the fix worked

Confirm the running kernel is at or above the fixed version; reproduce symlink operations under error injection and verify absence of i_link leaks with kmemleak or similar kernel memory debugging tools.

Typical attack path

1. Mount or access an encrypted UBIFS filesystem
2. Perform symlink creation via vfs_symlink
3. Force an error return from ubifs_jnl_update
4. Observe unreferenced kmemdup allocation via kmemleak

How to detect it

Inspect kernel logs for UBIFS symlink and journal errors; enable and review kmemleak output for unreferenced objects allocated from kmemdup in fscrypt_encrypt_symlink paths.

What your security team should do

• Prioritize kernel upgrade on all systems using UBIFS with encryption
• Monitor kernel memory usage and kmemleak reports in affected environments
• Test symlink workloads under encryption after patching to validate the fix