# CVE-2024-45000: fs/netfs/fscache_cookie: add missing "n_accesses" check

> A race condition in the Linux kernel's fscache module causes a NULL pointer dereference, leading to a system crash.

- **Severity:** High 7.8 (`CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H`)
- **Exploited in the wild:** Not known
- **Login needed:** Any signed-in user
- **Attackable:** Local or same network only
- **Victim action needed:** Not needed
- **Fix available:** Yes
- **Published:** 4 Sep 2024
- **Updated:** 5 Aug 2026
- **Also known as:** AZL-48700, BELL-CVE-2024-45000, DEBIAN-CVE-2024-45000, GHSA-gcpr-pgrp-45fp, UBUNTU-CVE-2024-45000

## What is CVE-2024-45000?

CVE-2024-45000 is a high-severity vulnerability in Linux kernel, published on 4 Sep 2024. It can only be exploited from the same machine or local network, with no action from the victim.

### Official description

In the Linux kernel, the following vulnerability has been resolved:

fs/netfs/fscache_cookie: add missing "n_accesses" check

This fixes a NULL pointer dereference bug due to a data race which
looks like this:

  BUG: kernel NULL pointer dereference, address: 0000000000000008
  #PF: supervisor read access in kernel mode
  #PF: error_code(0x0000) - not-present page
  PGD 0 P4D 0
  Oops: 0000 [#1] SMP PTI
  CPU: 33 PID: 16573 Comm: kworker/u97:799 Not tainted 6.8.7-cm4all1-hp+ #43
  Hardware name: HP ProLiant DL380 Gen9/ProLiant DL380 Gen9, BIOS P89 10/17/2018
  Workqueue: events_unbound netfs_rreq_write_to_cache_work
  RIP: 0010:cachefiles_prepare_write+0x30/0xa0
  Code: 57 41 56 45 89 ce 41 55 49 89 cd 41 54 49 89 d4 55 53 48 89 fb 48 83 ec 08 48 8b 47 08 48 83 7f 10 00 48 89 34 24 48 8b 68 20 <48> 8b 45 08 4c 8b 38 74 45 49 8b 7f 50 e8 4e a9 b0 ff 48 8b 73 10
  RSP: 0018:ffffb4e78113bde0 EFLAGS: 00010286
  RAX: ffff976126be6d10 RBX: ffff97615cdb8438 RCX: 0000000000020000
  RDX: ffff97605e6c4c68 RSI: ffff97605e6c4c60 RDI: ffff97615cdb8438
  RBP: 0000000000000000 R08: 0000000000278333 R09: 0000000000000001
  R10: ffff97605e6c4600 R11: 0000000000000001 R12: ffff97605e6c4c68
  R13: 0000000000020000 R14: 0000000000000001 R15: ffff976064fe2c00
  FS:  0000000000000000(0000) GS:ffff9776dfd40000(0000) knlGS:0000000000000000
  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
  CR2: 0000000000000008 CR3: 000000005942c002 CR4: 00000000001706f0
  Call Trace:
   <TASK>
   ? __die+0x1f/0x70
   ? page_fault_oops+0x15d/0x440
   ? search_module_extables+0xe/0x40
   ? fixup_exception+0x22/0x2f0
   ? exc_page_fault+0x5f/0x100
   ? asm_exc_page_fault+0x22/0x30
   ? cachefiles_prepare_write+0x30/0xa0
   netfs_rreq_write_to_cache_work+0x135/0x2e0
   process_one_work+0x137/0x2c0
   worker_thread+0x2e9/0x400
   ? __pfx_worker_thread+0x10/0x10
   kthread+0xcc/0x100
   ? __pfx_kthread+0x10/0x10
   ret_from_fork+0x30/0x50
   ? __pfx_kthread+0x10/0x10
   ret_from_fork_asm+0x1b/0x30
   </TASK>
  Modules linked in:
  CR2: 0000000000000008
  ---[ end trace 0000000000000000 ]---

This happened because fscache_cookie_state_machine() was slow and was
still running while another process invoked fscache_unuse_cookie();
this led to a fscache_cookie_lru_do_one() call, setting the
FSCACHE_COOKIE_DO_LRU_DISCARD flag, which was picked up by
fscache_cookie_state_machine(), withdrawing the cookie via
cachefiles_withdraw_cookie(), clearing cookie->cache_priv.

At the same time, yet another process invoked
cachefiles_prepare_write(), which found a NULL pointer in this code
line:

  struct cachefiles_object *object = cachefiles_cres_object(cres);

The next line crashes, obviously:

  struct cachefiles_cache *cache = object->volume->cache;

During cachefiles_prepare_write(), the "n_accesses" counter is
non-zero (via fscache_begin_operation()).  The cookie must not be
withdrawn until it drops to zero.

The counter is checked by fscache_cookie_state_machine() before
switching to FSCACHE_COOKIE_STATE_RELINQUISHING and
FSCACHE_COOKIE_STATE_WITHDRAWING (in "case
FSCACHE_COOKIE_STATE_FAILED"), but not for
FSCACHE_COOKIE_STATE_LRU_DISCARDING ("case
FSCACHE_COOKIE_STATE_ACTIVE").

This patch adds the missing check.  With a non-zero access counter,
the function returns and the next fscache_end_cookie_access() call
will queue another fscache_cookie_state_machine() call to handle the
still-pending FSCACHE_COOKIE_DO_LRU_DISCARD.

Weakness: CWE-476 (NULL Pointer Dereference)

## Which versions are affected by CVE-2024-45000?

It affects 1 product.


Products: Linux kernel.

## How do I fix CVE-2024-45000?

Apply the vendor's patch.

## Is CVE-2024-45000 being exploited?

There is no known exploitation of CVE-2024-45000 in the wild and no public exploit code.

## Other vulnerabilities in Linux kernel

- [CVE-2026-53266](https://insights.sbomify.com/CVE-2026-53266/): Linux Kernel Out-of-Bounds Write (high 8.8, exploited in the wild)
- [CVE-2013-6282](https://insights.sbomify.com/CVE-2013-6282/): Linux Kernel Improper Input Validation (high 8.8, exploited in the wild)
- [CVE-2022-0185](https://insights.sbomify.com/CVE-2022-0185/): Linux Kernel Heap-Based Buffer Overflow (high 8.4, exploited in the wild)
- [CVE-2013-2094](https://insights.sbomify.com/CVE-2013-2094/): Linux Kernel Privilege Escalation (high 8.4, exploited in the wild)
- [CVE-2026-53362](https://insights.sbomify.com/CVE-2026-53362/): Linux Kernel Unspecified (high 7.8, exploited in the wild)

## Fix prompt for AI coding agents

```text
Check this codebase for CVE-2024-45000 and fix it if it is affected.

What it is: CVE-2024-45000 is a high-severity vulnerability in Linux kernel, published on 4 Sep 2024. It can only be exploited from the same machine or local network, with no action from the victim.
Exploitation: There is no known exploitation of CVE-2024-45000 in the wild and no public exploit code.

Affected product: Linux kernel. No package-level version data is available, so check the vendor advisory linked from the reference page.

Task:
1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies.
2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it.
3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.
4. Run the tests and summarise what changed and why.
5. If nothing in the project is affected, say so and change nothing.

Reference: https://insights.sbomify.com/CVE-2024-45000/ (Markdown: https://insights.sbomify.com/CVE-2024-45000/index.md)
```

## Sources

- CVE record: https://www.cve.org/CVERecord?id=CVE-2024-45000
- NVD: https://nvd.nist.gov/vuln/detail/CVE-2024-45000
- OSV: https://osv.dev/vulnerability/CVE-2024-45000

---
From sbomify Insights: https://insights.sbomify.com/CVE-2024-45000/
Summaries are generated and may contain mistakes; the official description above is the record.