> Mostly of what has been happening with binary formats lately is code > removal. > > So I humbly suggest the best defense against misuse by modules is to > simply remove "EXPORT_SYMBOL(__register_binfmt)". It could be a solution. but that means the kernel doesn't allow dynamic binfmt using modules too. I think the best safe way to remove registered binfmt is ... unregister binfmt list first ---- (1) synchronize_rcu_task(); // tasklist stack-check... unload module. But for this, there shouldn't happen in the above situation of (1). If unregister_binfmt has this problem.. I think there is no way to unload safely for dynamic registered binfmt via module. On Thu, Feb 24, 2022 at 9:42 AM Eric W. Biederman <ebiederm@xxxxxxxxxxxx> wrote: > > Yun Levi <ppbuk5246@xxxxxxxxx> writes: > > > 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. > > Mostly of what has been happening with binary formats lately is code > removal. > > So I humbly suggest the best defense against misuse by modules is to > simply remove "EXPORT_SYMBOL(__register_binfmt)". > > Eric
