CVE-2025-68285: Linux Kernel Ceph Libceph Use-After-Free Fix

The Linux kernel has a newly recorded vulnerability — CVE-2025-68285 — that fixes a potential use-after-free in the Ceph client library (libceph) function have_mon_and_osd_map, closing a race that can let the kernel dereference already-freed map objects during Ceph session open.

Background​

Ceph is a widely used distributed storage system and the kernel’s libceph component contains client-side logic for talking to Ceph monitor (mon) and object storage daemon (OSD) maps. These maps — monmap and osdmap — are fundamental runtime structures describing cluster topology and OSD membership. The kernel exposes a Ceph client implementation that interacts with these maps during session setup and mount operations.
The vulnerability arises when the wait loop inside __ceph_open_session races with asynchronous map updates: code paths that install a newly received map free the old map then set the new pointer without holding the same locks that the wait-check function uses. Because have_mon_and_osd_map checks epoch fields on both maps without taking those protecting locks, it can read fields from an object another thread has just freed — a classic use-after-free scenario. This race was confirmed reproducible under KASAN (KernelAddress SANitizer) test runs.

---

Technical overview: what went wrong​

The actors and the race window​

• monmap and osdmap — kernel-side structures representing the monitor map and OSD map respectively.
• ceph_monc_handle_map and handle_one_map — code paths that process incoming map updates and install new map objects.
• __ceph_open_session and have_mon_and_osd_map — session open logic that waits until both a monmap and an osdmap are present and checks their epochs to decide when to proceed.
• Locking: the map installers use per-structure locks (for example, client->monc.mutex and client->osdc.lock) to protect replacement, while the wait loop reads map pointers and their epoch fields without taking those locks.

Because the installers free the old map (kfree(monc->monmap); monc->monmap = monmap or destroy the old osdmap (ceph_osdmap_destroy(osdc->osdmap); osdc->osdmap = newmap under their respective locks, a concurrent waiter that checks pointer validity and epoch values while not holding the same locks may observe a pointer in the act of being replaced and end up dereferencing freed memory. Under KASAN this surfaced as a slab-use-after-free trace originating at have_mon_and_osd_map.

Reproducibility and test evidence​

Test harnesses that exercise kernel mounts and Ceph interactions (notably generic/395 and generic/397 when run with KASAN enabled) reproduced the problem reliably, producing a KASAN slab-use-after-free trace. The reproducibility under KASAN provides strong diagnostic evidence — the issue is not purely theoretical timing noise but a real window where a freed map pointer can be accessed. Multiple vulnerability trackers and distro advisories referenced the same symptom and the upstream patching rationale.

---

Severity, exploitability, and practical impact​

CVSS and vendor severity​

Early vendor mappings rate the issue in the moderate-to-high range: Amazon’s ALAS listing reported a CVSSv3 base score mapping consistent with an Important classification for Amazon Linux image types, while other trackers mark the issue with medium-to-high practical impact depending on local threat models. These numeric scores reflect the fact the attack vector is local (an attacker needs local or host-adjacent capability) but the impact can be severe: kernel memory corruption leading to oopses, panics, or instability.

What an attacker can realistically achieve​

• Primary impact: availability — unexpected kernel oopses or panics resulting in service interruption, host reboots, or filesystem failures.
• Escalation potential: theoretical. Use-after-free in kernel space can be a valuable primitive for skilled exploit developers if other conditions (allocator behavior, heap grooming, predictable addresses) align, but no public proof-of-concept showing reliable privilege escalation was reported at the time advisories were published. The absence of public exploitation reports is not evidence the bug is benign; rather it is typical for kernel concurrency bugs that can be weaponized only with additional efforts.

Attack surface and who should worry most​

Systems where Ceph client code runs in privileged contexts are the primary concern:

• Kernel-based Ceph mounts on servers, NFS/SMB gateways that mount CephFS, or appliances exposing Ceph-backed filesystems.
• Multi-tenant environments (cloud VMs, containers, virtualization hosts) where untrusted or guest-controlled workloads might trigger Ceph mount/session flows.
• Test and CI systems that run KASAN or deliberately stress Ceph interactions — these environments may reproduce the issue more easily but are also useful for verification.

Desktops that do not mount Ceph filesystems or kernel builds without libceph are not affected in practice. Distributions and vendor kernels that include the upstream fix are considered remediated.

---

Patch and remediation status​

Upstream fix​

Kernel maintainers addressed the race by removing the unsafe dereference window: the fix ensures consistent locking or atomic snapshotting of the relevant pointers/fields before the wait loop checks epoch values (the exact patch implements the necessary locking discipline or adds safe reference handling to avoid dereferencing freed maps). The upstream commit was merged into the kernel trees and referenced in the canonical CVE and OSV entries.

Distribution and vendor advisories​

Multiple distributors have mapped the CVE into their security trackers and package advisories:

• Ubuntu lists CVE-2025-68285 with a priority indicator and referenced the same technical description of the race and KASAN reproducibility. Operators using Ubuntu kernels should follow the vendor update notices to find the patched kernel builds.
• Debian/OSV and other trackers imported the NVD/Upstream data and are preparing vendor-level backports.
• Amazon ALAS cataloged the issue for Amazon Linux images and labeled it Important, mapping affected kernel packages with pending fixes where applicable.

Note: vendor timelines and package names differ. Some vendors required backporting the patch into their stable kernel branches; others issued new kernel builds. Always consult your distribution’s advisory for the exact package version that includes the fix.

---

Practical remediation steps (what administrators should do now)​

• Inventory
• Identify all systems that mount CephFS or otherwise load the kernel libceph components.
• Confirm kernel builds: uname -r plus distribution package listing, and map to vendor advisories to see whether the installed build includes the upstream commit.
• Patch
• For distribution-managed kernels: install the vendor-supplied kernel security update that references CVE‑2025‑68285 or lists the upstream stable commit in its changelog.
• For custom or embedded kernels: merge the upstream stable commit(s) that implement the fix, rebuild, and deploy following your kernel rollout procedures.
• Reboot
• Kernel fixes require a reboot into the patched kernel image. Schedule staged reboots (canary → partial → full) for production infrastructure following change-control policies.
• Short-term mitigations (if immediate patching is impossible)
• Prevent or limit mounting of CephFS on exposed hosts until a patched kernel is available.
• Restrict which users/processes can perform mount operations or create Ceph sessions.
• Isolate Ceph mounts to dedicated nodes where possible (reduce exposure surface for multi-tenant hosts).
• Verification and monitoring
• After patching, validate by checking kernel package changelogs for the commit or vendor advisory entry.
• Monitor dmesg/journal for KASAN traces, slab-use-after-free reports, or Ceph-related mount failure stack traces; these were the primary indicators in the initial reports.

---

How to confirm a host is affected or fixed​

• Affected host signs:
• Kernel oops or panic that references have_mon_and_osd_map, or KASAN output showing slab-use-after-free tied to that function.
• Ceph mount failures during session open with stack traces pointing to ceph client map handling.
• Confirmation of fix:
• Vendor advisories listing a patched kernel build or a kernel changelog that includes the upstream commit.
• Rebuilds from upstream that include the stable commit: verify the commit ID is present in your kernel tree if building in-house.
• Re-run reproducer tests in an isolated lab (if safe) with a patched build: reproducer should not hit the KASAN use-after-free trace on a fixed kernel.

Vendors will often map the upstream commit hash to their package changelog. That mapping is the most reliable verification method because kernel package version numbers can be ambiguous across backported branches.

---

Risk analysis: strengths of the fix and potential residual concerns​

Strengths​

• The upstream patch is surgical and focused: it corrects a specific locking/ordering window rather than reworking large subsystems. Surgical fixes tend to be easier to review and backport and typically carry lower regression risk.
• Reproducible failure modes under KASAN gave maintainers a clear test-case to validate the correctness of the fix and to confirm fix effectiveness.
• Multiple independent trackers and distributors have indexed the CVE and are issuing or preparing backports — broad ecosystem attention reduces the chance of inconsistent remediation guidance.

Residual concerns and caveats​

• Timing/race bugs are sensitive: backporting errors or incomplete merges into vendor kernel trees risk leaving a residual race in some package builds. Administrators should not assume a given kernel version number is fixed without verifying the vendor’s changelog includes the upstream commit or an explicit statement.
• Embedded and OEM kernels (appliances, vendor-supplied images, or cloud marketplace images) often lag distribution kernels. Confirm with the vendor whether their images are updated — do not assume distribution upgrades automatically cover OEM images.
• The practical exploitation vector remains local — but local attack capability in multi-tenant or cloud environments is not uncommon. Guest VMs or containerized workloads that can influence Ceph mounts are realistic adjacency paths; therefore exposure assessment must consider deployment topology.

---

Detection and Hunting guidance​

• Watch for kernel logs (dmesg/journal) containing:
• KASAN traces referencing have_mon_and_osd_map.
• Ceph mount stack traces or oopses that point into libceph functions.
• Correlate crashes with recent Ceph map updates or bursty cluster reconfiguration events.
• In environments that process untrusted mounts or user-supplied images, add monitoring and alerting around mount operations and unexpected kernel faults.
• Preserve vmcore/kernel crash dumps (kdump) when crashes occur — they are invaluable for matching traces to the upstream patch and for vendor escalation.

---

Recommended timeline and prioritization​

• High priority (within 48–72 hours): public-facing hosts or nodes that mount CephFS for multi-tenant workloads, cloud gateways, and hypervisors that could expose Ceph session operations to guest or untrusted code.
• Medium priority (one week): internal storage nodes where disruption is tolerable but must be minimized; schedule controlled reboots and verification.
• Low priority: single-user workstations or hosts not mounting Ceph — maintain regular update cadence.

Always weigh the operational cost of reboots against the risk model of the environment. For high-availability clusters, follow phased rollouts and test on staging nodes that mimic production workloads.

---

Closing analysis​

CVE‑2025‑68285 is a classic concurrency-induced kernel memory-safety bug: a small but real window where the kernel can read fields from a freed map object during Ceph session initialization. The bug is demonstrable under KASAN and was patched upstream with a focused fix to the locking/ordering discipline. The realistic operational consequence is downtime and instability; while there is theoretical risk of a sophisticated escalation chain, available advisories emphasize availability as the primary impact.
Administrators running Ceph clients in kernel space must treat the advisory seriously: inventory Ceph-mounting hosts, prioritize installing vendor-supplied kernel updates (verify vendor changelogs for the upstream commit), and schedule reboots. If immediate patching is not feasible, reduce exposure by limiting Ceph mounts on exposed hosts and applying access controls to mount operations.
The ecosystem response — multiple vendors adding tracker entries and preparing/issuing backports — makes remediation straightforward for most distributions, but attention to vendor-specific backporting and OEM image status is essential. For high-value or multi-tenant environments, patch and staged reboot rollouts are the prudent course to restore kernel memory-safety and operational stability.

---

Source: MSRC Security Update Guide - Microsoft Security Response Center