On Thu, Feb 24, 2022 at 8:59 AM Yun Levi <ppbuk5246@xxxxxxxxx> wrote: > > On Thu, Feb 24, 2022 at 8:24 AM Al Viro <viro@xxxxxxxxxxxxxxxxxx> wrote: > > > > On Thu, Feb 24, 2022 at 08:17:52AM +0900, Levi Yun wrote: > > > Suppose a module registers its own binfmt (custom) and formats is like: > > > > > > +---------+ +----------+ +---------+ > > > | custom | -> | format1 | -> | format2 | > > > +---------+ +----------+ +---------+ > > > > > > and try to call unregister_binfmt with custom NOT in __exit stage. > > > > Explain, please. Why would anyone do that? And how would such > > module decide when it's safe to e.g. dismantle data structures > > used by methods of that binfmt, etc.? > > Could you give more detailed example? > > I think if someone wants to control their own binfmt via "ioctl" not > on time on LOAD. > For example, someone wants to control exec (notification, > allow/disallow and etc..) > and want to enable and disable own's control exec via binfmt reg / unreg > In that situation, While the module is loaded, binfmt is still live > and can be reused by > reg/unreg to enable/disable his exec' control. > > module can decide it's safe to unload by tracing the stack and > confirming whether some tasks in the custom binfmt's function after it > unregisters its own binfmt. > > > Because it looks like papering over an inherently unsafe use of binfmt interfaces.. > > I think the above example it's quite a trick and stupid. it's quite > unsafe to use as you mention. > But, misuse allows that situation to happen without any warning. > As a robustness, I just try to avoid above situation But, > I think it's better to restrict unregister binfmt unregister only when > there is no module usage. And not only stupid exmaple, if someone loadable custom binfmt register in __init and __exit via register and unregister_binfmt, I think that situation could happen.
