Executive Summary
Informations | |||
---|---|---|---|
Name | CVE-2022-49208 | First vendor Publication | 2025-02-26 |
Vendor | Cve | Last vendor Modification | 2025-03-18 |
Security-Database Scoring CVSS v3
Cvss vector : CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H | |||
---|---|---|---|
Overall CVSS Score | 5.5 | ||
Base Score | 5.5 | Environmental Score | 5.5 |
impact SubScore | 3.6 | Temporal Score | 5.5 |
Exploitabality Sub Score | 1.8 | ||
Attack Vector | Local | Attack Complexity | Low |
Privileges Required | Low | User Interaction | None |
Scope | Unchanged | Confidentiality Impact | None |
Integrity Impact | None | Availability Impact | High |
Calculate full CVSS 3.0 Vectors scores |
Security-Database Scoring CVSS v2
Cvss vector : | |||
---|---|---|---|
Cvss Base Score | N/A | Attack Range | N/A |
Cvss Impact Score | N/A | Attack Complexity | N/A |
Cvss Expoit Score | N/A | Authentication | N/A |
Calculate full CVSS 2.0 Vectors scores |
Detail
In the Linux kernel, the following vulnerability has been resolved: RDMA/irdma: Prevent some integer underflows My static checker complains that: drivers/infiniband/hw/irdma/ctrl.c:3605 irdma_sc_ceq_init() It appears that "info->dev->hmc_fpm_misc.max_ceqs" comes from the firmware in irdma_sc_parse_fpm_query_buf() so, yes, there is a chance that it could be zero. Even if we trust the firmware, it's easy enough to change the condition just as a hardenning measure. |
Original Source
Url : http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-49208 |
CWE : Common Weakness Enumeration
% | Id | Name |
---|---|---|
100 % | CWE-191 | Integer Underflow (Wrap or Wraparound) |
CPE : Common Platform Enumeration
Sources (Detail)
Alert History
Date | Informations |
---|---|
2025-06-26 02:09:21 |
|
2025-06-25 12:22:12 |
|
2025-06-24 02:13:58 |
|
2025-05-27 02:09:32 |
|
2025-03-29 03:14:23 |
|
2025-03-28 13:34:45 |
|
2025-03-28 02:56:51 |
|
2025-03-19 00:21:17 |
|
2025-02-26 17:20:33 |
|