[PATCH] xfrm: kill xfrm_dev_{state,policy}_flush_secctx_check()
Tetsuo Handa
penguin-kernel at I-love.SAKURA.ne.jp
Tue Jan 27 03:51:29 UTC 2026
On 2026/01/27 7:33, Paul Moore wrote:
> On Fri, Jan 23, 2026 at 5:13 AM Tetsuo Handa
> <penguin-kernel at i-love.sakura.ne.jp> wrote:
>>
>> Since xfrm_dev_{state,policy}_flush() are called from only NETDEV_DOWN and
>> NETDEV_UNREGISTER events, making xfrm_dev_{state,policy}_flush() no-op by
>> returning an error value from xfrm_dev_{state,policy}_flush_secctx_check()
>> is pointless. Especially, if xfrm_dev_{state,policy}_flush_secctx_check()
>> returned an error value upon NETDEV_UNREGISTER event, the system will hung
>> up with
>>
>> unregister_netdevice: waiting for $dev to become free. Usage count = $count
>>
>> message because the reference to $dev acquired by
>> xfrm_dev_{state,policy}_add() cannot be released.
>>
>> Signed-off-by: Tetsuo Handa <penguin-kernel at I-love.SAKURA.ne.jp>
>> ---
>> net/xfrm/xfrm_policy.c | 35 -----------------------------------
>> net/xfrm/xfrm_state.c | 33 ---------------------------------
>> 2 files changed, 68 deletions(-)
>
> I didn't make it very far into reviewing this patch, because it looks
> like xfrm_dev_state_flush() is called by the bonding driver's
> notification handler, and I don't see that reflected in this patch?
xfrm_dev_{state,policy}_flush() are called from only the bonding driver's NETDEV_UNREGISTER
event notification handler and the xfrm module's NETDEV_DOWN event / NETDEV_UNREGISTER event
notification handler ( https://elixir.bootlin.com/linux/v6.19-rc5/A/ident/xfrm_dev_state_flush ).
What this patch kills is not xfrm_dev_{state,policy}_flush() but
xfrm_dev_{state,policy}_flush_secctx_check(). No need to touch the bonding driver.
LSM hook for checking whether to allow deleting a file in tmpfs which is still mounted
makes sense, LSM hook for checking whether to allow starting unmount of tmpfs makes sense,
but LSM hook for checking whether to allow releasing memory in tmpfs while unmount operation
is already in progress causes nothing but a resource leak / denial-of-service kernel bug.
What xfrm_dev_{state,policy}_flush_secctx_check() are causing is something like
"LSM policy is refusing release of memory used by a file in tmpfs which is already under
unmount operation".
xfrm_dev_{state,policy}_flush_secctx_check() are too late to make LSM policy decision.
A must-not-fail operation has already started before LSM hooks are called.
More information about the Linux-security-module-archive
mailing list