Skip to main content

Linux Kernel CVE-2025-68285

CRITICAL
2025-12-16 416baaa9-dc9f-4396-8d5f-8c081fb06d67
Critical
Disputed · 9.8 Vendor: 416baaa9-dc9f-4396-8d5f-8c081fb06d67
Share

Severity by source

Sources disagree (Medium–Critical)
Vendor (416baaa9-dc9f-4396-8d5f-8c081fb06d67) PRIMARY
9.8 CRITICAL
AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
vuln.today AI
3.6 LOW

Local mount path (AV:L), narrow timing race (AC:H), requires privilege to mount Ceph (PR:L); impact is a small freed-memory read (C:L) and possible client crash (A:L), no integrity impact.

3.1 AV:L/AC:H/PR:L/UI:N/S:U/C:L/I:N/A:L
4.0 AV:L/AC:H/AT:P/PR:L/UI:N/VC:L/VI:N/VA:L/SC:N/SI:N/SA:N
SUSE
7.0 HIGH
AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
Red Hat
7.0 MEDIUM
qualitative

vuln.today treats the vendor’s rating as authoritative. A higher third-party CVSS (e.g. CISA-ADP) is shown for transparency but does not drive the headline severity.

CVSS VectorVendor: 416baaa9-dc9f-4396-8d5f-8c081fb06d67

Attack Vector
Network
Attack Complexity
Low
Privileges Required
None
User Interaction
None
Scope
Unchanged
Confidentiality
High
Integrity
High
Availability
High

Lifecycle Timeline

2
Analysis Generated
Jul 30, 2026 - 07:14 vuln.today
CVE Published
Dec 16, 2025 - 16:16 cve.org
CRITICAL 9.8

DescriptionCVE.org

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.

AnalysisAI

Use-after-free in the Linux kernel's libceph client (the in-kernel Ceph transport shared by CephFS and RBD) lets the mount-time wait loop in __ceph_open_session() read a monmap or osdmap structure after a worker thread has freed and replaced it. The flaw is a race between a mounting task polling have_mon_and_osd_map() without locks and ceph_monc_handle_map()/handle_one_map() swapping in a fresh map under their respective locks, producing a KASAN slab-use-after-free (reproducible with xfstests generic/395 and generic/397). There is no public exploit identified at time of analysis and it is not in CISA KEV; EPSS is very low at 0.18% (8th percentile).

Technical ContextAI

libceph is the kernel-side Ceph messenger/client library that maintains cluster maps: the monmap (monitor map, guarded by client->monc.mutex) and the osdmap (OSD map, guarded by client->osdc.lock). Both ceph_monc_handle_map() and handle_one_map() install a replacement map immediately after freeing the old one (kfree(monc->monmap); monc->monmap = monmap; and ceph_osdmap_destroy(osdc->osdmap); osdc->osdmap = newmap;). The condition in have_mon_and_osd_map() dereferences client->monc.monmap->epoch and client->osdc.osdmap->epoch without acquiring either lock, so a concurrent map update can free the object between the pointer check and the epoch read. Root cause is a classic time-of-check/use race producing a use-after-free (CWE-416, closely related to CWE-362 concurrent access without proper synchronization). CWE was reported as N/A by the source. The fix rewrites the wait loop to evaluate the condition under monc.mutex and osdc.lock, hardens mount_timeout handling against multiple sleeps in wait_event_interruptible_timeout(), reads client->auth_err under monc.mutex, and makes monmap_show()/osdmap_show() take the locks too.

Affected ProductsAI

The affected product is the Linux kernel's libceph subsystem (used by CephFS and Ceph RBD clients); the crash trace is from kernel 6.14.0-rc2. No CPE strings were provided in the input, so exact affected version ranges are not enumerated by NVD here. The fix is distributed across seven stable-branch commits at git.kernel.org (05ec43e9a9de..., 076381c26137..., 183ad6e3b651..., 3fc43120b22a..., 7c8ccdc1714d..., bb4910c5fd43..., e08021b3b56b...), indicating backports to multiple maintained stable series; consult each kernel stable tree and your distribution's advisory to map these commits to a released kernel package version.

RemediationAI

Upstream fix available (commit/stable backports); a released patched version is not independently confirmed from the provided data - apply the fix by updating to a kernel build that includes the libceph change referenced by the seven git.kernel.org/stable commits (e.g. 05ec43e9a9de67132dc8cd3b22afef001574947f and its sibling backports) via your distribution's kernel update channel. Because this is a mount-time race with no attacker-controlled network trigger, an effective compensating control until patched is to restrict who can mount Ceph filesystems: limit CAP_SYS_ADMIN / mount privileges and avoid untrusted local users invoking mount.ceph, which removes the ability to drive the racing mount path at the cost of tightening operational mounting workflows. There is no feature toggle for the race itself, so hosts that do not use CephFS/RBD are unaffected and need no action beyond normal kernel patching. Track your distribution advisory for the exact fixed package version rather than relying on the raw commit hashes.

Vendor StatusVendor

SUSE

Severity: Important
Product Status
Container suse/sl-micro/6.0/baremetal-os-container:latest Affected
Container suse/sl-micro/6.0/base-os-container:2.1.3-7.95 Affected
Container suse/sl-micro/6.0/kvm-os-container:2.1.3-6.115 Affected
Container suse/sl-micro/6.0/rt-os-container:2.1.3-7.146 Affected
Container suse/sl-micro/6.0/toolbox:latest Affected

Share

CVE-2025-68285 vulnerability details – vuln.today

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy