Skip to content
Fencer Vulns
high 8.8

CVE-2025-40362 json

ceph: fix multifs mds auth caps issue

published 2025-12-16 10 mo ago modified 2026-10-15 24 d ago also EUVD-2025-203731

cvss
8.8
version 3.1, CNA
cisa kev
Not listed
not in CISA's catalog
epss
0.2%
EPSS 0.2% chance of exploitation in 30 days, percentile 5%
public exploits
0
none known

Summary

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

ceph: fix multifs mds auth caps issue

The mds auth caps check should also validate the fsname along with the associated caps. Not doing so would result in applying the mds auth caps of one fs on to the other fs in a multifs ceph cluster. The bug causes multiple issues w.r.t user authentication, following is one such example.

Steps to Reproduce (on vstart cluster): 1. Create two file systems in a cluster, say 'fsname1' and 'fsname2' 2. Authorize read only permission to the user 'client.usr' on fs 'fsname1' $ceph fs authorize fsname1 client.usr / r 3. Authorize read and write permission to the same user 'client.usr' on fs 'fsname2' $ceph fs authorize fsname2 client.usr / rw 4. Update the keyring $ceph auth get client.usr >> ./keyring

With above permssions for the user 'client.usr', following is the expectation. a. The 'client.usr' should be able to only read the contents and not allowed to create or delete files on file system 'fsname1'. b. The 'client.usr' should be able to read/write on file system 'fsname2'.

But, with this bug, the 'client.usr' is allowed to read/write on file system 'fsname1'. See below.

5. Mount the file system 'fsname1' with the user 'client.usr' $sudo bin/mount.ceph usr@.fsname1=/ /kmnt_fsname1_usr/ 6. Try creating a file on file system 'fsname1' with user 'client.usr'. This should fail but passes with this bug. $touch /kmnt_fsname1_usr/file1 7. Mount the file system 'fsname1' with the user 'client.admin' and create a file. $sudo bin/mount.ceph admin@.fsname1=/ /kmnt_fsname1_admin $echo "data" > /kmnt_fsname1_admin/admin_file1 8. Try removing an existing file on file system 'fsname1' with the user 'client.usr'. This shoudn't succeed but succeeds with the bug. $rm -f /kmnt_fsname1_usr/admin_file1

For more information, please take a look at the corresponding mds/fuse patch and tests added by looking into the tracker mentioned below.

v2: Fix a possible null dereference in doutc v3: Don't store fsname from mdsmap, validate against ceph_mount_options's fsname and use it v4: Code refactor, better warning message and fix possible compiler warning

[ Slava.Dubeyko: "fsname check failed" -> "fsname mismatch" ]

Patch / fix

  • Linux Linux 6.12.58, 6.17.8, 6.18
  • linux Debian 13 6.12.63-1
  • linux Debian 14 6.17.8-1

debian advisories DEBIAN-CVE-2025-40362

  • linux Ubuntu 25.10 6.17.0-14.14
  • linux-aws Ubuntu 25.10 6.17.0-1007.7
  • linux-gcp Ubuntu 25.10 6.17.0-1007.7
  • linux-azure Ubuntu 25.10 6.17.0-1008.8
  • linux-raspi Ubuntu 25.10 6.17.0-1008.8
  • linux-riscv Ubuntu 25.10 6.17.0-14.14.1
  • linux-oracle Ubuntu 25.10 6.17.0-1007.7
  • linux-aws-6.17 Ubuntu 24.04 LTS 6.17.0-1007.7~24.04.1

ubuntu advisories UBUNTU-CVE-2025-40362

Ubuntu security data © Canonical Ltd., from https://github.com/canonical/ubuntu-security-notices via OSV; changed: normalised to fixed package versions per release. CC BY-SA 4.0

  • kernel-rt Linux Micro 6.2 6.12.0-160000.9.1
  • kernel-64kb SLES 16.0, Linux Micro 6.2, SLES for SAP applications 16.0 6.12.0-160000.9.1
  • kernel-source SLES 16.0, Linux Micro 6.2, SLES for SAP applications 16.0 6.12.0-160000.9.1
  • kernel-default SLES 16.0, SLE High Availability Extension 16.0, Linux Micro 6.2 +1 more 6.12.0-160000.9.1
  • kernel-default-base SLES 16.0, Linux Micro 6.2, SLES for SAP applications 16.0 6.12.0-160000.9.1.160000.2.6
  • kernel-syms SLES 16.0, Linux Micro Extras 6.2, SLES for SAP applications 16.0 6.12.0-160000.9.1
  • kernel-azure SLES for SAP applications 16.0, SLES 16.0 6.12.0-160000.9.1
  • kernel-obs-qa SLES for SAP applications 16.0, SLES 16.0 6.12.0-160000.9.1

suse advisories SUSE-SU-2026:20207-1SUSE-SU-2026:20220-1SUSE-SU-2026:20564-1SUSE-SU-2026:20228-1

  • kernel-rt openSUSE Leap 16.0 6.12.0-160000.9.1
  • dtb-aarch64 openSUSE Leap 16.0 6.12.0-160000.9.1
  • kernel-64kb openSUSE Leap 16.0 6.12.0-160000.9.1
  • kernel-syms openSUSE Leap 16.0 6.12.0-160000.9.1
  • kernel-azure openSUSE Leap 16.0 6.12.0-160000.9.1
  • kernel-obs-qa openSUSE Leap 16.0 6.12.0-160000.9.1
  • kernel-source openSUSE Leap 16.0 6.12.0-160000.9.1
  • kernel-default openSUSE Leap 16.0 6.12.0-160000.9.1

opensuse advisories openSUSE-SU-2026:20145-1

Vendor advisories

What the vendors themselves say about their products: affected, fixed or not affected, and what to do.

red hat product security vex CVE-2025-40362 updated cvss 5.5

kernel: Linux kernel (ceph): Incorrect authorization allows privilege escalation in multifs clusters

  • Red Hat Enterprise Linux 7 perf, kernel, bpftool, kernel-rt, python-perf, kernel-kdump, +8 more Red Hat Enterprise Linux 8 perf, kernel, bpftool, kernel-rt, kernel-core, kernel-tools, +29 more Red Hat Enterprise Linux 9 rv, perf, rtla, kernel, bpftool, libperf, +83 more Red Hat Enterprise Linux 10 kernel
    affected: workaround, no fix available “Fix deferred”
  • Red Hat Enterprise Linux 6 perf, kernel, python-perf, kernel-kdump, kernel-firmware, kernel-bootwrapper, +1 more
    not affected: vulnerable code not present

Red Hat CSAF VEX © Red Hat, Inc., from https://security.access.redhat.com/data/csaf/v2/vex/; changed: reduced to product statuses and remediations. CC BY 4.0 · csaf

CISA SSVC

Exploitation
none
Automatable
no
Technical impact
total
Assessed
24 d ago

Exploit prediction

0.16% chance of exploitation in the next 30 days, higher than 5% of all scored CVEs (FIRST EPSS, 2026-11-08).

CVSS scores

assigned by version score vector
CNA 3.1 8.8 CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H

Affected products

  • Linux Linux

Classification

Technology feeds

References

Sources

Fencer Vulns keeps one entry per vulnerability: the CVE id wins, then GHSA, and records that alias each other are merged, except that two CVEs always keep separate entries. The same data is available as JSON.