CVE-2022-48742

In the Linux kernel, the following vulnerability has been resolved:

rtnetlink: make sure to refresh master_dev/m_ops in __rtnl_newlink()

While looking at one unrelated syzbot bug, I found the replay logic in __rtnl_newlink() to potentially trigger use-after-free.

It is better to clear master_dev and m_ops inside the loop, in case we have to replay it.

Actual only for Red Hat Enterprise Linux 8. Fixed for all versions of Red Hat Enterprise Linux 9.

Reading the source code, related source in function __rtnl_newlink or in rtnl_newlink for newer versions. The fix is that setting to NULL these vars

• master_dev = NULL;
• m_ops = NULL; just before usage (before call "master_dev = netdev_master_upper_dev_get(dev);"), but not in advance in the beginning of func __rtnl_newlink. It means that for some complex conditions potentially these vars could be inited with some incorrect values between. No known ways to reproduce it, so saying generally could be considered as not a security issue (or maybe as potential security issue with low level impact).

The bug could happen only if function rtnl_link_ops_get(..) returns some "ops" (instead of NULL). This could happen if some option "kind" exists. Basically it could happen only if IFLA_INFO_KIND being used (that is ops->kind). It is possible to set this "ops->kind" during __rtnl_newlink(..) call. See "RTM_NEWLINK" in doc https://man7.org/linux/man-pages/man7/rtnetlink.7.html I think that regular user cannot trigger call to the "RTM_NEWLINK", so only privileged user can try to trigger this issue (potentially, because unlikely that can find way how to trigger it).

The CVSS score(s) listed for this vulnerability do not reflect the associated product's status, and are included for informational purposes to better understand the severity of this vulnerability.