Token fixes: reattach token on container reload #511
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
To avoid references to destroyed container objects, use deep copies of container_usbdev_t elements in tracking list allow_on_unplug_list. E.g., on container reload the corresponding container is freed and so is the list of usbdevs of which the references were held in other container's 'allow_on_unplug_list's. This use-after-free was triggered if the container was reloaded and started again. Fixes: 1dd99f4 ("daemon/c_hotplug: Deny access to USB tokens") Signed-off-by: Michael Weiß <[email protected]>
On reload the new container object is created with container_new()
and afterwards the previous object is deleted by a call to
container_free(). Makes sens to first try to create the new updated
container object and only if this succeeds, the old object is
destroyed. However on container_new() the token is attached to the
scd and on container_free() it is removed:
Thus we now have the following behavior:
1) We have the token attached in the scd. The config updated kicks
in and we get a new container object created by container_new().
A second attach is made in the scd:
<INFO> control.c+221: Token already exists.
2) That is ok, we just ignore that in the scd and the new updated
container object is created successfully.
3) However afterwards the container_free(<outdated container object>)
is made and also the scd resources are released by an internal
call to usbtoken_free() in scd:
<DEBUG> usbtoken.c+603: Closing CT interface (ctn=0) done.
4) Since both container objects map to the same token in the scd, we
now have no token attached in the scd anymore.
5) An attempt to do anything token related in the cmld now results
in that the token is not available:
<ERROR> control.c+254: No token loaded, unlock failed
Simply fix this by reattaching the token after the container_free()
of the outdated container.
Fixes: c13ef81 ("daemon/cmld: cleanup observer handling")
Signed-off-by: Michael Weiß <[email protected]>
k0ch4lo
approved these changes
Dec 5, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
daemon/cmld: reattach token on container reload
On reload the new container object is created with container_new()
and afterwards the previous object is deleted by a call to
container_free(). Makes sens to first try to create the new updated
container object and only if this succeeds, the old object is
destroyed. However on container_new() the token is attached to the
scd and on container_free() it is removed:
Thus we now have the following behavior:
We have the token attached in the scd. The config updated kicks
in and we get a new container object created by container_new().
A second attach is made in the scd:
control.c+221: Token already exists.
That is ok, we just ignore that in the scd and the new updated
container object is created successfully.
However afterwards the container_free()
is made and also the scd resources are released by an internal
call to usbtoken_free() in scd:
usbtoken.c+603: Closing CT interface (ctn=0) done.
Since both container objects map to the same token in the scd, we
now have no token attached in the scd anymore.
An attempt to do anything token related in the cmld now results
in that the token is not available:
control.c+254: No token loaded, unlock failed
Simply fix this by reattaching the token after the container_free()
of the outdated container.
Fixes: c13ef81 ("daemon/cmld: cleanup observer handling")
Signed-off-by: Michael Weiß [email protected]