A vulnerability was found in iproute2 before 5.1.0 has a use-after-free in get_netnsid_from_name in ip/ipnetns.c. NOTE: security relevance may be limited to certain uses of setuid that, although not a default, are sometimes a configuration option offered to end users. Even when setuid is used, other factors (such as C library configuration) may block exploitability. References: https://git.kernel.org/pub/scm/network/iproute2/iproute2.git/commit/?id=9bf2c538a0eb10d66e2365a655bf6c52f5ba3d10
Created iproute tracking bugs for this issue: Affects: fedora-all [bug 1868213]
From upstream commit: """ In get_netnsid_from_name func, answer is freed before rta_getattr_u32(tb[NETNSA_NSID]), where tb[] refers to answer`s content. If we set MALLOC_MMAP_THRESHOLD_=0, mmap will be adoped to malloc memory, which will be freed immediately after calling free func. So reading tb[NETNSA_NSID] will access the released memory after free(answer). """
Note that for security reasons the environment variable "MALLOC_MMAP_THRESHOLD_" is ignored in set-user-ID and set-group-ID programs [1]. This is not relevant in this case though, as the attacker would need to have root privileges anyways to be able to create a network namespace in the first place. [1] https://man7.org/linux/man-pages/man3/mallopt.3.html
It is unclear to me how this could be exploited to attack other users, it seems like a self-attack. This bug is more of a reliability issue since MALLOC_MMAP_THRESHOLD_ must be set to 0 and the user must trigger a crash locally by displaying the network namespaces. Under normal circumstances (i.e., MALLOC_MMAP_THRESHOLD_ unset) the security impact is minimal: the network namespace id (uint32) is "disclosed" from the free()d memory chunk through the result of get_netnsid_from_name(). Note that after calling free() the nsid is immediately accessed and returned to the parent function netns_map_init(). The pointer to the heap chunk is a local variable which is automatically released when the function ends, so it seems unlikely the use-after-free could be exploited in any meaningful way. --- struct nlmsghdr *answer; struct rtattr *tb[NETNSA_MAX + 1]; <snip> free(answer); return rta_getattr_u32(tb[NETNSA_NSID]); // tb[NETNSA_NSID] points to nsid in answer's content
Statement: This issue affects the versions of `iproute` as shipped with Red Hat Enterprise Linux 7. Red Hat Enterprise Linux 8 is not affected by this flaw. This flaw has been rated as having a security impact of Low, and is not currently planned to be addressed in future updates of Red Hat Enterprise Linux 5 and Red Hat Enterprise Linux 6. Red Hat Enterprise Linux 5 is now in Extended Life Phase of the support and maintenance life cycle. Red Hat Enterprise Linux 6 is now in Maintenance Support 2 Phase of the support and maintenance life cycle. For additional information, refer to the Red Hat Enterprise Linux Life Cycle: https://access.redhat.com/support/policy/updates/errata/.