CVE-2024-26764

What it actually does

Calling kiocb_set_cancel_fn() for I/O submitted via io_uring instead of libaio triggers a kernel WARN_ON in fs/aio.c:598, logging an unnecessary stack trace without affecting correctness.

Why it matters to the business

Systems using io_uring for file I/O may see spurious kernel warnings that increase log volume, complicate troubleshooting, and raise false-positive alerts for kernel stability issues.

How an attack unfolds

An attacker or benign workload submits read/write operations through io_uring; the kernel path invokes kiocb_set_cancel_fn without the IOCB_AIO_RW flag, hitting the warning condition in aio.c.

How to fix it

Upgrade the Linux kernel to a version containing commit 337b543e274fe7a8f47df3c8293cc6686ffa620f or later; rebuild and reboot affected systems.

How to confirm the fix worked

Confirm the presence of commit 337b543e274fe7a8f47df3c8293cc6686ffa620f in the running kernel source or verify that io_uring I/O no longer produces the aio.c:598 warning.

Typical attack path

1. Submit I/O via io_uring SQE
2. Kernel calls ffs_epfile_read_iter or equivalent
3. io_read or io_write invokes kiocb_set_cancel_fn
4. Condition check fails because IOCB_AIO_RW is absent
5. WARN_ON fires and stack trace is emitted

How to detect it

Search kernel logs (dmesg, journalctl, /var/log/kern.log) for the string 'kiocb_set_cancel_fn+0x9c/0xa8' or the call trace containing 'io_uring_enter' and 'ffs_epfile_read_iter'.

• WARNING: CPU:.*PID:.*at fs/aio.c:598 kiocb_set_cancel_fn
• ffs_epfile_read_iter.*io_read.*io_issue_sqe
• __arm64_sys_io_uring_enter

What your security team should do

• Prioritize kernel upgrade on all systems that use io_uring for production workloads
• Monitor kernel logs for the specific WARN_ON string until patches are applied
• Review any custom io_uring usage for unintended side effects after the update