On March 2024, a vulnerability, CVE-2024-26878, was identified and fixed in the Linux kernel affecting the quota management subsystem. This bug could lead to a NULL pointer dereference, resulting in kernel crashes (OOPS) or a possible local denial of service. While this bug is subtle and requires specific timing, it’s a perfect example of why concurrency in kernel code is so hard to get right. This post will explain, in simple terms, exactly how this race condition happens, what code is vulnerable, and how it was fixed.

What’s The Vulnerability About?

The Linux kernel allows per-user and per-group quotas on filesystems. To manage quotas, the kernel uses structures attached to in-memory representations of files (inodes). Sometimes two threads can try to access and change these quota pointers at the same time. If things happen in the wrong order, one thread can end up using a quota pointer just after another thread sets it to NULL.

This bug was reported and fixed here.

Here’s the sequence

| P1 (dquot_free_inode) | P2 (quota_off, drop_dquot_ref) |
|-------------------------------|----------------------------------|
| dquots = i_dquot(inode) | |
| | dquots = i_dquot(inode) |
| | ... |
| srcu_read_lock() | |
| dquots[cnt] != NULL (1) | |
| | dquots[type] = NULL (2) |
| ... | ... |
| spin_lock(&dquots[cnt]->dq_dqb_lock); (3) | |

At (3): P1 tries to use the pointer—oops, it’s now NULL. The kernel crashes.

In short: If one part of the kernel checks a pointer and, before it uses it, another part sets it to NULL, you can end up dereferencing a NULL pointer. In the kernel, this is a serious problem.

Here is a simplified example based on the vulnerable pattern prior to the fix

struct dquot **dquots = i_dquot(inode);

if (dquots[cnt] != NULL)
    spin_lock(&dquots[cnt]->dq_dqb_lock);
    // If P2 sets dquots[cnt] to NULL between these lines, boom!

Exploitability

Who can exploit this?
- Any unprivileged local user with the ability to force quotas on and off and manipulate files on a quota-enabled filesystem could, in theory, exploit this bug for a denial of service (crash the system).

Exploit reliability is low since it depends on exact timing.

What’s the risk?

Not a privilege escalation, but a local crash and denial-of-service is possible.

- Some containerized environments using quotas could be especially exposed if containers can trigger quota changes.

The Official Fix

To fix the race, the kernel now makes a temporary pointer copy _after_ confirming the pointer is not NULL, protecting its use from being altered by other threads until after it's done.

Fixed Code Example

struct dquot *dquot;

if ((dquot = dquots[cnt]) != NULL)
    spin_lock(&dquot->dq_dqb_lock);
    // Use 'dquot' safely

Why does this work?
- By copying the pointer to a local variable, you guarantee that even if another thread changes the original pointer, you still have a valid reference to the structure. (Other concurrency checks apply, but this is a safe pattern.)

Official Patch Reference:
- Linux Kernel Patch Commit: a6a5dcd22f9a4f37daf7b7b315e6efebe6b1bc97

Are you affected?

- If you are running a Linux kernel version prior to the patch and using quota-enabled filesystems, you could be at risk.

How to fix:

- Upgrade your Linux kernel to a version including the patch, or apply the backport if your vendor supplies one.

Additional Reading & References

- Original Kernel Mailing List Report
- Upstream Patch
- CVE Entry on NVD (updates may be pending)

Conclusion

CVE-2024-26878 highlights that even old, well-known subsystems like quotas can have subtle concurrency problems. Thanks to careful code auditing and community vigilance, these bugs continue to be found and patched—protecting everyone who relies on Linux.

Key takeaway: If you run quota-enabled filesystems, update your kernel regularly and follow upstream mailing lists for vulnerability news.

Stay safe, and keep your systems patched!

If you found this article helpful, share it with your team or on your favorite Linux community forum. For more deep dives like this, stay tuned!

Timeline

Published on: 04/17/2024 11:15:09 UTC
Last modified on: 01/14/2025 14:49:44 UTC