Hi Dan, On 3/10/2025 20:22, Dan Carpenter wrote: > On Mon, Mar 10, 2025 at 02:43:51PM +0200, Ilpo Järvinen wrote: >> On Mon, 10 Mar 2025, Dan Carpenter wrote: >> >>> There are a couple problems in this code: >>> >>> First, if amd_pmf_tee_init() fails then the function returns directly >>> instead of cleaning up. We cannot simply do a "goto error;" because >>> that would lead to a double free. I have re-written this code to >>> use an unwind ladder to free the allocations. >> >> Thanks Dan, >> >> Could you please amend this with the information of what is getting >> double freed, it took considerable amount of time for me to figure out. >> I assume it's ->fw_shm_pool ? >> > > Yes, that's it. Sure, I can re-write that. > >>> Second, if amd_pmf_start_policy_engine() fails on every iteration though >>> the loop then the code calls amd_pmf_tee_deinit() twice which is also a >>> double free. Call amd_pmf_tee_deinit() inside the loop for each failed >>> iteration. Also on that path the error codes are not necessarily >>> negative kernel error codes. Set the error code to -EINVAL. >> >> Maybe I should start to consistently reject any attempt to use >> cleanup/deinit helper functions instead of a proper rollback. It >> seems a pattern that is very prone to errors like this. > > I do not like deinit functions. They are so hard to review. But I > detected this bug because of a Smatch warning: > > drivers/platform/x86/amd/pmf/tee-if.c:540 amd_pmf_init_smart_pc() warn: missing unwind goto? Thank you for the fix. We have a CI that runs sparse/smatch/coverity to catch all these issues and unfortunately this was not caught by the CI system. But, I can confirm that Smatch is triggering this. drivers/platform/x86/amd/pmf/tee-if.c CHECK scripts/mod/empty.c CALL scripts/checksyscalls.sh DESCEND objtool INSTALL libsubcmd_headers CC [M] drivers/platform/x86/amd/pmf/tee-if.o CHECK drivers/platform/x86/amd/pmf/tee-if.c drivers/platform/x86/amd/pmf/tee-if.c:540 amd_pmf_init_smart_pc() warn: missing unwind goto? Thanks, Shyam
