CVE-2022-48742

Description

From CVE.org

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.

Statement

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).

Common Vulnerability Scoring System (CVSS) Score Details

Info alert:Important note

CVSS scores for open source components depend on vendor-specific factors (e.g. version or build chain). Therefore, Red Hat's score and impact rating can be different from NVD and other vendors. Red Hat remains the authoritative CVE Naming Authority (CNA) source for its products and services (see Red Hat classifications).

The following CVSS metrics and score provided are preliminary and subject to review.

CVSS v3 Score Breakdown

Red HatNVDcve.org
Base Score6.47.87.8
Attack VectorLocalLocalLocal
Attack ComplexityHighLowLow
Privileges RequiredHighLowLow
User InteractionNoneNoneNone
ScopeUnchangedUnchangedUnchanged
ConfidentialityHighHighHigh
Integrity ImpactHighHighHigh
Availability ImpactHighHighHigh

Vector

Red Hat: CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:H

NVD: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

cve.org: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

Red Hat CVSS v3 Score Explanation

See the 'Statement' section for an explanation of the difference between the CVSS from Red Hat and NVD.

Understanding the Weakness (CWE)

CWE-416

Integrity

Technical Impact: Modify Memory

The use of previously freed memory may corrupt valid data, if the memory area in question has been allocated and used properly elsewhere.

Availability

Technical Impact: DoS: Crash, Exit, or Restart

If chunk consolidation occurs after the use of previously freed data, the process may crash when invalid data is used as chunk information.

Confidentiality

Technical Impact: Read Memory

Read operations on freed memory can sometimes leak sensitive information instead of causing a crash

Integrity,Confidentiality,Availability

Technical Impact: Execute Unauthorized Code or Commands

If malicious data is entered before chunk consolidation can take place, it may be possible to take advantage of a write-what-where primitive to execute arbitrary code. If the newly allocated data happens to hold a class, in C++ for example, various function pointers may be scattered within the heap data. If one of these function pointers is overwritten with an address to valid shellcode, execution of arbitrary code can be achieved.

Frequently Asked Questions

Not sure what something means? Check out our Security Glossary.

Want to get errata notifications? Sign up here.