• Thomas Haller's avatar
    platform/netlink: don't reallocate ancillary data for recvmsg() on truncation · 5740ed67
    Thomas Haller authored
    Coverity thinks there is a problem here:
        Error: TAINTED_SCALAR (CWE-20): [#def233]
        NetworkManager-1.31.5/src/libnm-platform/nm-netlink.c:1437: tainted_argument: Calling function "recvmsg" taints argument "msg".
        NetworkManager-1.31.5/src/libnm-platform/nm-netlink.c:1458: tainted_data: Passing tainted expression "msg.msg_controllen" to "g_realloc", which uses it as an allocation size.
        NetworkManager-1.31.5/src/libnm-platform/nm-netlink.c:1458: remediation: Ensure that tainted values are properly sanitized, by checking that their values are within a permissible range.
        # 1456|
        # 1457|           msg.msg_controllen *= 2;
        # 1458|->         msg.msg_control = g_realloc(msg.msg_control, msg.msg_controllen);
        # 1459|           goto retry;
        # 1460|       }
    but the problem is not the tainted data. The problem is how should
    we handle MSG_CTRUNC? If we reach MSG_CTRUNC we already lost a message.
    Retrying to receive the next message is not going to fix that and is
    Also, there really is no reason why any truncation should happen. The only
    ancillary data that should be present is the sender information, and for
    that our buffer is supposed to be large enough.
    So, simply ignore truncation. It shouldn't happen, if it happened we
    cannot recover from it (aside failing an assertion), and all we really
    care are the retrieved credentials. If truncation happened, we might
    not have retrieved the credentials, but then that is for the caller
    to handle (by rejecting the message as untrusted).