CVE-2024-26622

What it actually does

Use-after-free write in tomoyo_write_control() caused by fetching head->write_buf before acquiring head->io_sem, allowing concurrent write() operations on long lines to trigger double-free and memory corruption in the Linux kernel TOMOYO module.

Why it matters to the business

Local attackers can crash or corrupt kernel memory on affected Linux systems, potentially leading to denial of service or escalation to root privileges; widespread impact across servers, desktops, and Android devices running vulnerable kernels, though exploitation remains uncommon.

How an attack unfolds

An attacker with local access issues multiple concurrent write() system calls containing long lines to a TOMOYO control interface; the race condition allows one thread to free the write buffer while another still references it, resulting in a use-after-free write that can be leveraged for memory corruption or code execution.

How to fix it

Update the Linux kernel to a version containing commit a23ac1788e2c828c097119e9a3178f0b7e503fee or later; rebuild and reboot into the patched kernel. Where possible, restrict unprivileged access to TOMOYO interfaces via LSM or seccomp policies until patches are applied.

How to confirm the fix worked

Verify the running kernel contains commit a23ac1788e2c828c097119e9a3178f0b7e503fee by inspecting /proc/version or kernel source; attempt to reproduce the original race condition under controlled concurrency to confirm the fix prevents the UAF.

Typical attack path

1. Obtain local unprivileged access to a vulnerable Linux system
2. Identify and open the TOMOYO write control interface
3. Issue multiple overlapping write() calls with long payloads to trigger the race
4. Trigger use-after-free write to corrupt kernel memory structures
5. Escalate privileges or cause kernel panic for denial of service

How to detect it

Review kernel logs for use-after-free warnings or slab corruption messages related to tomoyo_write_control; inspect auditd or syscall logs for unusual concurrent write patterns to TOMOYO control files; correlate with any observed kernel oops or panic traces referencing the TOMOYO module.

What your security team should do

• Prioritize patching production Linux kernels within the next maintenance window
• Monitor vendor advisories for distribution-specific backports of the fix
• Limit unprivileged write access to securityfs TOMOYO entries via mount options or LSM
• Add kernel memory corruption detection tooling (e.g., KASAN) to CI test suites