CVE-2025-38523

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cifs: Fix the smbd_response slab to allow usercopy<br /> <br /> The handling of received data in the smbdirect client code involves using<br /> copy_to_iter() to copy data from the smbd_reponse struct&amp;#39;s packet trailer<br /> to a folioq buffer provided by netfslib that encapsulates a chunk of<br /> pagecache.<br /> <br /> If, however, CONFIG_HARDENED_USERCOPY=y, this will result in the checks<br /> then performed in copy_to_iter() oopsing with something like the following:<br /> <br /> CIFS: Attempting to mount //172.31.9.1/test<br /> CIFS: VFS: RDMA transport established<br /> usercopy: Kernel memory exposure attempt detected from SLUB object &amp;#39;smbd_response_0000000091e24ea1&amp;#39; (offset 81, size 63)!<br /> ------------[ cut here ]------------<br /> kernel BUG at mm/usercopy.c:102!<br /> ...<br /> RIP: 0010:usercopy_abort+0x6c/0x80<br /> ...<br /> Call Trace:<br /> <br /> __check_heap_object+0xe3/0x120<br /> __check_object_size+0x4dc/0x6d0<br /> smbd_recv+0x77f/0xfe0 [cifs]<br /> cifs_readv_from_socket+0x276/0x8f0 [cifs]<br /> cifs_read_from_socket+0xcd/0x120 [cifs]<br /> cifs_demultiplex_thread+0x7e9/0x2d50 [cifs]<br /> kthread+0x396/0x830<br /> ret_from_fork+0x2b8/0x3b0<br /> ret_from_fork_asm+0x1a/0x30<br /> <br /> The problem is that the smbd_response slab&amp;#39;s packet field isn&amp;#39;t marked as<br /> being permitted for usercopy.<br /> <br /> Fix this by passing parameters to kmem_slab_create() to indicate that<br /> copy_to_iter() is permitted from the packet region of the smbd_response<br /> slab objects, less the header space.