CVE-2022-49749: i2c: designware: use casting of u64 in clock multiplication to avoid overflow
In the Linux kernel, the following vulnerability has been resolved:
i2c: designware: use casting of u64 in clock multiplication to avoid overflow
In functions i2c_dw_scl_lcnt() and i2c_dw_scl_hcnt() may have overflow
by depending on the values of the given parameters including the ic_clk.
For example in our use case where ic_clk is larger than one million,
multiplication of ic_clk * 4700 will result in 32 bit overflow.
Add cast of u64 to the calculation to avoid multiplication overflow, and
use the corresponding define for divide.
Security readout for executives and security teams
Plain-English summary
CVE-2022-49749 is a Linux kernel availability issue in the DesignWare I2C driver. A clock calculation can overflow on some configurations, potentially causing denial of service. The source data indicates local access and low privileges are required, with no confidentiality or integrity impact listed.
Executive priority
Treat this as a routine-to-expedited kernel maintenance item, not an emergency internet-facing crisis. Prioritize critical embedded, industrial, appliance, or server platforms where I2C failure could affect service availability.
Technical view
The flaw is a CWE-190 integer overflow in i2c_dw_scl_lcnt() and i2c_dw_scl_hcnt(). Multiplying ic_clk by timing constants could overflow 32-bit arithmetic, such as when ic_clk exceeds one million. The kernel fix casts calculations to u64 and uses the proper divide constant.
Likely exposure
Exposure is most likely on systems running affected Linux kernels with the DesignWare I2C controller driver and relevant clock configurations. The supplied data does not show broad remote exposure, affected distributions, or device models beyond Linux kernel versions and commits.
Exploitation context
The CVSS vector is local, low-complexity, low-privilege, and no user interaction. CISA KEV status is false in the source bundle, and no cited source states active exploitation or provides public exploit evidence.
Researcher notes
The source bundle identifies the bug and stable kernel fixes but does not provide distribution package status, affected hardware models, crash traces, or exploitation details. Validate exposure through kernel source, configuration, and vendor advisories.
Mitigation direction
Update to a kernel or vendor package containing the referenced stable fixes.
Check Linux distribution advisories for backported fixes matching your deployed kernel branch.
Prioritize systems using the DesignWare I2C driver on operationally important hardware.
Avoid inventing compensating controls; follow vendor guidance where patching is constrained.
Validation and detection
Inventory kernel versions and confirm whether the DesignWare I2C driver is present or loaded.
Compare deployed kernels against vendor advisories and the referenced stable commits.
Review device-tree or platform configuration for high ic_clk values where applicable.
Confirm patched code uses u64 casting in the affected clock calculations.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cwe · low confidence lookup
CWE-190: Exact CWE lookup
Use the exact CWE identifier as the starting point before reviewing related ATT&CK behavior. Open the exact CWE lookup page first, then review the ATT&CK searches from that MITRE weakness context. This is a Glexia lookup hint, not an official ATT&CK mapping.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.