ghsa-gcpr-pgrp-45fp
Vulnerability from github
Published
2024-09-04 21:30
Modified
2024-09-06 18:31
Details

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: ? __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 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.

Show details on source website


{
  "affected": [],
  "aliases": [
    "CVE-2024-45000"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-476"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-09-04T20:15:08Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nfs/netfs/fscache_cookie: add missing \"n_accesses\" check\n\nThis fixes a NULL pointer dereference bug due to a data race which\nlooks like this:\n\n  BUG: kernel NULL pointer dereference, address: 0000000000000008\n  #PF: supervisor read access in kernel mode\n  #PF: error_code(0x0000) - not-present page\n  PGD 0 P4D 0\n  Oops: 0000 [#1] SMP PTI\n  CPU: 33 PID: 16573 Comm: kworker/u97:799 Not tainted 6.8.7-cm4all1-hp+ #43\n  Hardware name: HP ProLiant DL380 Gen9/ProLiant DL380 Gen9, BIOS P89 10/17/2018\n  Workqueue: events_unbound netfs_rreq_write_to_cache_work\n  RIP: 0010:cachefiles_prepare_write+0x30/0xa0\n  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 \u003c48\u003e 8b 45 08 4c 8b 38 74 45 49 8b 7f 50 e8 4e a9 b0 ff 48 8b 73 10\n  RSP: 0018:ffffb4e78113bde0 EFLAGS: 00010286\n  RAX: ffff976126be6d10 RBX: ffff97615cdb8438 RCX: 0000000000020000\n  RDX: ffff97605e6c4c68 RSI: ffff97605e6c4c60 RDI: ffff97615cdb8438\n  RBP: 0000000000000000 R08: 0000000000278333 R09: 0000000000000001\n  R10: ffff97605e6c4600 R11: 0000000000000001 R12: ffff97605e6c4c68\n  R13: 0000000000020000 R14: 0000000000000001 R15: ffff976064fe2c00\n  FS:  0000000000000000(0000) GS:ffff9776dfd40000(0000) knlGS:0000000000000000\n  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n  CR2: 0000000000000008 CR3: 000000005942c002 CR4: 00000000001706f0\n  Call Trace:\n   \u003cTASK\u003e\n   ? __die+0x1f/0x70\n   ? page_fault_oops+0x15d/0x440\n   ? search_module_extables+0xe/0x40\n   ? fixup_exception+0x22/0x2f0\n   ? exc_page_fault+0x5f/0x100\n   ? asm_exc_page_fault+0x22/0x30\n   ? cachefiles_prepare_write+0x30/0xa0\n   netfs_rreq_write_to_cache_work+0x135/0x2e0\n   process_one_work+0x137/0x2c0\n   worker_thread+0x2e9/0x400\n   ? __pfx_worker_thread+0x10/0x10\n   kthread+0xcc/0x100\n   ? __pfx_kthread+0x10/0x10\n   ret_from_fork+0x30/0x50\n   ? __pfx_kthread+0x10/0x10\n   ret_from_fork_asm+0x1b/0x30\n   \u003c/TASK\u003e\n  Modules linked in:\n  CR2: 0000000000000008\n  ---[ end trace 0000000000000000 ]---\n\nThis happened because fscache_cookie_state_machine() was slow and was\nstill running while another process invoked fscache_unuse_cookie();\nthis led to a fscache_cookie_lru_do_one() call, setting the\nFSCACHE_COOKIE_DO_LRU_DISCARD flag, which was picked up by\nfscache_cookie_state_machine(), withdrawing the cookie via\ncachefiles_withdraw_cookie(), clearing cookie-\u003ecache_priv.\n\nAt the same time, yet another process invoked\ncachefiles_prepare_write(), which found a NULL pointer in this code\nline:\n\n  struct cachefiles_object *object = cachefiles_cres_object(cres);\n\nThe next line crashes, obviously:\n\n  struct cachefiles_cache *cache = object-\u003evolume-\u003ecache;\n\nDuring cachefiles_prepare_write(), the \"n_accesses\" counter is\nnon-zero (via fscache_begin_operation()).  The cookie must not be\nwithdrawn until it drops to zero.\n\nThe counter is checked by fscache_cookie_state_machine() before\nswitching to FSCACHE_COOKIE_STATE_RELINQUISHING and\nFSCACHE_COOKIE_STATE_WITHDRAWING (in \"case\nFSCACHE_COOKIE_STATE_FAILED\"), but not for\nFSCACHE_COOKIE_STATE_LRU_DISCARDING (\"case\nFSCACHE_COOKIE_STATE_ACTIVE\").\n\nThis patch adds the missing check.  With a non-zero access counter,\nthe function returns and the next fscache_end_cookie_access() call\nwill queue another fscache_cookie_state_machine() call to handle the\nstill-pending FSCACHE_COOKIE_DO_LRU_DISCARD.",
  "id": "GHSA-gcpr-pgrp-45fp",
  "modified": "2024-09-06T18:31:29Z",
  "published": "2024-09-04T21:30:32Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-45000"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/0a4d41fa14b2a0efd40e350cfe8ec6a4c998ac1d"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/b8a50877f68efdcc0be3fcc5116e00c31b90e45b"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/dfaa39b05a6cf34a16c525a2759ee6ab26b5fef6"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/f71aa06398aabc2e3eaac25acdf3d62e0094ba70"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

Sightings

Author Source Type Date

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
  • Confirmed: The vulnerability is confirmed from an analyst perspective.
  • Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
  • Patched: This vulnerability was successfully patched by the user reporting the sighting.
  • Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
  • Not confirmed: The user expresses doubt about the veracity of the vulnerability.
  • Not patched: This vulnerability was not successfully patched by the user reporting the sighting.