MokManager: handle mok parameter allocations better.

Covscan daftly claims:

288. var_compare_op: Comparing MokSB to null implies that MokSB might be null.
2330                if (MokSB) {
2331                        menu_strings[i] = L"Change Secure Boot state";
2332                        menu_item[i] = MOK_CHANGE_SB;
2333                        i++;
2334                }
2335
...
2358                choice = console_select(perform_mok_mgmt, menu_strings, 0);
2359                if (choice < 0)
2360                        goto out;
...
2362                switch (menu_item[choice]) {
...
2395                case MOK_CHANGE_SB:
    CID 182841 (#1 of 1): Dereference after null check
    (FORWARD_NULL)293. var_deref_model: Passing null pointer MokSB to
    mok_sb_prompt, which dereferences it. [show details]
2396                        efi_status = mok_sb_prompt(MokSB, MokSBSize);

Which is, of course, entirely false, beause for menu_item[choice] to be
MOK_CHANGE_SB, MokSB must be !NULL.  And then:

    252. Condition efi_status == 0, taking true branch.
2397                        if (efi_status == EFI_SUCCESS)
2398                                MokSB = NULL;

This guarantees it won't be in the list the next time through the loop.

This adds tests for NULLness before mok_sb_prompt(), just to make it
more clear to covscan what's going on.

Also do the same thing for all of:
	MOK_CHANGE_SB
	MOK_SET_PW
	MOK_CHANGE_DB
	MOK_ENROLL_MOKX
	MOK_DELETE_MOKX

I also Lindent-ed everything I had to touch.

Three other minor errors are also fixed:
1) the loop in enter_mok_menu() leaked the menu allocations each time
   through the loop
2) mok_sb_prompt(), mok_pw_prompt(), and mok_db_prompt() all call
   FreePool() on their respective variables (MokSB, etc), and
   check_mok_request() also calls FreePool() on these.  This sounds
   horrible, but it turns out it's not an issue, because they only free
   them in their EFI_SUCCESS paths, and enter_mok_menu() resets the
   system if any of the mok_XX_prompt() calls actually returned
   EFI_SUCCESS, so we never get back to check_mok_request() for it to do
   its FreePool() calls.
3) the loop in enter_mok_menu() winds up introducing a double free in
   the call to free_menu(), but we also can't hit this bug, because all
   the exit paths from the loop are "goto out" (or return error) rather
   than actually exiting on the loop conditional.

Signed-off-by: Peter Jones <pjones@redhat.com>

0 files changed, 0 insertions, 0 deletions