CVE-2025-40362

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ceph: fix multifs mds auth caps issue<br /> <br /> The mds auth caps check should also validate the<br /> fsname along with the associated caps. Not doing<br /> so would result in applying the mds auth caps of<br /> one fs on to the other fs in a multifs ceph cluster.<br /> The bug causes multiple issues w.r.t user<br /> authentication, following is one such example.<br /> <br /> Steps to Reproduce (on vstart cluster):<br /> 1. Create two file systems in a cluster, say &amp;#39;fsname1&amp;#39; and &amp;#39;fsname2&amp;#39;<br /> 2. Authorize read only permission to the user &amp;#39;client.usr&amp;#39; on fs &amp;#39;fsname1&amp;#39;<br /> $ceph fs authorize fsname1 client.usr / r<br /> 3. Authorize read and write permission to the same user &amp;#39;client.usr&amp;#39; on fs &amp;#39;fsname2&amp;#39;<br /> $ceph fs authorize fsname2 client.usr / rw<br /> 4. Update the keyring<br /> $ceph auth get client.usr &gt;&gt; ./keyring<br /> <br /> With above permssions for the user &amp;#39;client.usr&amp;#39;, following is the<br /> expectation.<br /> a. The &amp;#39;client.usr&amp;#39; should be able to only read the contents<br /> and not allowed to create or delete files on file system &amp;#39;fsname1&amp;#39;.<br /> b. The &amp;#39;client.usr&amp;#39; should be able to read/write on file system &amp;#39;fsname2&amp;#39;.<br /> <br /> But, with this bug, the &amp;#39;client.usr&amp;#39; is allowed to read/write on file<br /> system &amp;#39;fsname1&amp;#39;. See below.<br /> <br /> 5. Mount the file system &amp;#39;fsname1&amp;#39; with the user &amp;#39;client.usr&amp;#39;<br /> $sudo bin/mount.ceph usr@.fsname1=/ /kmnt_fsname1_usr/<br /> 6. Try creating a file on file system &amp;#39;fsname1&amp;#39; with user &amp;#39;client.usr&amp;#39;. This<br /> should fail but passes with this bug.<br /> $touch /kmnt_fsname1_usr/file1<br /> 7. Mount the file system &amp;#39;fsname1&amp;#39; with the user &amp;#39;client.admin&amp;#39; and create a<br /> file.<br /> $sudo bin/mount.ceph admin@.fsname1=/ /kmnt_fsname1_admin<br /> $echo "data" &gt; /kmnt_fsname1_admin/admin_file1<br /> 8. Try removing an existing file on file system &amp;#39;fsname1&amp;#39; with the user<br /> &amp;#39;client.usr&amp;#39;. This shoudn&amp;#39;t succeed but succeeds with the bug.<br /> $rm -f /kmnt_fsname1_usr/admin_file1<br /> <br /> For more information, please take a look at the corresponding mds/fuse patch<br /> and tests added by looking into the tracker mentioned below.<br /> <br /> v2: Fix a possible null dereference in doutc<br /> v3: Don&amp;#39;t store fsname from mdsmap, validate against<br /> ceph_mount_options&amp;#39;s fsname and use it<br /> v4: Code refactor, better warning message and<br /> fix possible compiler warning<br /> <br /> [ Slava.Dubeyko: "fsname check failed" -&gt; "fsname mismatch" ]