On 23.06.2022 15:03, Julien Grall wrote:
>
>
> On 23/06/2022 13:59, Jan Beulich wrote:
>> On 23.06.2022 13:24, Julien Grall wrote:
>>> From: Julien Grall <jgr...@amazon.com>
>>>
>>> At the moment, corrupt() is neither checking for allocation failure
>>> nor freeing the allocated memory.
>>>
>>> Harden the code by printing ENOMEM if the allocation failed and
>>> free 'str' after the last use.
>>>
>>> This is not considered to be a security issue because corrupt() should
>>> only be called when Xenstored thinks the database is corrupted. Note
>>> that the trigger (i.e. a guest reliably provoking the call) would be
>>> a security issue.
>>>
>>> Fixes: 06d17943f0cd ("Added a basic integrity checker, and some basic
>>> ability to recover from store")
>>> Signed-off-by: Julien Grall <jgr...@amazon.com>
>>
>> Is this something which would want queuing for backport?
>
> I would say yes. There are a couple of more Xenstored patches I would
> consider for backporting:
>
> fe9be76d880b tools/xenstore: fix error handling of check_store()
> b977929d3646 tools/xenstore: fix hashtable_expand() zeroing new area
>
> Who is taking care of tools backport nowadays?
I'm trying to, as long as they apply cleanly enough. But I'd prefer if
rather sooner then later I could offload this again. And I'm not
actively looking to spot backporting candidates there (unlike for the
hypervisor, excluding Arm).
Jan
