The analysis is based on the detailed vulnerability report 'krb5_detect_1.md' (content fetched from https://raw.githubusercontent.com/LuMingYinDetect/krb5_defects/main/krb5_detect_1.md), as no patch commit information was provided. This report pinpoints a memory leak in the file 'krb5/src/lib/rpc/pmap_rmt.c' in Kerberos 5 version 1.21.2.
The report provides code snippets (including function signatures and line numbers) and a logical walkthrough of the vulnerability:
- The function, identified from screenshots as 'clnt_com_create', is located in 'krb5/src/lib/rpc/pmap_rmt.c'.
- Inside 'clnt_com_create', a pointer 'port_ptr' is initialized to NULL.
- The function 'gssrpc_xdr_reference' is called with '&port_ptr'. In 'XDR_DECODE' mode (which is active), 'gssrpc_xdr_reference' allocates memory for 'port_ptr' using 'mem_alloc' (a macro for 'malloc') if 'port_ptr' is NULL. This allocation occurs before 'gssrpc_xdr_reference' calls its 'proc' argument (another XDR function, in this case 'xdr_u_int32') on the now-allocated 'port_ptr'.
- The vulnerability is triggered if the following sequence occurs:
a. 'mem_alloc' within 'gssrpc_xdr_reference' successfully allocates memory for 'port_ptr'.
b. The subsequent 'proc' call (e.g., 'xdr_u_int32' on 'port_ptr') within 'gssrpc_xdr_reference' fails, causing 'gssrpc_xdr_reference' to return a failure status (e.g., FALSE).
c. Back in 'clnt_com_create', the condition
if (!gssrpc_xdr_reference(...) && !xdr_u_int32(xdrs, &crp->resultslen)) is evaluated. If 'gssrpc_xdr_reference' returned FALSE (so !gssrpc_xdr_reference(...) is TRUE), and the second call xdr_u_int32(xdrs, &crp->resultslen) also returns FALSE (so !xdr_u_int32(...) is TRUE), the entire condition (TRUE && TRUE) becomes TRUE.
d. This TRUE condition leads to the execution of goto done;.
- The code at the
done: label (around line 170 in 'pmap_rmt.c') handles cleanup for other resources but does not include a call to free the memory allocated for port_ptr.
- The function then returns, leaking the memory pointed to by
port_ptr.
The identified vulnerable function is 'clnt_com_create' because it contains this flawed control flow that fails to deallocate memory under specific error conditions. The function name, file path, and operative line numbers are derived from the detailed analysis and screenshots presented in the 'krb5_detect_1.md' report. Confidence in this function being the site of the vulnerability logic is high due to the specificity of the report.