In scenarios where a program running inside a container issues a syscall that triggers the kernel to upcall cifs.upcall, such as when users access a multiuser cifs mount or when users access a DFS link, cifs.upcall is executed in the host environment where its execution may indirectly leak an information about resources available only to host applications, such as Kerberos credential caches, to a containerized application. As a result, a containerized application may trigger access to files on an SMB share under an identity otherwise not intended to be accessed by this container's environment. The bug is a consequence of the kernel calling the host cifs.upcall binary and can traced back to the introduction of the cifs.upcall mechanism in cifs-utils and the introduction of containers in the kernel.
Created attachment 16512 [details] announcement
I'm adding Metze to CC as I'm not sure he can see the bug (another bugzilla problem...) Just updating this bug to mention the discussion happening in the private email thread: * We can set a date in three weeks or so. E.g. by end of March. This would give enough time for other vendors. * How do we notify other vendors? The usual bugzilla checkbox is not in this bug.
(In reply to Aurélien Aptel from comment #3) > * How do we notify other vendors? The usual bugzilla checkbox is not in this bug. I could help with communication on distros/linux-distros if there is a need. My first samba bug though. Let me know if you need this assistance.
Our standard method for communication with Samba vendors is by adding their group to the bug. But this bugzilla is not set up to add other groups, so we need help from bugzilla administrators to adjust the component for cifsvfs to provide this capability.
Opening this bug to Samba vendors. This is a cifs-utils package issue that we plan to make public on April 12th, 2021. A fix and an announcement details can be found in the attachments.
Fixed in cifs-utils 6.13.