{"id":"CVE-2025-68285","title":"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 shortl…","summary":"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 shortl…","severity":"critical","cvss":9.8,"cvssVector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H","published":"2025-12-16","updated":"2026-10-14","sourceUpdated":"2026-10-14T13:10:00.187","source":"NVD","sourceUrl":"https://nvd.nist.gov/vuln/detail/CVE-2025-68285","references":[{"url":"https://git.kernel.org/stable/c/05ec43e9a9de67132dc8cd3b22afef001574947f","label":"416baaa9-dc9f-4396-8d5f-8c081fb06d67"},{"url":"https://git.kernel.org/stable/c/076381c261374c587700b3accf410bdd2dba334e","label":"416baaa9-dc9f-4396-8d5f-8c081fb06d67"},{"url":"https://git.kernel.org/stable/c/183ad6e3b651e8fb0b66d6a2678f4b80bfbba092","label":"416baaa9-dc9f-4396-8d5f-8c081fb06d67"},{"url":"https://git.kernel.org/stable/c/3fc43120b22a3d4f1fbeff56a35ce2105b6a5683","label":"416baaa9-dc9f-4396-8d5f-8c081fb06d67"},{"url":"https://git.kernel.org/stable/c/7c8ccdc1714d9fabecd26e1be7db1771061acc6e","label":"416baaa9-dc9f-4396-8d5f-8c081fb06d67"},{"url":"https://git.kernel.org/stable/c/bb4910c5fd436701faf367e1b5476a5a6d2aff1c","label":"416baaa9-dc9f-4396-8d5f-8c081fb06d67"},{"url":"https://git.kernel.org/stable/c/e08021b3b56b2407f37b5fe47b654be80cc665fb","label":"416baaa9-dc9f-4396-8d5f-8c081fb06d67"}],"tags":["nvd"],"epss":0.00585,"epssPercentile":0.46508,"ingestedAt":"2026-10-14T13:30:58.475Z","slug":"CVE-2025-68285","body":"## Overview\n\nIn 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->monmap);\n    monc->monmap = monmap;\n\n    ceph_osdmap_destroy(osdc->osdmap);\n    osdc->osdmap = newmap;\n\nunder client->monc.mutex and client->osdc.lock respectively, but\nbecause neither is taken in have_mon_and_osd_map() it's possible for\nclient->monc.monmap->epoch and client->osdc.osdmap->epoch arms in\n\n    client->monc.monmap && client->monc.monmap->epoch &&\n        client->osdc.osdmap && client->osdc.osdmap->epoch;\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    <TASK>\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    </TASK>\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->monc.mutex and client->osdc.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->auth_err under client->monc.mutex to match\nhow it's set in finish_auth().\n\nmonmap_show() and osdmap_show() now take the respective lock before\naccessing the map as well.\n\n## Remediation\n\nRefer to the linked advisories for vendor-supplied fixes and affected version ranges.","depth":"midnight","depthScore":54,"depthScoreParts":{"impact":53.9,"likelihood":0.1,"exploitation":0,"ransomware":0},"changes":[]}