Page MenuHomeFreeBSD

ipsec: Drain async ipsec_offload work when destroying a vnet
ClosedPublic

Authored by markj on Aug 30 2024, 12:54 AM.
Tags
None
Referenced Files
F102185891: D46483.diff
Fri, Nov 8, 4:16 PM
Unknown Object (File)
Wed, Oct 30, 1:38 PM
Unknown Object (File)
Sat, Oct 19, 10:23 PM
Unknown Object (File)
Oct 9 2024, 9:18 AM
Unknown Object (File)
Oct 2 2024, 5:21 PM
Unknown Object (File)
Oct 1 2024, 1:31 PM
Unknown Object (File)
Oct 1 2024, 11:20 AM
Unknown Object (File)
Oct 1 2024, 3:57 AM

Details

Summary

The ipsec_offload code in some cases releases object references in an
asynchronous context where it needs to set the current VNET. Make sure
that all such work completes before the VNET is actually destroyed,
otherwise a use-after-free is possible.

Reported by: KASAN
Fixes: ef2a572bf6bd ("ipsec_offload: kernel infrastructure")

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

This revision is now accepted and ready to land.Aug 30 2024, 6:35 AM

This patch can cause hangs, since it's possible for key_vnet_destroy() to execute in taskqueue_thread's context.

To fix this, I wonder if ipsec_accel can use a dedicated taskqueue thread instead of taskqueue_thread.

This patch can cause hangs, since it's possible for key_vnet_destroy() to execute in taskqueue_thread's context.

To fix this, I wonder if ipsec_accel can use a dedicated taskqueue thread instead of taskqueue_thread.

It can, the restriction is that all handling should occur in the same single-threaded context.
I did not allocated dedicated thread because the events like creation or destruction of SAs are very rare, and creation or destruction of SPs almost never happen. So I do not want to waste the whole thread for this.

Then, for me this feels more like a bug in taskqueue_drain_all(). What about D46489 instead?