FlawAtlas
Search the atlas
CVE-2025-68285 Not scored

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

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.

Exploit probability 0.2%
Published December 16, 2025
Required by Not available
Last source change July 15, 2026

02 / AFFECTED SOFTWARE

Affected packages

Linux Kernel
Unknown Unknown

03 / CONNECTIONS

Connected vulnerabilities

related ALSA-2026:0443
related ALSA-2026:0444
related ALSA-2026:0786
related ALSA-2026:0793
related OPENSUSE-SU-2026:20145-1
related SUSE-SU-2026:0411-1
related SUSE-SU-2026:0447-1
related SUSE-SU-2026:0471-1
related SUSE-SU-2026:0472-1
related SUSE-SU-2026:0474-1
related SUSE-SU-2026:0496-1
related SUSE-SU-2026:0587-1
related SUSE-SU-2026:0617-1
related SUSE-SU-2026:0928-1
related SUSE-SU-2026:0939-1
related SUSE-SU-2026:0940-1
related SUSE-SU-2026:0941-1
related SUSE-SU-2026:0943-1
related SUSE-SU-2026:0944-1
related SUSE-SU-2026:0945-1
related SUSE-SU-2026:0946-1
related SUSE-SU-2026:0951-1
related SUSE-SU-2026:0953-1
related SUSE-SU-2026:0954-1
related SUSE-SU-2026:0958-1
related SUSE-SU-2026:0961-1
related SUSE-SU-2026:0964-1
related SUSE-SU-2026:0967-1
related SUSE-SU-2026:0970-1
related SUSE-SU-2026:0983-1
related SUSE-SU-2026:0985-1
related SUSE-SU-2026:0992-1
related SUSE-SU-2026:0997-1
related SUSE-SU-2026:1000-1
related SUSE-SU-2026:1002-1
related SUSE-SU-2026:1039-1
related SUSE-SU-2026:1044-1
related SUSE-SU-2026:1045-1
related SUSE-SU-2026:1046-1
related SUSE-SU-2026:1048-1
related SUSE-SU-2026:1049-1
related SUSE-SU-2026:1059-1
related SUSE-SU-2026:1073-1
related SUSE-SU-2026:1078-1
related SUSE-SU-2026:1083-1
related SUSE-SU-2026:1088-1
related SUSE-SU-2026:1089-1
related SUSE-SU-2026:1096-1
related SUSE-SU-2026:1099-1
related SUSE-SU-2026:1100-1
related SUSE-SU-2026:1101-1
related SUSE-SU-2026:1102-1
related SUSE-SU-2026:1125-1
related SUSE-SU-2026:1132-1
related SUSE-SU-2026:1136-1
related SUSE-SU-2026:20207-1
related SUSE-SU-2026:20220-1
related SUSE-SU-2026:20228-1
related SUSE-SU-2026:20477-1
related SUSE-SU-2026:20498-1
related SUSE-SU-2026:20828-1
related SUSE-SU-2026:20829-1
related SUSE-SU-2026:20831-1
related SUSE-SU-2026:20832-1
related SUSE-SU-2026:20837-1
related SUSE-SU-2026:20840-1
related SUSE-SU-2026:20841-1
related SUSE-SU-2026:20842-1
related SUSE-SU-2026:20845-1
related SUSE-SU-2026:20853-1
related SUSE-SU-2026:20854-1
related SUSE-SU-2026:20855-1
related SUSE-SU-2026:20856-1
related SUSE-SU-2026:20862-1
related SUSE-SU-2026:20863-1
related SUSE-SU-2026:20864-1
related SUSE-SU-2026:20865-1
related SUSE-SU-2026:20866-1
related SUSE-SU-2026:20876-1
related SUSE-SU-2026:20885-1
related SUSE-SU-2026:20886-1
related SUSE-SU-2026:20887-1
related SUSE-SU-2026:20888-1
related SUSE-SU-2026:20889-1
related SUSE-SU-2026:20897-1
related SUSE-SU-2026:20898-1
related SUSE-SU-2026:20899-1
related SUSE-SU-2026:20900-1
related SUSE-SU-2026:20944-1
related SUSE-SU-2026:20945-1
related SUSE-SU-2026:20946-1
related SUSE-SU-2026:20947-1

04 / EVIDENCE

Source records

Open Source Vulnerabilities CVE-2025-68285

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.

View original source

05 / REFERENCES

Further evidence