GHSA-V24J-9GHX-7RF2

Vulnerability from github – Published: 2025-12-16 18:31 – Updated: 2025-12-16 18:31
VLAI?
Details

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

libceph: fix potential use-after-free in have_mon_and_osd_map()

The wait loop in __ceph_open_session() can race with the client receiving a new monmap or osdmap shortly after the initial map is received. Both ceph_monc_handle_map() and handle_one_map() install a new map immediately after freeing the old one

kfree(monc->monmap);
monc->monmap = monmap;

ceph_osdmap_destroy(osdc->osdmap);
osdc->osdmap = newmap;

under client->monc.mutex and client->osdc.lock respectively, but because neither is taken in have_mon_and_osd_map() it's possible for client->monc.monmap->epoch and client->osdc.osdmap->epoch arms in

client->monc.monmap && client->monc.monmap->epoch &&
    client->osdc.osdmap && client->osdc.osdmap->epoch;

condition to dereference an already freed map. This happens to be reproducible with generic/395 and generic/397 with KASAN enabled:

BUG: KASAN: slab-use-after-free in have_mon_and_osd_map+0x56/0x70
Read of size 4 at addr ffff88811012d810 by task mount.ceph/13305
CPU: 2 UID: 0 PID: 13305 Comm: mount.ceph Not tainted 6.14.0-rc2-build2+ #1266
...
Call Trace:
<TASK>
have_mon_and_osd_map+0x56/0x70
ceph_open_session+0x182/0x290
ceph_get_tree+0x333/0x680
vfs_get_tree+0x49/0x180
do_new_mount+0x1a3/0x2d0
path_mount+0x6dd/0x730
do_mount+0x99/0xe0
__do_sys_mount+0x141/0x180
do_syscall_64+0x9f/0x100
entry_SYSCALL_64_after_hwframe+0x76/0x7e
</TASK>

Allocated by task 13305:
ceph_osdmap_alloc+0x16/0x130
ceph_osdc_init+0x27a/0x4c0
ceph_create_client+0x153/0x190
create_fs_client+0x50/0x2a0
ceph_get_tree+0xff/0x680
vfs_get_tree+0x49/0x180
do_new_mount+0x1a3/0x2d0
path_mount+0x6dd/0x730
do_mount+0x99/0xe0
__do_sys_mount+0x141/0x180
do_syscall_64+0x9f/0x100
entry_SYSCALL_64_after_hwframe+0x76/0x7e

Freed by task 9475:
kfree+0x212/0x290
handle_one_map+0x23c/0x3b0
ceph_osdc_handle_map+0x3c9/0x590
mon_dispatch+0x655/0x6f0
ceph_con_process_message+0xc3/0xe0
ceph_con_v1_try_read+0x614/0x760
ceph_con_workfn+0x2de/0x650
process_one_work+0x486/0x7c0
process_scheduled_works+0x73/0x90
worker_thread+0x1c8/0x2a0
kthread+0x2ec/0x300
ret_from_fork+0x24/0x40
ret_from_fork_asm+0x1a/0x30

Rewrite the wait loop to check the above condition directly with client->monc.mutex and client->osdc.lock taken as appropriate. While at it, improve the timeout handling (previously mount_timeout could be exceeded in case wait_event_interruptible_timeout() slept more than once) and access client->auth_err under client->monc.mutex to match how it's set in finish_auth().

monmap_show() and osdmap_show() now take the respective lock before accessing the map as well.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-68285"
  ],
  "database_specific": {
    "cwe_ids": [],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-12-16T16:16:07Z",
    "severity": null
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nlibceph: fix potential use-after-free in have_mon_and_osd_map()\n\nThe wait loop in __ceph_open_session() can race with the client\nreceiving a new monmap or osdmap shortly after the initial map is\nreceived.  Both ceph_monc_handle_map() and handle_one_map() install\na new map immediately after freeing the old one\n\n    kfree(monc-\u003emonmap);\n    monc-\u003emonmap = monmap;\n\n    ceph_osdmap_destroy(osdc-\u003eosdmap);\n    osdc-\u003eosdmap = newmap;\n\nunder client-\u003emonc.mutex and client-\u003eosdc.lock respectively, but\nbecause neither is taken in have_mon_and_osd_map() it\u0027s possible for\nclient-\u003emonc.monmap-\u003eepoch and client-\u003eosdc.osdmap-\u003eepoch arms in\n\n    client-\u003emonc.monmap \u0026\u0026 client-\u003emonc.monmap-\u003eepoch \u0026\u0026\n        client-\u003eosdc.osdmap \u0026\u0026 client-\u003eosdc.osdmap-\u003eepoch;\n\ncondition to dereference an already freed map.  This happens to be\nreproducible with generic/395 and generic/397 with KASAN enabled:\n\n    BUG: KASAN: slab-use-after-free in have_mon_and_osd_map+0x56/0x70\n    Read of size 4 at addr ffff88811012d810 by task mount.ceph/13305\n    CPU: 2 UID: 0 PID: 13305 Comm: mount.ceph Not tainted 6.14.0-rc2-build2+ #1266\n    ...\n    Call Trace:\n    \u003cTASK\u003e\n    have_mon_and_osd_map+0x56/0x70\n    ceph_open_session+0x182/0x290\n    ceph_get_tree+0x333/0x680\n    vfs_get_tree+0x49/0x180\n    do_new_mount+0x1a3/0x2d0\n    path_mount+0x6dd/0x730\n    do_mount+0x99/0xe0\n    __do_sys_mount+0x141/0x180\n    do_syscall_64+0x9f/0x100\n    entry_SYSCALL_64_after_hwframe+0x76/0x7e\n    \u003c/TASK\u003e\n\n    Allocated by task 13305:\n    ceph_osdmap_alloc+0x16/0x130\n    ceph_osdc_init+0x27a/0x4c0\n    ceph_create_client+0x153/0x190\n    create_fs_client+0x50/0x2a0\n    ceph_get_tree+0xff/0x680\n    vfs_get_tree+0x49/0x180\n    do_new_mount+0x1a3/0x2d0\n    path_mount+0x6dd/0x730\n    do_mount+0x99/0xe0\n    __do_sys_mount+0x141/0x180\n    do_syscall_64+0x9f/0x100\n    entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\n    Freed by task 9475:\n    kfree+0x212/0x290\n    handle_one_map+0x23c/0x3b0\n    ceph_osdc_handle_map+0x3c9/0x590\n    mon_dispatch+0x655/0x6f0\n    ceph_con_process_message+0xc3/0xe0\n    ceph_con_v1_try_read+0x614/0x760\n    ceph_con_workfn+0x2de/0x650\n    process_one_work+0x486/0x7c0\n    process_scheduled_works+0x73/0x90\n    worker_thread+0x1c8/0x2a0\n    kthread+0x2ec/0x300\n    ret_from_fork+0x24/0x40\n    ret_from_fork_asm+0x1a/0x30\n\nRewrite the wait loop to check the above condition directly with\nclient-\u003emonc.mutex and client-\u003eosdc.lock taken as appropriate.  While\nat it, improve the timeout handling (previously mount_timeout could be\nexceeded in case wait_event_interruptible_timeout() slept more than\nonce) and access client-\u003eauth_err under client-\u003emonc.mutex to match\nhow it\u0027s set in finish_auth().\n\nmonmap_show() and osdmap_show() now take the respective lock before\naccessing the map as well.",
  "id": "GHSA-v24j-9ghx-7rf2",
  "modified": "2025-12-16T18:31:33Z",
  "published": "2025-12-16T18:31:33Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68285"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/05ec43e9a9de67132dc8cd3b22afef001574947f"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/076381c261374c587700b3accf410bdd2dba334e"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/183ad6e3b651e8fb0b66d6a2678f4b80bfbba092"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/3fc43120b22a3d4f1fbeff56a35ce2105b6a5683"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/7c8ccdc1714d9fabecd26e1be7db1771061acc6e"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/bb4910c5fd436701faf367e1b5476a5a6d2aff1c"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/e08021b3b56b2407f37b5fe47b654be80cc665fb"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}


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 observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.


Loading…

Detection rules are retrieved from Rulezet.

Loading…

Loading…