CVE-2022-49820
published 2025-05-01CVE-2022-49820: In the Linux kernel, the following vulnerability has been resolved: mctp i2c: don't count unused / invalid keys for flow release We're currently hitting the…
PriorityP419medium5.5CVSS 3.1
AVLACLPRLUINSUCNINAH
EPSS
0.16%
5.6th percentile
In the Linux kernel, the following vulnerability has been resolved:
mctp i2c: don't count unused / invalid keys for flow release
We're currently hitting the WARN_ON in mctp_i2c_flow_release:
if (midev->release_count > midev->i2c_lock_count) {
WARN_ONCE(1, "release count overflow");
This may be hit if we expire a flow before sending the first packet it
contains - as we will not be pairing the increment of release_count
(performed on flow release) with the i2c lock operation (only
performed on actual TX).
To fix this, only release a flow if we've encountered it previously (ie,
dev_flow_state does not indicate NEW), as we will mark the flow as
ACTIVE at the same time as accounting for the i2c lock operation. We
also need to add an INVALID flow state, to indicate when we've done the
release.
Affected
9 ranges
| Vendor | Product | Version range | Fixed in |
|---|---|---|---|
| debian | linux | < linux 6.0.10-1 (bookworm) | linux 6.0.10-1 (bookworm) |
| linux | linux | — | — |
| linux | linux | >= f5b8abf9fc3dacd7529d363e26fe8230935d65f8 < a5915a9a3ab4067ef8996a57738d156eabeb3a12 | a5915a9a3ab4067ef8996a57738d156eabeb3a12 |
| linux | linux | >= f5b8abf9fc3dacd7529d363e26fe8230935d65f8 < 9cbd48d5fa14e4c65f8580de16686077f7cea02b | 9cbd48d5fa14e4c65f8580de16686077f7cea02b |
| linux | linux_kernel | — | — |
| linux | linux_kernel | >= 0 < 6.0.10-1 | 6.0.10-1 |
| linux | linux_kernel | >= 0 < 6.0.10-1 | 6.0.10-1 |
| linux | linux_kernel | >= 0 < 6.0.10-1 | 6.0.10-1 |
| linux | linux_kernel | >= 5.18 < 6.0.10 | 6.0.10 |
CVSS provenance
nvdv3.15.5MEDIUMCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
osv5.5MEDIUM
vendor_debian5.5MEDIUM
vendor_redhat5.5MEDIUM
Stop checking back — get the weekly exploitation signal.
Every Monday: what got weaponized or added to CISA KEV in the last seven days — each CVE cross-linked to its PoC, Nuclei template, and detection rule. Free, one email a week, unsubscribe in one click.
GHSA
GHSA-whp8-mg46-9399: In the Linux kernel, the following vulnerability has been resolved:
mctp i2c: don't count unused / invalid keys for flow release
We're currently hit
ghsa_unreviewed·2025-05-01
CVE-2022-49820 [MEDIUM] GHSA-whp8-mg46-9399: In the Linux kernel, the following vulnerability has been resolved:
mctp i2c: don't count unused / invalid keys for flow release
We're currently hit
In the Linux kernel, the following vulnerability has been resolved:
mctp i2c: don't count unused / invalid keys for flow release
We're currently hitting the WARN_ON in mctp_i2c_flow_release:
if (midev->release_count > midev->i2c_lock_count) {
WARN_ONCE(1, "release count overflow");
This may be hit if we expire a flow before sending the first packet it
contains - as we will not be pairing the increment of release_count
(performed on flow release) with the i2c lock operation (only
performed on actual TX).
To fix this, only release a flow if we've encountered it previously (ie,
dev_flow_state does not indicate NEW), as we will mark the flow as
ACTIVE at the same time as accounting for the i2c lock operation. We
also need to add an INVALID flow state, to indicate when we've done the
relea
OSV
CVE-2022-49820: In the Linux kernel, the following vulnerability has been resolved: mctp i2c: don't count unused / invalid keys for flow release We're currently hitti
osv·2025-05-01·CVSS 5.5
CVE-2022-49820 [MEDIUM] CVE-2022-49820: In the Linux kernel, the following vulnerability has been resolved: mctp i2c: don't count unused / invalid keys for flow release We're currently hitti
In the Linux kernel, the following vulnerability has been resolved: mctp i2c: don't count unused / invalid keys for flow release We're currently hitting the WARN_ON in mctp_i2c_flow_release: if (midev->release_count > midev->i2c_lock_count) { WARN_ONCE(1, "release count overflow"); This may be hit if we expire a flow before sending the first packet it contains - as we will not be pairing the increment of release_count (performed on flow release) with the i2c lock operation (only performed on actual TX). To fix this, only release a flow if we've encountered it previously (ie, dev_flow_state does not indicate NEW), as we will mark the flow as ACTIVE at the same time as accounting for the i2c lock operation. We also need to add an INVALID flow state, to indicate when we've done the release.
Red Hat
kernel: mctp i2c: don't count unused / invalid keys for flow release
vendor_redhat·2025-05-01·CVSS 5.5
CVE-2022-49820 [MEDIUM] kernel: mctp i2c: don't count unused / invalid keys for flow release
kernel: mctp i2c: don't count unused / invalid keys for flow release
In the Linux kernel, the following vulnerability has been resolved:
mctp i2c: don't count unused / invalid keys for flow release
We're currently hitting the WARN_ON in mctp_i2c_flow_release:
if (midev->release_count > midev->i2c_lock_count) {
WARN_ONCE(1, "release count overflow");
This may be hit if we expire a flow before sending the first packet it
contains - as we will not be pairing the increment of release_count
(performed on flow release) with the i2c lock operation (only
performed on actual TX).
To fix this, only release a flow if we've encountered it previously (ie,
dev_flow_state does not indicate NEW), as we will mark the flow as
ACTIVE at the same time as accounting for the i2c lock operation. We
also need to
Debian
CVE-2022-49820: linux - In the Linux kernel, the following vulnerability has been resolved: mctp i2c: d...
vendor_debian·2022·CVSS 5.5
CVE-2022-49820 [MEDIUM] CVE-2022-49820: linux - In the Linux kernel, the following vulnerability has been resolved: mctp i2c: d...
In the Linux kernel, the following vulnerability has been resolved: mctp i2c: don't count unused / invalid keys for flow release We're currently hitting the WARN_ON in mctp_i2c_flow_release: if (midev->release_count > midev->i2c_lock_count) { WARN_ONCE(1, "release count overflow"); This may be hit if we expire a flow before sending the first packet it contains - as we will not be pairing the increment of release_count (performed on flow release) with the i2c lock operation (only performed on actual TX). To fix this, only release a flow if we've encountered it previously (ie, dev_flow_state does not indicate NEW), as we will mark the flow as ACTIVE at the same time as accounting for the i2c lock operation. We also need to add an INVALID flow state, to indicate when we've done the release.
S
No detection rules found.
No public exploits indexed.
2025-05-01
Published