On Sat, Nov 4, 2023 at 2:33 AM Paulo Alcantara <pc@xxxxxxxxxxxxx> wrote: > > nspmangalore@xxxxxxxxx writes: > > > From: Shyam Prasad N <sprasad@xxxxxxxxxxxxx> > > > > Today, we have no way to access the cifs_sb when we > > just have pointers to struct tcon. This is very > > limiting as many functions deal with cifs_sb, and > > these calls do not directly originate from VFS. > > > > This change introduces a new cifs_sb field in cifs_tcon > > that points to the cifs_sb for the tcon. The assumption > > here is that a tcon will always map to this cifs_sb and > > will never change. > > > > Also, refcounting should not be necessary, since cifs_sb > > will never be freed before tcon. > > > > Signed-off-by: Shyam Prasad N <sprasad@xxxxxxxxxxxxx> > > --- > > fs/smb/client/cifsglob.h | 1 + > > fs/smb/client/connect.c | 2 ++ > > 2 files changed, 3 insertions(+) > > This is wrong as a single tcon may be shared among different > superblocks. You can, however, map those superblocks to a tcon by using > the cifs_sb_master_tcon() helper. > > If you do something like this > > mount.cifs //srv/share /mnt/1 -o ... > mount.cifs //srv/share /mnt/1 -o ... -> -EBUSY > > tcon->cifs_sb will end up with the already freed superblock pointer that > was compared to the existing one. So, you'll get an use-after-free when > you dereference tcon->cifs_sb as in patch 11/14. Hi Steve, I discussed this one with Paulo separately. You can drop this patch. I'll have another patch in place of this one. And then send you an updated patch for the patch which depends on it. -- Regards, Shyam
