mirror of
https://github.com/xen-project/xen.git
synced 2026-10-28 02:01:24 +01:00
Commitf2bebf72c4"xenstore: rework of transaction handling" moved out from copying the entire database everytime a new transaction is opened to track the list of nodes changed. The content of all the nodes accessed during a transaction will be temporarily stored in TDB using a different key. The function create_node() may write/update multiple nodes if the child doesn't exist. In case of a failure, the function will revert any changes (this include any update to TDB). Unfortunately, the function which reverts the changes (i.e. destroy_node()) will not use the correct key to delete any update or even request the transaction to fail. This means that if a client decide to go ahead with committing the transaction, orphan nodes will be created because they were not linked to an existing node (create_node() will write the nodes backwards). Once some nodes have been partially updated in a transaction, it is not easily possible to undo any changes. So rather than continuing and hit weird issue while committing, it is much saner to fail the transaction. This will have an impact on any client that decides to commit even if it can't write a node. Although, it is not clear why a normal client would want to do that... Lastly, update destroy_node() to use the correct key for deleting the node. Rather than recreating it (this will allocate memory and therefore fail), stash the key in the structure node. This is XSA-415 / CVE-2022-42310. Signed-off-by: Julien Grall <jgrall@amazon.com> Reviewed-by: Juergen Gross <jgross@suse.com> (cherry picked from commit5d71766bd1)