CVE-2025-21631 - Use-After-Free in Linux Kernel’s BFQ Block Scheduler – Exploit Analysis and Fix

In early 2024, researchers and kernel fuzzers uncovered a serious use-after-free (UAF) vulnerability in the Linux kernel’s BFQ block I/O scheduler. The issue, tracked as CVE-2025-21631, was fixed in Linux 6.6 and newer. This long-read explains the bug, who’s at risk, exploitability, and how to stay safe – all in plain English, with sample code and references for further reading.

What Is CVE-2025-21631?

CVE-2025-21631 is a memory corruption vulnerability in Linux’s BFQ ("Budget Fair Queueing") block device scheduler. When handling concurrent I/O requests, a data structure could be freed while another piece of code still used a pointer to it – classic use-after-free. That leads to a crash, data corruption, or, if an attacker can control the memory, kernel code execution.

This bug was discovered by the syzkaller fuzzer, which analyzes Linux kernels for race conditions and memory safety problems. It generated the following report:

BUG: KASAN: slab-use-after-free in bfq_init_rq+x175d/x17a block/bfq-iosched.c:6958
Read of size 8 at addr ffff8881b57147d8 by task fsstress/232726

In short? Kernel code tried to read memory that was already freed, because the BFQ scheduling thread structure waker_bfqq could be used after its life ended.

The problem happens in this sequence

1. A BFQ data structure is created (a ‘bfq queue’ for I/O).

Any kernel code using the old pointer now triggers a UAF.

In particular, the function bfq_init_rq() called with a stale waker_bfqq pointer after splitting leads to a UAF. Here’s a simplified vulnerable pattern:

// PSEUDO-VULNERABLE CODE SNIPPET
struct bfq_queue *waker_bfqq = rq->waker_bfqq;

bfq_split_bfqq(...); // Frees/invalidates 'waker_bfqq', but we still have the pointer

if (waker_bfqq)
    do_something(waker_bfqq); // UAF here!

All Linux kernels 6.6 and earlier with BFQ enabled

- Enabled by default on some distributions (especially on desktops/laptops, or distros focusing on I/O fairness)
- Exploitable locally (run code on the box); possible vectors in containers or with crafted filesystems

Impact: Local DoS (crash), possible elevation of privilege (under right circumstances)

- Complexity: Requires ability to trigger many block layer operations (I/O-heavy workloads, crafted filesystems, fuzzing)
- Proof-of-Concept: Fuzzers like syzkaller, or mounting/unmounting filesystems while rapidly creating/deleting files on BFQ-enabled device

The bug was discovered running the fsstress tool

fsstress -d /mnt/bfqtest -n 10000

Fuzzer or advanced attackers could manipulate memory allocations just right to reclaim the freed object, injecting attacker-controlled data and possibly controlling kernel behavior or even hijacking kernel execution if they can hit the right window.

The Patch: How Was CVE-2025-21631 Fixed?

Kernel maintainers fixed the bug by making sure waker_bfqq references are re-checked and only dereferenced if valid after splitting. Here’s the essence of the fix:

- if (rq->waker_bfqq)
-     do_something(rq->waker_bfqq);
+ if (rq->waker_bfqq && !bfq_bfqq_expired(rq->waker_bfqq))
+     do_something(rq->waker_bfqq);

Or, more generally, clear any stale pointers immediately after splitting/invalidating queues.

Fix Commit Reference

- block, bfq: fix waker_bfqq UAF after bfq_split_bfqq()
- LKML Patch Mail

Check your kernel version

uname -r

If you run Linux < 6.6 (with default config or BFQ enabled), you are likely affected.

Check if BFQ is active

cat /sys/block/sda/queue/scheduler

If you see bfq in brackets ([bfq]), it's the active scheduler.

Upgrade to Linux 6.6 or later, or apply latest security patches provided by your distro.

- If you can't upgrade, and don’t need BFQ, switch to another scheduler (like mq-deadline or none):

echo mq-deadline | sudo tee /sys/block/sda/queue/scheduler

Key References

- Official Patch & Commit Details
- syzkaller Kernel Fuzzer
- LKML Bug/Fix Discussion

Conclusion

CVE-2025-21631 highlights the ongoing importance of memory safety for critical kernel code. While this bug mostly threatens local, advanced attackers, it’s a high-value target for anyone seeking kernel escalation. Keep your kernels patched, and consider switching from BFQ if not needed.

Need more technical nitty-gritty or PoC help? See the links above or search for your distro’s security advisories.

Timeline

Published on: 01/19/2025 11:15:07 UTC
Last modified on: 02/10/2025 18:15:34 UTC