lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Sat, 13 Feb 2021 17:09:17 +0000
From:   "Winkler, Tomas" <>
To:     Richard Weinberger <>
CC:     Miquel Raynal <>,
        Vignesh Raghavendra <>,
        linux-mtd <>,
        linux-kernel <>
Subject: RE: [PATCH] mtd: use refcount to prevent corruption

> Tomas,
> ----- Urspr√ľngliche Mail -----
> >> As Richard was saying, we are really open to enhance MTD refcounting.
> >>
> >> However, the issue you are facing is, IMHO, not related to MTD but to
> MFD.
> >> There should be a way to avoid MFD to vanish by taking a reference of
> >> it through mtd->_get_device(). I don't think addressing the case
> >> where MFD vanishes while MTD (as a user) is still active is the right
> approach.
> >
> > I think it won't work because MFD sub-driver remove() is called   and it
> must
> > succeed because the main device  is not accessible unlike glueubi
> > which just returns -EBUSY.
> Well, the trick in glubi (and other MTDs with "hotplug" support) is not to
> reject removal of the sub-device. ->_put_device() is of return type void.
> The key is grabbing a reference on the sub-device in ->_get_device() such
> that the layer below doesn't even try to remove while the MTD is in use.

I understand that. But in that case the kernel is in the mercy of user space to close the handle,  
the whole perception here is that of hotplug that the device is  physically removed it cannot wait 
for the user space to complete. What's the fix is trying to do is to bail out gracefully.

> > so we postpone the mtd unregister to  mtd_info->_put_device()  but it
> > that state we have nothing to hold on as the device is gone in
> > remove() User will fail anyway, as the underlying device is not
> > functional in that state.
> > Anyway I've tried your suggestion, the kernel is crashing, hope I
> > haven't done some silly bug.
> Can you point us to the affected code?
> This would help a lot to understand the issue better.
> I'm sure we can find a solution.

Got green light on releasing the patches will send soon.


Powered by blists - more mailing lists