On Mon, Nov 6, 2023 at 9:42 PM Shyam Prasad N <nspmangalore@xxxxxxxxx> wrote: > > 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 Here's the replacement patch for "cifs: add a back pointer to cifs_sb from tcon" -- Regards, Shyam
Attachment:
0004-cifs-do-not-pass-cifs_sb-when-trying-to-add-channels.patch
Description: Binary data
