RHSA-2024:4211
Vulnerability from csaf_redhat - Published: 2024-07-02 09:02 - Updated: 2026-09-10 12:49A vulnerability was found in Linux Kernel, where Bluetooth BR/EDR PIN Pairing procedure is vulnerable to an impersonation attack. When an attacker connects to a victim device using the address of the device and the victim initiates a Pairing, the attacker can reflect the encrypted nonce even without knowledge of the key.
| Product | Identifier | Version | Remediation |
|---|---|---|---|
| Unresolved product id: BaseOS-8.10.0.Z.MAIN.EUS:bpftool-0:4.18.0-553.8.1.el8_10.aarch64 | — |
Vendor Fix
fix
Workaround
|
|
| Unresolved product id: BaseOS-8.10.0.Z.MAIN.EUS:bpftool-0:4.18.0-553.8.1.el8_10.ppc64le | — |
Vendor Fix
fix
Workaround
|
|
| Unresolved product id: BaseOS-8.10.0.Z.MAIN.EUS:bpftool-0:4.18.0-553.8.1.el8_10.s390x | — |
Vendor Fix
fix
Workaround
|
|
| Unresolved product id: BaseOS-8.10.0.Z.MAIN.EUS:bpftool-0:4.18.0-553.8.1.el8_10.x86_64 | — |
Vendor Fix
fix
Workaround
|
|
| Unresolved product id: BaseOS-8.10.0.Z.MAIN.EUS:bpftool-debuginfo-0:4.18.0-553.8.1.el8_10.aarch64 | — |
Vendor Fix
fix
Workaround
|
|
| Unresolved product id: BaseOS-8.10.0.Z.MAIN.EUS:bpftool-debuginfo-0:4.18.0-553.8.1.el8_10.ppc64le | — |
Vendor Fix
fix
Workaround
|
|
| Unresolved product id: BaseOS-8.10.0.Z.MAIN.EUS:bpftool-debuginfo-0:4.18.0-553.8.1.el8_10.s390x | — |
Vendor Fix
fix
Workaround
|
|
| Unresolved product id: BaseOS-8.10.0.Z.MAIN.EUS:bpftool-debuginfo-0:4.18.0-553.8.1.el8_10.x86_64 | — |
Vendor Fix
fix
Workaround
|
|
| Unresolved product id: BaseOS-8.10.0.Z.MAIN.EUS:kernel-0:4.18.0-553.8.1.el8_10.aarch64 | — |
Vendor Fix
fix
Workaround
|
|
| Unresolved product id: BaseOS-8.10.0.Z.MAIN.EUS:kernel-0:4.18.0-553.8.1.el8_10.ppc64le | — |
Vendor Fix
fix
Workaround
|
|
| Unresolved product id: BaseOS-8.10.0.Z.MAIN.EUS:kernel-0:4.18.0-553.8.1.el8_10.s390x | — |
Vendor Fix
fix
Workaround
|
|
| Unresolved product id: BaseOS-8.10.0.Z.MAIN.EUS:kernel-0:4.18.0-553.8.1.el8_10.src | — |
Vendor Fix
fix
Workaround
|
|
| Unresolved product id: BaseOS-8.10.0.Z.MAIN.EUS:kernel-0:4.18.0-553.8.1.el8_10.x86_64 | — |
Vendor Fix
fix
Workaround
|
|
| Unresolved product id: BaseOS-8.10.0.Z.MAIN.EUS:kernel-abi-stablelists-0:4.18.0-553.8.1.el8_10.noarch | — |
Vendor Fix
fix
Workaround
|
|
| Unresolved product id: BaseOS-8.10.0.Z.MAIN.EUS:kernel-core-0:4.18.0-553.8.1.el8_10.aarch64 | — |
Vendor Fix
fix
Workaround
|
|
| Unresolved product id: BaseOS-8.10.0.Z.MAIN.EUS:kernel-core-0:4.18.0-553.8.1.el8_10.ppc64le | — |
Vendor Fix
fix
Workaround
|
|
| Unresolved product id: BaseOS-8.10.0.Z.MAIN.EUS:kernel-core-0:4.18.0-553.8.1.el8_10.s390x | — |
Vendor Fix
fix
Workaround
|
|
| Unresolved product id: BaseOS-8.10.0.Z.MAIN.EUS:kernel-core-0:4.18.0-553.8.1.el8_10.x86_64 | — |
Vendor Fix
fix
Workaround
|
|
| Unresolved product id: BaseOS-8.10.0.Z.MAIN.EUS:kernel-debug-0:4.18.0-553.8.1.el8_10.aarch64 | — |
Vendor Fix
fix
Workaround
|
|
| Unresolved product id: BaseOS-8.10.0.Z.MAIN.EUS:kernel-debug-0:4.18.0-553.8.1.el8_10.ppc64le | — |
Vendor Fix
fix
Workaround
|
|
| Unresolved product id: BaseOS-8.10.0.Z.MAIN.EUS:kernel-debug-0:4.18.0-553.8.1.el8_10.s390x | — |
Vendor Fix
fix
Workaround
|
|
| Unresolved product id: BaseOS-8.10.0.Z.MAIN.EUS:kernel-debug-0:4.18.0-553.8.1.el8_10.x86_64 | — |
Vendor Fix
fix
Workaround
|
|
| Unresolved product id: BaseOS-8.10.0.Z.MAIN.EUS:kernel-debug-core-0:4.18.0-553.8.1.el8_10.aarch64 | — |
Vendor Fix
fix
Workaround
|
|
| Unresolved product id: BaseOS-8.10.0.Z.MAIN.EUS:kernel-debug-core-0:4.18.0-553.8.1.el8_10.ppc64le | — |
Vendor Fix
fix
Workaround
|
|
| Unresolved product id: BaseOS-8.10.0.Z.MAIN.EUS:kernel-debug-core-0:4.18.0-553.8.1.el8_10.s390x | — |
Vendor Fix
fix
Workaround
|
|
| Unresolved product id: BaseOS-8.10.0.Z.MAIN.EUS:kernel-debug-core-0:4.18.0-553.8.1.el8_10.x86_64 | — |
Vendor Fix
fix
Workaround
|
|
| Unresolved product id: BaseOS-8.10.0.Z.MAIN.EUS:kernel-debug-debuginfo-0:4.18.0-553.8.1.el8_10.aarch64 | — |
Vendor Fix
fix
Workaround
|
|
| Unresolved product id: BaseOS-8.10.0.Z.MAIN.EUS:kernel-debug-debuginfo-0:4.18.0-553.8.1.el8_10.ppc64le | — |
Vendor Fix
fix
Workaround
|
|
| Unresolved product id: BaseOS-8.10.0.Z.MAIN.EUS:kernel-debug-debuginfo-0:4.18.0-553.8.1.el8_10.s390x | — |
Vendor Fix
fix
Workaround
|
|
| Unresolved product id: BaseOS-8.10.0.Z.MAIN.EUS:kernel-debug-debuginfo-0:4.18.0-553.8.1.el8_10.x86_64 | — |
Vendor Fix
fix
Workaround
|
|
| Unresolved product id: BaseOS-8.10.0.Z.MAIN.EUS:kernel-debug-devel-0:4.18.0-553.8.1.el8_10.aarch64 | — |
Vendor Fix
fix
Workaround
|
|
| Unresolved product id: BaseOS-8.10.0.Z.MAIN.EUS:kernel-debug-devel-0:4.18.0-553.8.1.el8_10.ppc64le | — |
Vendor Fix
fix
Workaround
|
|
| Unresolved product id: BaseOS-8.10.0.Z.MAIN.EUS:kernel-debug-devel-0:4.18.0-553.8.1.el8_10.s390x | — |
Vendor Fix
fix
Workaround
|
|
| Unresolved product id: BaseOS-8.10.0.Z.MAIN.EUS:kernel-debug-devel-0:4.18.0-553.8.1.el8_10.x86_64 | — |
Vendor Fix
fix
Workaround
|
|
| Unresolved product id: BaseOS-8.10.0.Z.MAIN.EUS:kernel-debug-modules-0:4.18.0-553.8.1.el8_10.aarch64 | — |
Vendor Fix
fix
Workaround
|
|
| Unresolved product id: BaseOS-8.10.0.Z.MAIN.EUS:kernel-debug-modules-0:4.18.0-553.8.1.el8_10.ppc64le | — |
Vendor Fix
fix
Workaround
|
|
| Unresolved product id: BaseOS-8.10.0.Z.MAIN.EUS:kernel-debug-modules-0:4.18.0-553.8.1.el8_10.s390x | — |
Vendor Fix
fix
Workaround
|
|
| Unresolved product id: BaseOS-8.10.0.Z.MAIN.EUS:kernel-debug-modules-0:4.18.0-553.8.1.el8_10.x86_64 | — |
Vendor Fix
fix
Workaround
|
|
| Unresolved product id: BaseOS-8.10.0.Z.MAIN.EUS:kernel-debug-modules-extra-0:4.18.0-553.8.1.el8_10.aarch64 | — |
Vendor Fix
fix
Workaround
|
|
| Unresolved product id: BaseOS-8.10.0.Z.MAIN.EUS:kernel-debug-modules-extra-0:4.18.0-553.8.1.el8_10.ppc64le | — |
Vendor Fix
fix
Workaround
|
|
| Unresolved product id: BaseOS-8.10.0.Z.MAIN.EUS:kernel-debug-modules-extra-0:4.18.0-553.8.1.el8_10.s390x | — |
Vendor Fix
fix
Workaround
|
|
| Unresolved product id: BaseOS-8.10.0.Z.MAIN.EUS:kernel-debug-modules-extra-0:4.18.0-553.8.1.el8_10.x86_64 | — |
Vendor Fix
fix
Workaround
|
|
| Unresolved product id: BaseOS-8.10.0.Z.MAIN.EUS:kernel-debuginfo-0:4.18.0-553.8.1.el8_10.aarch64 | — |
Vendor Fix
fix
Workaround
|
|
| Unresolved product id: BaseOS-8.10.0.Z.MAIN.EUS:kernel-debuginfo-0:4.18.0-553.8.1.el8_10.ppc64le | — |
Vendor Fix
fix
Workaround
|
|
| Unresolved product id: BaseOS-8.10.0.Z.MAIN.EUS:kernel-debuginfo-0:4.18.0-553.8.1.el8_10.s390x | — |
Vendor Fix
fix
Workaround
|
|
| Unresolved product id: BaseOS-8.10.0.Z.MAIN.EUS:kernel-debuginfo-0:4.18.0-553.8.1.el8_10.x86_64 | — |
Vendor Fix
fix
Workaround
|
|
| Unresolved product id: BaseOS-8.10.0.Z.MAIN.EUS:kernel-debuginfo-common-aarch64-0:4.18.0-553.8.1.el8_10.aarch64 | — |
Vendor Fix
fix
Workaround
|
|
| Unresolved product id: BaseOS-8.10.0.Z.MAIN.EUS:kernel-debuginfo-common-ppc64le-0:4.18.0-553.8.1.el8_10.ppc64le | — |
Vendor Fix
fix
Workaround
|
|
| Unresolved product id: BaseOS-8.10.0.Z.MAIN.EUS:kernel-debuginfo-common-s390x-0:4.18.0-553.8.1.el8_10.s390x | — |
Vendor Fix
fix
Workaround
|
|
| Unresolved product id: BaseOS-8.10.0.Z.MAIN.EUS:kernel-debuginfo-common-x86_64-0:4.18.0-553.8.1.el8_10.x86_64 | — |
Vendor Fix
fix
Workaround
|
|
| Unresolved product id: BaseOS-8.10.0.Z.MAIN.EUS:kernel-devel-0:4.18.0-553.8.1.el8_10.aarch64 | — |
Vendor Fix
fix
Workaround
|
|
| Unresolved product id: BaseOS-8.10.0.Z.MAIN.EUS:kernel-devel-0:4.18.0-553.8.1.el8_10.ppc64le | — |
Vendor Fix
fix
Workaround
|
|
| Unresolved product id: BaseOS-8.10.0.Z.MAIN.EUS:kernel-devel-0:4.18.0-553.8.1.el8_10.s390x | — |
Vendor Fix
fix
Workaround
|
|
| Unresolved product id: BaseOS-8.10.0.Z.MAIN.EUS:kernel-devel-0:4.18.0-553.8.1.el8_10.x86_64 | — |
Vendor Fix
fix
Workaround
|
|
| Unresolved product id: BaseOS-8.10.0.Z.MAIN.EUS:kernel-doc-0:4.18.0-553.8.1.el8_10.noarch | — |
Vendor Fix
fix
Workaround
|
|
| Unresolved product id: BaseOS-8.10.0.Z.MAIN.EUS:kernel-modules-0:4.18.0-553.8.1.el8_10.aarch64 | — |
Vendor Fix
fix
Workaround
|
|
| Unresolved product id: BaseOS-8.10.0.Z.MAIN.EUS:kernel-modules-0:4.18.0-553.8.1.el8_10.ppc64le | — |
Vendor Fix
fix
Workaround
|
|
| Unresolved product id: BaseOS-8.10.0.Z.MAIN.EUS:kernel-modules-0:4.18.0-553.8.1.el8_10.s390x | — |
Vendor Fix
fix
Workaround
|
|
| Unresolved product id: BaseOS-8.10.0.Z.MAIN.EUS:kernel-modules-0:4.18.0-553.8.1.el8_10.x86_64 | — |
Vendor Fix
fix
Workaround
|
|
| Unresolved product id: BaseOS-8.10.0.Z.MAIN.EUS:kernel-modules-extra-0:4.18.0-553.8.1.el8_10.aarch64 | — |
Vendor Fix
fix
Workaround
|
|
| Unresolved product id: BaseOS-8.10.0.Z.MAIN.EUS:kernel-modules-extra-0:4.18.0-553.8.1.el8_10.ppc64le | — |
Vendor Fix
fix
Workaround
|
|
| Unresolved product id: BaseOS-8.10.0.Z.MAIN.EUS:kernel-modules-extra-0:4.18.0-553.8.1.el8_10.s390x | — |
Vendor Fix
fix
Workaround
|
|
| Unresolved product id: BaseOS-8.10.0.Z.MAIN.EUS:kernel-modules-extra-0:4.18.0-553.8.1.el8_10.x86_64 | — |
Vendor Fix
fix
Workaround
|
|
| Unresolved product id: BaseOS-8.10.0.Z.MAIN.EUS:kernel-tools-0:4.18.0-553.8.1.el8_10.aarch64 | — |
Vendor Fix
fix
Workaround
|
|
| Unresolved product id: BaseOS-8.10.0.Z.MAIN.EUS:kernel-tools-0:4.18.0-553.8.1.el8_10.ppc64le | — |
Vendor Fix
fix
Workaround
|
|
| Unresolved product id: BaseOS-8.10.0.Z.MAIN.EUS:kernel-tools-0:4.18.0-553.8.1.el8_10.s390x | — |
Vendor Fix
fix
Workaround
|
|
| Unresolved product id: BaseOS-8.10.0.Z.MAIN.EUS:kernel-tools-0:4.18.0-553.8.1.el8_10.x86_64 | — |
Vendor Fix
fix
Workaround
|
|
| Unresolved product id: BaseOS-8.10.0.Z.MAIN.EUS:kernel-tools-debuginfo-0:4.18.0-553.8.1.el8_10.aarch64 | — |
Vendor Fix
fix
Workaround
|
|
| Unresolved product id: BaseOS-8.10.0.Z.MAIN.EUS:kernel-tools-debuginfo-0:4.18.0-553.8.1.el8_10.ppc64le | — |
Vendor Fix
fix
Workaround
|
|
| Unresolved product id: BaseOS-8.10.0.Z.MAIN.EUS:kernel-tools-debuginfo-0:4.18.0-553.8.1.el8_10.s390x | — |
Vendor Fix
fix
Workaround
|
|
| Unresolved product id: BaseOS-8.10.0.Z.MAIN.EUS:kernel-tools-debuginfo-0:4.18.0-553.8.1.el8_10.x86_64 | — |
Vendor Fix
fix
Workaround
|
|
| Unresolved product id: BaseOS-8.10.0.Z.MAIN.EUS:kernel-tools-libs-0:4.18.0-553.8.1.el8_10.aarch64 | — |
Vendor Fix
fix
Workaround
|
|
| Unresolved product id: BaseOS-8.10.0.Z.MAIN.EUS:kernel-tools-libs-0:4.18.0-553.8.1.el8_10.ppc64le | — |
Vendor Fix
fix
Workaround
|
|
| Unresolved product id: BaseOS-8.10.0.Z.MAIN.EUS:kernel-tools-libs-0:4.18.0-553.8.1.el8_10.x86_64 | — |
Vendor Fix
fix
Workaround
|
|
| Unresolved product id: BaseOS-8.10.0.Z.MAIN.EUS:kernel-zfcpdump-0:4.18.0-553.8.1.el8_10.s390x | — |
Vendor Fix
fix
Workaround
|
|
| Unresolved product id: BaseOS-8.10.0.Z.MAIN.EUS:kernel-zfcpdump-core-0:4.18.0-553.8.1.el8_10.s390x | — |
Vendor Fix
fix
Workaround
|
|
| Unresolved product id: BaseOS-8.10.0.Z.MAIN.EUS:kernel-zfcpdump-debuginfo-0:4.18.0-553.8.1.el8_10.s390x | — |
Vendor Fix
fix
Workaround
|
|
| Unresolved product id: BaseOS-8.10.0.Z.MAIN.EUS:kernel-zfcpdump-devel-0:4.18.0-553.8.1.el8_10.s390x | — |
Vendor Fix
fix
Workaround
|
|
| Unresolved product id: BaseOS-8.10.0.Z.MAIN.EUS:kernel-zfcpdump-modules-0:4.18.0-553.8.1.el8_10.s390x | — |
Vendor Fix
fix
Workaround
|
|
| Unresolved product id: BaseOS-8.10.0.Z.MAIN.EUS:kernel-zfcpdump-modules-extra-0:4.18.0-553.8.1.el8_10.s390x | — |
Vendor Fix
fix
Workaround
|
|
| Unresolved product id: BaseOS-8.10.0.Z.MAIN.EUS:perf-0:4.18.0-553.8.1.el8_10.aarch64 | — |
Vendor Fix
fix
Workaround
|
|
| Unresolved product id: BaseOS-8.10.0.Z.MAIN.EUS:perf-0:4.18.0-553.8.1.el8_10.ppc64le | — |
Vendor Fix
fix
Workaround
|
|
| Unresolved product id: BaseOS-8.10.0.Z.MAIN.EUS:perf-0:4.18.0-553.8.1.el8_10.s390x | — |
Vendor Fix
fix
Workaround
|
|
| Unresolved product id: BaseOS-8.10.0.Z.MAIN.EUS:perf-0:4.18.0-553.8.1.el8_10.x86_64 | — |
Vendor Fix
fix
Workaround
|
|
| Unresolved product id: BaseOS-8.10.0.Z.MAIN.EUS:perf-debuginfo-0:4.18.0-553.8.1.el8_10.aarch64 | — |
Vendor Fix
fix
Workaround
|
|
| Unresolved product id: BaseOS-8.10.0.Z.MAIN.EUS:perf-debuginfo-0:4.18.0-553.8.1.el8_10.ppc64le | — |
Vendor Fix
fix
Workaround
|
|
| Unresolved product id: BaseOS-8.10.0.Z.MAIN.EUS:perf-debuginfo-0:4.18.0-553.8.1.el8_10.s390x | — |
Vendor Fix
fix
Workaround
|
|
| Unresolved product id: BaseOS-8.10.0.Z.MAIN.EUS:perf-debuginfo-0:4.18.0-553.8.1.el8_10.x86_64 | — |
Vendor Fix
fix
Workaround
|
|
| Unresolved product id: BaseOS-8.10.0.Z.MAIN.EUS:python3-perf-0:4.18.0-553.8.1.el8_10.aarch64 | — |
Vendor Fix
fix
Workaround
|
|
| Unresolved product id: BaseOS-8.10.0.Z.MAIN.EUS:python3-perf-0:4.18.0-553.8.1.el8_10.ppc64le | — |
Vendor Fix
fix
Workaround
|
|
| Unresolved product id: BaseOS-8.10.0.Z.MAIN.EUS:python3-perf-0:4.18.0-553.8.1.el8_10.s390x | — |
Vendor Fix
fix
Workaround
|
|
| Unresolved product id: BaseOS-8.10.0.Z.MAIN.EUS:python3-perf-0:4.18.0-553.8.1.el8_10.x86_64 | — |
Vendor Fix
fix
Workaround
|
|
| Unresolved product id: BaseOS-8.10.0.Z.MAIN.EUS:python3-perf-debuginfo-0:4.18.0-553.8.1.el8_10.aarch64 | — |
Vendor Fix
fix
Workaround
|
|
| Unresolved product id: BaseOS-8.10.0.Z.MAIN.EUS:python3-perf-debuginfo-0:4.18.0-553.8.1.el8_10.ppc64le | — |
Vendor Fix
fix
Workaround
|
|
| Unresolved product id: BaseOS-8.10.0.Z.MAIN.EUS:python3-perf-debuginfo-0:4.18.0-553.8.1.el8_10.s390x | — |
Vendor Fix
fix
Workaround
|
|
| Unresolved product id: BaseOS-8.10.0.Z.MAIN.EUS:python3-perf-debuginfo-0:4.18.0-553.8.1.el8_10.x86_64 | — |
Vendor Fix
fix
Workaround
|
|
| Unresolved product id: CRB-8.10.0.Z.MAIN.EUS:bpftool-debuginfo-0:4.18.0-553.8.1.el8_10.aarch64 | — |
Vendor Fix
fix
Workaround
|
|
| Unresolved product id: CRB-8.10.0.Z.MAIN.EUS:bpftool-debuginfo-0:4.18.0-553.8.1.el8_10.ppc64le | — |
Vendor Fix
fix
Workaround
|
|
| Unresolved product id: CRB-8.10.0.Z.MAIN.EUS:bpftool-debuginfo-0:4.18.0-553.8.1.el8_10.x86_64 | — |
Vendor Fix
fix
Workaround
|
|
| Unresolved product id: CRB-8.10.0.Z.MAIN.EUS:kernel-debug-debuginfo-0:4.18.0-553.8.1.el8_10.aarch64 | — |
Vendor Fix
fix
Workaround
|
|
| Unresolved product id: CRB-8.10.0.Z.MAIN.EUS:kernel-debug-debuginfo-0:4.18.0-553.8.1.el8_10.ppc64le | — |
Vendor Fix
fix
Workaround
|
|
| Unresolved product id: CRB-8.10.0.Z.MAIN.EUS:kernel-debug-debuginfo-0:4.18.0-553.8.1.el8_10.x86_64 | — |
Vendor Fix
fix
Workaround
|
|
| Unresolved product id: CRB-8.10.0.Z.MAIN.EUS:kernel-debuginfo-0:4.18.0-553.8.1.el8_10.aarch64 | — |
Vendor Fix
fix
Workaround
|
|
| Unresolved product id: CRB-8.10.0.Z.MAIN.EUS:kernel-debuginfo-0:4.18.0-553.8.1.el8_10.ppc64le | — |
Vendor Fix
fix
Workaround
|
|
| Unresolved product id: CRB-8.10.0.Z.MAIN.EUS:kernel-debuginfo-0:4.18.0-553.8.1.el8_10.x86_64 | — |
Vendor Fix
fix
Workaround
|
|
| Unresolved product id: CRB-8.10.0.Z.MAIN.EUS:kernel-debuginfo-common-aarch64-0:4.18.0-553.8.1.el8_10.aarch64 | — |
Vendor Fix
fix
Workaround
|
|
| Unresolved product id: CRB-8.10.0.Z.MAIN.EUS:kernel-debuginfo-common-ppc64le-0:4.18.0-553.8.1.el8_10.ppc64le | — |
Vendor Fix
fix
Workaround
|
|
| Unresolved product id: CRB-8.10.0.Z.MAIN.EUS:kernel-debuginfo-common-x86_64-0:4.18.0-553.8.1.el8_10.x86_64 | — |
Vendor Fix
fix
Workaround
|
|
| Unresolved product id: CRB-8.10.0.Z.MAIN.EUS:kernel-tools-debuginfo-0:4.18.0-553.8.1.el8_10.aarch64 | — |
Vendor Fix
fix
Workaround
|
|
| Unresolved product id: CRB-8.10.0.Z.MAIN.EUS:kernel-tools-debuginfo-0:4.18.0-553.8.1.el8_10.ppc64le | — |
Vendor Fix
fix
Workaround
|
|
| Unresolved product id: CRB-8.10.0.Z.MAIN.EUS:kernel-tools-debuginfo-0:4.18.0-553.8.1.el8_10.x86_64 | — |
Vendor Fix
fix
Workaround
|
|
| Unresolved product id: CRB-8.10.0.Z.MAIN.EUS:kernel-tools-libs-devel-0:4.18.0-553.8.1.el8_10.aarch64 | — |
Vendor Fix
fix
Workaround
|
|
| Unresolved product id: CRB-8.10.0.Z.MAIN.EUS:kernel-tools-libs-devel-0:4.18.0-553.8.1.el8_10.ppc64le | — |
Vendor Fix
fix
Workaround
|
|
| Unresolved product id: CRB-8.10.0.Z.MAIN.EUS:kernel-tools-libs-devel-0:4.18.0-553.8.1.el8_10.x86_64 | — |
Vendor Fix
fix
Workaround
|
|
| Unresolved product id: CRB-8.10.0.Z.MAIN.EUS:perf-debuginfo-0:4.18.0-553.8.1.el8_10.aarch64 | — |
Vendor Fix
fix
Workaround
|
|
| Unresolved product id: CRB-8.10.0.Z.MAIN.EUS:perf-debuginfo-0:4.18.0-553.8.1.el8_10.ppc64le | — |
Vendor Fix
fix
Workaround
|
|
| Unresolved product id: CRB-8.10.0.Z.MAIN.EUS:perf-debuginfo-0:4.18.0-553.8.1.el8_10.x86_64 | — |
Vendor Fix
fix
Workaround
|
|
| Unresolved product id: CRB-8.10.0.Z.MAIN.EUS:python3-perf-debuginfo-0:4.18.0-553.8.1.el8_10.aarch64 | — |
Vendor Fix
fix
Workaround
|
|
| Unresolved product id: CRB-8.10.0.Z.MAIN.EUS:python3-perf-debuginfo-0:4.18.0-553.8.1.el8_10.ppc64le | — |
Vendor Fix
fix
Workaround
|
|
| Unresolved product id: CRB-8.10.0.Z.MAIN.EUS:python3-perf-debuginfo-0:4.18.0-553.8.1.el8_10.x86_64 | — |
Vendor Fix
fix
Workaround
|
| Product | Identifier | Version | Remediation |
|---|---|---|---|
| Unresolved product id: BaseOS-8.10.0.Z.MAIN.EUS:kernel-cross-headers-0:4.18.0-553.8.1.el8_10.aarch64 | — |
Workaround
|
|
| Unresolved product id: BaseOS-8.10.0.Z.MAIN.EUS:kernel-cross-headers-0:4.18.0-553.8.1.el8_10.ppc64le | — |
Workaround
|
|
| Unresolved product id: BaseOS-8.10.0.Z.MAIN.EUS:kernel-cross-headers-0:4.18.0-553.8.1.el8_10.s390x | — |
Workaround
|
|
| Unresolved product id: BaseOS-8.10.0.Z.MAIN.EUS:kernel-cross-headers-0:4.18.0-553.8.1.el8_10.x86_64 | — |
Workaround
|
|
| Unresolved product id: BaseOS-8.10.0.Z.MAIN.EUS:kernel-headers-0:4.18.0-553.8.1.el8_10.aarch64 | — |
Workaround
|
|
| Unresolved product id: BaseOS-8.10.0.Z.MAIN.EUS:kernel-headers-0:4.18.0-553.8.1.el8_10.ppc64le | — |
Workaround
|
|
| Unresolved product id: BaseOS-8.10.0.Z.MAIN.EUS:kernel-headers-0:4.18.0-553.8.1.el8_10.s390x | — |
Workaround
|
|
| Unresolved product id: BaseOS-8.10.0.Z.MAIN.EUS:kernel-headers-0:4.18.0-553.8.1.el8_10.x86_64 | — |
Workaround
|
A denial of service flaw was found in the ARM footbridge in the Linux Kernel. This issue may cause an oops if a PCI driver is loaded or bound after the kernel has initialized.
In the Linux kernel, the following vulnerability has been resolved: ovl: fix leaked dentry Since commit 6815f479ca90 ("ovl: use only uppermetacopy state in ovl_lookup()"), overlayfs doesn't put temporary dentry when there is a metacopy error, which leads to dentry leaks when shutting down the related superblock: overlayfs: refusing to follow metacopy origin for (/file0) ... BUG: Dentry (____ptrval____){i=3f33,n=file3} still in use (1) [unmount of overlay overlay] ... WARNING: CPU: 1 PID: 432 at umount_check.cold+0x107/0x14d CPU: 1 PID: 432 Comm: unmount-overlay Not tainted 5.12.0-rc5 #1 ... RIP: 0010:umount_check.cold+0x107/0x14d ... Call Trace: d_walk+0x28c/0x950 ? dentry_lru_isolate+0x2b0/0x2b0 ? __kasan_slab_free+0x12/0x20 do_one_tree+0x33/0x60 shrink_dcache_for_umount+0x78/0x1d0 generic_shutdown_super+0x70/0x440 kill_anon_super+0x3e/0x70 deactivate_locked_super+0xc4/0x160 deactivate_super+0xfa/0x140 cleanup_mnt+0x22e/0x370 __cleanup_mnt+0x1a/0x30 task_work_run+0x139/0x210 do_exit+0xb0c/0x2820 ? __kasan_check_read+0x1d/0x30 ? find_held_lock+0x35/0x160 ? lock_release+0x1b6/0x660 ? mm_update_next_owner+0xa20/0xa20 ? reacquire_held_locks+0x3f0/0x3f0 ? __sanitizer_cov_trace_const_cmp4+0x22/0x30 do_group_exit+0x135/0x380 __do_sys_exit_group.isra.0+0x20/0x20 __x64_sys_exit_group+0x3c/0x50 do_syscall_64+0x45/0x70 entry_SYSCALL_64_after_hwframe+0x44/0xae ... VFS: Busy inodes after unmount of overlay. Self-destruct in 5 seconds. Have a nice day... This fix has been tested with a syzkaller reproducer.
A flaw was found in the Linux kernel’s IPC system. This flaw allows an attacker to use a specially crafted program to cause a rare race condition, leading to a denial of service.
In the Linux kernel, the following vulnerability has been resolved: platform/x86: dell-smbios-wmi: Fix oops on rmmod dell_smbios init_dell_smbios_wmi() only registers the dell_smbios_wmi_driver on systems where the Dell WMI interface is supported. While exit_dell_smbios_wmi() unregisters it unconditionally, this leads to the following oops: [ 175.722921] ------------[ cut here ]------------ [ 175.722925] Unexpected driver unregister! [ 175.722939] WARNING: CPU: 1 PID: 3630 at drivers/base/driver.c:194 driver_unregister+0x38/0x40 ... [ 175.723089] Call Trace: [ 175.723094] cleanup_module+0x5/0xedd [dell_smbios] ... [ 175.723148] ---[ end trace 064c34e1ad49509d ]--- Make the unregister happen on the same condition the register happens to fix this.
CWE-99 - Improper Control of Resource Identifiers ('Resource Injection')In the Linux kernel, the following vulnerability has been resolved: net: cdc_eem: fix tx fixup skb leak when usbnet transmit a skb, eem fixup it in eem_tx_fixup(), if skb_copy_expand() failed, it return NULL, usbnet_start_xmit() will have no chance to free original skb. fix it by free orginal skb in eem_tx_fixup() first, then check skb clone status, if failed, return NULL to usbnet.
A vulnerability was found in the Linux kernel's TI TLAN driver, where the tlan_remove_one function can lead to a use-after-free issue when the driver attempts to access private data after the network device has already been freed, potentially causing system instability or crash.
A vulnerability was found in the Linux kernel's Qualcomm EMAC driver, where the emac_remove function can lead to a use-after-free issue when the driver tries to access data after the network device has been freed, causing instability and a crash in the network subsystem.
A vulnerability was found in the Linux kernel's UDF file system driver, where the udf_symlink function can dereference a NULL pointer. This occurs because the function uses a value returned from udf_tgetblk without checking if it is NULL, potentially causing system crashes if sb_getblk fails.
A vulnerability was found in the Linux kernel's mISDN driver. This issue arises during the cleanup process, where a timer handler might still be running after the driver has been removed, which can lead to a use-after-free issue, potentially causing a system crash.
In the Linux kernel, the following vulnerability has been resolved: can: peak_pci: peak_pci_remove(): fix UAF When remove the module peek_pci, referencing 'chan' again after releasing 'dev' will cause UAF. Fix this by releasing 'dev' later. The following log reveals it: [ 35.961814 ] BUG: KASAN: use-after-free in peak_pci_remove+0x16f/0x270 [peak_pci] [ 35.963414 ] Read of size 8 at addr ffff888136998ee8 by task modprobe/5537 [ 35.965513 ] Call Trace: [ 35.965718 ] dump_stack_lvl+0xa8/0xd1 [ 35.966028 ] print_address_description+0x87/0x3b0 [ 35.966420 ] kasan_report+0x172/0x1c0 [ 35.966725 ] ? peak_pci_remove+0x16f/0x270 [peak_pci] [ 35.967137 ] ? trace_irq_enable_rcuidle+0x10/0x170 [ 35.967529 ] ? peak_pci_remove+0x16f/0x270 [peak_pci] [ 35.967945 ] __asan_report_load8_noabort+0x14/0x20 [ 35.968346 ] peak_pci_remove+0x16f/0x270 [peak_pci] [ 35.968752 ] pci_device_remove+0xa9/0x250
In the Linux kernel, the following vulnerability has been resolved: usbnet: sanity check for maxpacket maxpacket of 0 makes no sense and oopses as we need to divide by it. Give up. V2: fixed typo in log and stylistic issues
In the Linux kernel, the following vulnerability has been resolved: block: null_blk: end timed out poll request When poll request is timed out, it is removed from the poll list, but not completed, so the request is leaked, and never get chance to complete. Fix the issue by ending it in timeout handler.
A flaw was found in KVM. An improper check in svm_set_x2apic_msr_interception() may allow direct access to host x2apic msrs when the guest resets its apic, potentially leading to a denial of service condition.
A flaw was found in the Linux Kernel. An improper buffer size is provided to the strncat function, which may result in an out-of-bounds write, leading to memory corruption or a denial of service.
CWE-805 - Buffer Access with Incorrect Length ValueA potential memory leak flaw was found in damon_do_test_apply_three_regions() in the Linux kernel. This issue may lead to minor memory issues, resulting in compromised availability.
CWE-401 - Missing Release of Memory after Effective LifetimeA vulnerability was found in the hwrng component of the Linux kernel, which caused a deadlock when reading from /dev/hwrng into memory and mmap-ed from /dev/hwrng. This issue is triggered by a recursive read during a page fault and allows a local, authenticated attacker to cause a denial of service.
An operation precedence flaw was found in the Linux kernel’s Mellanox Technologies networking driver. This flaw allows a local user to crash the system or potentially gain access to data that should not be accessible.
A double-free flaw was found in the Linux kernel ConnectX-4 and Connect-IB cards in the Mellanox driver. This issue could allow a local user to crash the system.
In the Linux kernel, the following vulnerability has been resolved: crypto: s390/aes - Fix buffer overread in CTR mode When processing the last block, the s390 ctr code will always read a whole block, even if there isn't a whole block of data left. Fix this by using the actual length left and copy it into a buffer first for processing.
In the Linux kernel, the following vulnerability has been resolved: powerpc/imc-pmu: Add a null pointer check in update_events_in_group() kasprintf() returns a pointer to dynamically allocated memory which can be NULL upon failure.
In the Linux kernel, the following vulnerability has been resolved: powerpc/powernv: Add a null pointer check in opal_event_init() kasprintf() returns a pointer to dynamically allocated memory which can be NULL upon failure.
In the Linux kernel, the following vulnerability has been resolved: tipc: fix kernel warning when sending SYN message When sending a SYN message, this kernel stack trace is observed: ... [ 13.396352] RIP: 0010:_copy_from_iter+0xb4/0x550 ... [ 13.398494] Call Trace: [ 13.398630] <TASK> [ 13.398630] ? __alloc_skb+0xed/0x1a0 [ 13.398630] tipc_msg_build+0x12c/0x670 [tipc] [ 13.398630] ? shmem_add_to_page_cache.isra.71+0x151/0x290 [ 13.398630] __tipc_sendmsg+0x2d1/0x710 [tipc] [ 13.398630] ? tipc_connect+0x1d9/0x230 [tipc] [ 13.398630] ? __local_bh_enable_ip+0x37/0x80 [ 13.398630] tipc_connect+0x1d9/0x230 [tipc] [ 13.398630] ? __sys_connect+0x9f/0xd0 [ 13.398630] __sys_connect+0x9f/0xd0 [ 13.398630] ? preempt_count_add+0x4d/0xa0 [ 13.398630] ? fpregs_assert_state_consistent+0x22/0x50 [ 13.398630] __x64_sys_connect+0x16/0x20 [ 13.398630] do_syscall_64+0x42/0x90 [ 13.398630] entry_SYSCALL_64_after_hwframe+0x63/0xcd It is because commit a41dad905e5a ("iov_iter: saner checks for attempt to copy to/from iterator") has introduced sanity check for copying from/to iov iterator. Lacking of copy direction from the iterator viewpoint would lead to kernel stack trace like above. This commit fixes this issue by initializing the iov iterator with the correct copy direction when sending SYN or ACK without data.
In the Linux kernel, the following vulnerability has been resolved: net/usb: kalmia: Don't pass act_len in usb_bulk_msg error path syzbot reported that act_len in kalmia_send_init_packet() is uninitialized when passing it to the first usb_bulk_msg error path. Jiri Pirko noted that it's pointless to pass it in the error path, and that the value that would be printed in the second error path would be the value of act_len from the first call to usb_bulk_msg.[1] With this in mind, let's just not pass act_len to the usb_bulk_msg error paths. 1: https://lore.kernel.org/lkml/Y9pY61y1nwTuzMOa@nanopsycho/
CWE-15 - External Control of System or Configuration SettingIn the Linux kernel, the following vulnerability has been resolved: usb: config: fix iteration issue in 'usb_get_bos_descriptor()' The BOS descriptor defines a root descriptor and is the base descriptor for accessing a family of related descriptors. Function 'usb_get_bos_descriptor()' encounters an iteration issue when skipping the 'USB_DT_DEVICE_CAPABILITY' descriptor type. This results in the same descriptor being read repeatedly. To address this issue, a 'goto' statement is introduced to ensure that the pointer and the amount read is updated correctly. This ensures that the function iterates to the next descriptor instead of reading the same descriptor repeatedly.
In the Linux kernel, the following vulnerability has been resolved: crypto: pcrypt - Fix hungtask for PADATA_RESET We found a hungtask bug in test_aead_vec_cfg as follows: INFO: task cryptomgr_test:391009 blocked for more than 120 seconds. "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. Call trace: __switch_to+0x98/0xe0 __schedule+0x6c4/0xf40 schedule+0xd8/0x1b4 schedule_timeout+0x474/0x560 wait_for_common+0x368/0x4e0 wait_for_completion+0x20/0x30 wait_for_completion+0x20/0x30 test_aead_vec_cfg+0xab4/0xd50 test_aead+0x144/0x1f0 alg_test_aead+0xd8/0x1e0 alg_test+0x634/0x890 cryptomgr_test+0x40/0x70 kthread+0x1e0/0x220 ret_from_fork+0x10/0x18 Kernel panic - not syncing: hung_task: blocked tasks For padata_do_parallel, when the return err is 0 or -EBUSY, it will call wait_for_completion(&wait->completion) in test_aead_vec_cfg. In normal case, aead_request_complete() will be called in pcrypt_aead_serial and the return err is 0 for padata_do_parallel. But, when pinst->flags is PADATA_RESET, the return err is -EBUSY for padata_do_parallel, and it won't call aead_request_complete(). Therefore, test_aead_vec_cfg will hung at wait_for_completion(&wait->completion), which will cause hungtask. The problem comes as following: (padata_do_parallel) | rcu_read_lock_bh(); | err = -EINVAL; | (padata_replace) | pinst->flags |= PADATA_RESET; err = -EBUSY | if (pinst->flags & PADATA_RESET) | rcu_read_unlock_bh() | return err In order to resolve the problem, we replace the return err -EBUSY with -EAGAIN, which means parallel_data is changing, and the caller should call it again. v3: remove retry and just change the return err. v2: introduce padata_try_do_parallel() in pcrypt_aead_encrypt and pcrypt_aead_decrypt to solve the hungtask.
In the Linux kernel, the following vulnerability has been resolved: perf/core: Bail out early if the request AUX area is out of bound When perf-record with a large AUX area, e.g 4GB, it fails with: #perf record -C 0 -m ,4G -e arm_spe_0// -- sleep 1 failed to mmap with 12 (Cannot allocate memory) and it reveals a WARNING with __alloc_pages(): ------------[ cut here ]------------ WARNING: CPU: 44 PID: 17573 at mm/page_alloc.c:5568 __alloc_pages+0x1ec/0x248 Call trace: __alloc_pages+0x1ec/0x248 __kmalloc_large_node+0xc0/0x1f8 __kmalloc_node+0x134/0x1e8 rb_alloc_aux+0xe0/0x298 perf_mmap+0x440/0x660 mmap_region+0x308/0x8a8 do_mmap+0x3c0/0x528 vm_mmap_pgoff+0xf4/0x1b8 ksys_mmap_pgoff+0x18c/0x218 __arm64_sys_mmap+0x38/0x58 invoke_syscall+0x50/0x128 el0_svc_common.constprop.0+0x58/0x188 do_el0_svc+0x34/0x50 el0_svc+0x34/0x108 el0t_64_sync_handler+0xb8/0xc0 el0t_64_sync+0x1a4/0x1a8 'rb->aux_pages' allocated by kcalloc() is a pointer array which is used to maintains AUX trace pages. The allocated page for this array is physically contiguous (and virtually contiguous) with an order of 0..MAX_ORDER. If the size of pointer array crosses the limitation set by MAX_ORDER, it reveals a WARNING. So bail out early with -ENOMEM if the request AUX area is out of bound, e.g.: #perf record -C 0 -m ,4G -e arm_spe_0// -- sleep 1 failed to mmap with 12 (Cannot allocate memory)
In the Linux kernel, the following vulnerability has been resolved: usb: typec: tcpm: Fix NULL pointer dereference in tcpm_pd_svdm() It is possible that typec_register_partner() returns ERR_PTR on failure. When port->partner is an error, a NULL pointer dereference may occur as shown below. [91222.095236][ T319] typec port0: failed to register partner (-17) ... [91225.061491][ T319] Unable to handle kernel NULL pointer dereference at virtual address 000000000000039f [91225.274642][ T319] pc : tcpm_pd_data_request+0x310/0x13fc [91225.274646][ T319] lr : tcpm_pd_data_request+0x298/0x13fc [91225.308067][ T319] Call trace: [91225.308070][ T319] tcpm_pd_data_request+0x310/0x13fc [91225.308073][ T319] tcpm_pd_rx_handler+0x100/0x9e8 [91225.355900][ T319] kthread_worker_fn+0x178/0x58c [91225.355902][ T319] kthread+0x150/0x200 [91225.355905][ T319] ret_from_fork+0x10/0x30 Add a check for port->partner to avoid dereferencing a NULL pointer.
In the Linux kernel, the following vulnerability has been resolved: can: dev: can_put_echo_skb(): don't crash kernel if can_priv::echo_skb is accessed out of bounds If the "struct can_priv::echoo_skb" is accessed out of bounds, this would cause a kernel crash. Instead, issue a meaningful warning message and return with an error.
A flaw was found in the Linux kernel. Two TCP spoofing primitives exist where an attacker can brute force the server-chosen send window by acknowledging data that was never sent, called "ghost ACKs." There are side channels that also allow the attacker to leak the otherwise secret server-chosen initial sequence number (ISN). One of these side channels leverages TCP SYN cookies.
A race condition vulnerability was found in the tls subsystem of the Linux kernel. The submitting thread that calls recvmsg/sendmsg may exit as soon as the async crypto handler calls complete(); any code past that point risks touching already freed data. This could lead to a use-after-free issue and a denial of service condition.
A flaw was found in the tls subsystem of the Linux kernel. When setting the CRYPTO_TFM_REQ_MAY_BACKLOG flag on requests to the crypto API, crypto_aead_encrypt and crypto_aead_decrypt functions can return -EBUSY instead of -EINPROGRESS in valid situations. This issue could lead to undefined behavior and a denial of service condition.
A race condition vulnerability was found in the tls subsystem of the Linux kernel. The submitting thread (recvmsg/sendmsg) may exit as soon as the async crypto handler calls complete(), which could lead to undefined behavior and a denial of service.
A failure flaw was found in the Linux kernel’s AMDGPU driver in how a user sends ioctl with an invalid address and size when using the AMD GPU. This flaw allows a local user to crash the system.
In the Linux kernel, the following vulnerability has been resolved: ppp_async: limit MRU to 64K syzbot triggered a warning [1] in __alloc_pages(): WARN_ON_ONCE_GFP(order > MAX_PAGE_ORDER, gfp) Willem fixed a similar issue in commit c0a2a1b0d631 ("ppp: limit MRU to 64K") Adopt the same sanity check for ppp_async_ioctl(PPPIOCSMRU) [1]: WARNING: CPU: 1 PID: 11 at mm/page_alloc.c:4543 __alloc_pages+0x308/0x698 mm/page_alloc.c:4543 Modules linked in: CPU: 1 PID: 11 Comm: kworker/u4:0 Not tainted 6.8.0-rc2-syzkaller-g41bccc98fb79 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023 Workqueue: events_unbound flush_to_ldisc pstate: 204000c5 (nzCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : __alloc_pages+0x308/0x698 mm/page_alloc.c:4543 lr : __alloc_pages+0xc8/0x698 mm/page_alloc.c:4537 sp : ffff800093967580 x29: ffff800093967660 x28: ffff8000939675a0 x27: dfff800000000000 x26: ffff70001272ceb4 x25: 0000000000000000 x24: ffff8000939675c0 x23: 0000000000000000 x22: 0000000000060820 x21: 1ffff0001272ceb8 x20: ffff8000939675e0 x19: 0000000000000010 x18: ffff800093967120 x17: ffff800083bded5c x16: ffff80008ac97500 x15: 0000000000000005 x14: 1ffff0001272cebc x13: 0000000000000000 x12: 0000000000000000 x11: ffff70001272cec1 x10: 1ffff0001272cec0 x9 : 0000000000000001 x8 : ffff800091c91000 x7 : 0000000000000000 x6 : 000000000000003f x5 : 00000000ffffffff x4 : 0000000000000000 x3 : 0000000000000020 x2 : 0000000000000008 x1 : 0000000000000000 x0 : ffff8000939675e0 Call trace: __alloc_pages+0x308/0x698 mm/page_alloc.c:4543 __alloc_pages_node include/linux/gfp.h:238 [inline] alloc_pages_node include/linux/gfp.h:261 [inline] __kmalloc_large_node+0xbc/0x1fc mm/slub.c:3926 __do_kmalloc_node mm/slub.c:3969 [inline] __kmalloc_node_track_caller+0x418/0x620 mm/slub.c:4001 kmalloc_reserve+0x17c/0x23c net/core/skbuff.c:590 __alloc_skb+0x1c8/0x3d8 net/core/skbuff.c:651 __netdev_alloc_skb+0xb8/0x3e8 net/core/skbuff.c:715 netdev_alloc_skb include/linux/skbuff.h:3235 [inline] dev_alloc_skb include/linux/skbuff.h:3248 [inline] ppp_async_input drivers/net/ppp/ppp_async.c:863 [inline] ppp_asynctty_receive+0x588/0x186c drivers/net/ppp/ppp_async.c:341 tty_ldisc_receive_buf+0x12c/0x15c drivers/tty/tty_buffer.c:390 tty_port_default_receive_buf+0x74/0xac drivers/tty/tty_port.c:37 receive_buf drivers/tty/tty_buffer.c:444 [inline] flush_to_ldisc+0x284/0x6e4 drivers/tty/tty_buffer.c:494 process_one_work+0x694/0x1204 kernel/workqueue.c:2633 process_scheduled_works kernel/workqueue.c:2706 [inline] worker_thread+0x938/0xef4 kernel/workqueue.c:2787 kthread+0x288/0x310 kernel/kthread.c:388 ret_from_fork+0x10/0x20 arch/arm64/kernel/entry.S:860
A use-after-free flaw was found in the Linux kernel’s IPv6 protocol functionality. This flaw allows a local user to potentially crash the system.
In the Linux kernel, the following vulnerability has been resolved: mm/swap: fix race when skipping swapcache The Linux kernel CVE team has assigned CVE-2024-26759 to this issue. Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024040304-CVE-2024-26759-45f1@gregkh/T
A use-after-free flaw was found in the Linux kernel’s Bluetooth subsystem in how it handles hardware failure when it occurs. This flaw allows a local user to potentially crash the system.
A use-after-free flaw was found in the Linux kernel’s ip_tunnel functionality when a user uses the ip_tunnel infrastructure. This flaw allows a local user to crash the system.
A flaw was found in the Linux kernel. A logical error in the Multipath TCP packet manager causes some packets intended for retransmission to be lost, resulting in a potential denial of service.
In the Linux kernel, the following vulnerability has been resolved: net/bnx2x: Prevent access to a freed page in page_pool Fix race condition leading to system crash during EEH error handling During EEH error recovery, the bnx2x driver's transmit timeout logic could cause a race condition when handling reset tasks. The bnx2x_tx_timeout() schedules reset tasks via bnx2x_sp_rtnl_task(), which ultimately leads to bnx2x_nic_unload(). In bnx2x_nic_unload() SGEs are freed using bnx2x_free_rx_sge_range(). However, this could overlap with the EEH driver's attempt to reset the device using bnx2x_io_slot_reset(), which also tries to free SGEs. This race condition can result in system crashes due to accessing freed memory locations in bnx2x_free_rx_sge() 799 static inline void bnx2x_free_rx_sge(struct bnx2x *bp, 800 struct bnx2x_fastpath *fp, u16 index) 801 { 802 struct sw_rx_page *sw_buf = &fp->rx_page_ring[index]; 803 struct page *page = sw_buf->page; .... where sw_buf was set to NULL after the call to dma_unmap_page() by the preceding thread. EEH: Beginning: 'slot_reset' PCI 0011:01:00.0#10000: EEH: Invoking bnx2x->slot_reset() bnx2x: [bnx2x_io_slot_reset:14228(eth1)]IO slot reset initializing... bnx2x 0011:01:00.0: enabling device (0140 -> 0142) bnx2x: [bnx2x_io_slot_reset:14244(eth1)]IO slot reset --> driver unload Kernel attempted to read user page (0) - exploit attempt? (uid: 0) BUG: Kernel NULL pointer dereference on read at 0x00000000 Faulting instruction address: 0xc0080000025065fc Oops: Kernel access of bad area, sig: 11 [#1] ..... Call Trace: [c000000003c67a20] [c00800000250658c] bnx2x_io_slot_reset+0x204/0x610 [bnx2x] (unreliable) [c000000003c67af0] [c0000000000518a8] eeh_report_reset+0xb8/0xf0 [c000000003c67b60] [c000000000052130] eeh_pe_report+0x180/0x550 [c000000003c67c70] [c00000000005318c] eeh_handle_normal_event+0x84c/0xa60 [c000000003c67d50] [c000000000053a84] eeh_event_handler+0xf4/0x170 [c000000003c67da0] [c000000000194c58] kthread+0x1c8/0x1d0 [c000000003c67e10] [c00000000000cf64] ret_from_kernel_thread+0x5c/0x64 To solve this issue, we need to verify page pool allocations before freeing.
In the Linux kernel, the following vulnerability has been resolved: x86/mm: Disallow vsyscall page read for copy_from_kernel_nofault() The Linux kernel CVE team has assigned CVE-2024-26906 to this issue. Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024041746-CVE-2024-26906-bb35@gregkh/T
A flaw was found in the Linux kernel's mlx5 InfiniBand driver. Certain scenarios could lead to a use-after-free issue, potentially allowing an attacker to escalate their privileges or affect system integrity or stability.
A race condition was found in drivers/crypto/intel/qat/qat_common/adf_aer.c in the Linux kernel during AER recovery.
A flaw was found in the squashfs module in the Linux kernel. A missing check of an inode number with an invalid value of zero can cause an out-of-bounds read and result in a denial of service.
A use-after-free flaw was found in the Linux kernel’s netfilter subsystem in how a user triggers the element timeout. This flaw allows a local user to crash or potentially escalate their privileges on the system.
CVE-2024-27410 is a vulnerability in the Linux kernel’s Wi-Fi subsystem, affecting the nl80211 interface. The issue occurs when a mesh ID is set while simultaneously switching the interface to mesh mode, which can overwrite critical data in the wireless device's configuration. This can lead to unexpected behavior or instability. The issue has been resolved by preventing interface type changes during mesh ID updates. Users should update their kernel to a patched version to address this issue and ensure proper system functionality.
CVE-2024-35789 is a vulnerability in the Linux kernel’s Wi-Fi subsystem (mac80211). It occurs when a station is moved out of a VLAN, and the VLAN is subsequently deleted. A reference to the deleted VLAN’s network device may remain, leading to a use-after-free condition. This can result in system instability or crashes. The issue has been resolved by ensuring that outdated references are cleared when a station changes VLANs.
A double-free vulnerability was found in the `arfs_create_groups` function in the Linux kernel's `net/mlx5e` driver. This issue could lead to memory corruption or a system crash if exploited, as freeing the same memory twice may cause undefined behavior.
In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: fix potential sta-link leak When a station is allocated, links are added but not set to valid yet (e.g. during connection to an AP MLD), we might remove the station without ever marking links valid, and leak them. Fix that.
In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: dbg-tlv: ensure NUL termination The Linux kernel CVE team has assigned CVE-2024-35845 to this issue. Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024051718-CVE-2024-35845-65bd@gregkh/T
CVE-2024-35852 addresses a memory leak in the Linux kernel's mlxsw driver, specifically within the Spectrum ACL TCAM module. The issue occurs when rehash work is canceled while pending, leading to allocated hints not being freed properly. This results in a memory leak that can degrade system performance over time. The problem has been resolved by ensuring that any associated hints are freed when the rehash work is canceled. Users should update their Linux kernel to a version that includes this fix to maintain optimal system performance.
In the Linux kernel, the following vulnerability has been resolved: mlxsw: spectrum_acl_tcam: Fix memory leak during rehash The Linux kernel CVE team has assigned CVE-2024-35853 to this issue. Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024051740-CVE-2024-35853-869a@gregkh/T
In the Linux kernel, the following vulnerability has been resolved: mlxsw: spectrum_acl_tcam: Fix possible use-after-free during rehash The Linux kernel CVE team has assigned CVE-2024-35854 to this issue. Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024051740-CVE-2024-35854-d17b@gregkh/T
In the Linux kernel, the following vulnerability has been resolved: mlxsw: spectrum_acl_tcam: Fix possible use-after-free during activity update The Linux kernel CVE team has assigned CVE-2024-35855 to this issue. Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024051741-CVE-2024-35855-c1fb@gregkh/T
In the Linux kernel, the following vulnerability has been resolved: erspan: make sure erspan_base_hdr is present in skb->head The Linux kernel CVE team has assigned CVE-2024-35888 to this issue. Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024051947-CVE-2024-35888-1e04@gregkh/T
A flaw was found in the Linux kernel's Generic Receive Offload (GRO) feature, where packets processed with a fragment list are not properly orphaned due to incorrect handling of socket references. This vulnerability can cause system instability or kernel bugs. The issue has been fixed by making sure that socket references are correctly removed during packet processing. Users should update their kernel to the patched version to mitigate this risk.
This is a vulnerability in the Linux kernel's Elastic Network Adapter (ENA) driver, which manages network interfaces on certain platforms. The driver utilizes two types of transmit (TX) queues: one for packets from the network stack and another for packets directed by XDP (eXpress Data Path) operations. The function ena_free_tx_bufs() is responsible for unmapping and freeing descriptors of uncompleted TX transactions. However, it incorrectly assumes that all TX queues handle packets from the network stack, leading to improper handling of descriptors in XDP-specific queues. This mismanagement can result in descriptors not being freed correctly, potentially causing system crashes, especially during a Virtual Function (VF) reset. The issue has been resolved by updating the driver to correctly differentiate between the two types of TX queues, ensuring proper descriptor management. Users are advised to update their Linux kernel to a version that includes this fix to maintain system stability.
In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Fix mlx5e_priv_init() cleanup flow The Linux kernel CVE team has assigned CVE-2024-35959 to this issue. Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024052019-CVE-2024-35959-6e06@gregkh/T
CVE-2024-35960 is a vulnerability in the Linux kernel's Mellanox MLX5 driver that affects flow steering rule handling. When identical rules are created and referenced multiple times, they can fail to properly link into the rule tree, leaving them uninitialized. This can cause system crashes during rule deletion due to invalid references. The issue has been fixed by ensuring all newly created rules are properly initialized and linked. Updating to a patched kernel version resolves the problem and ensures system stability.
In the Linux kernel, the following vulnerability has been resolved: i40e: Do not use WQ_MEM_RECLAIM flag for workqueue Issue reported by customer during SRIOV testing, call trace: When both i40e and the i40iw driver are loaded, a warning in check_flush_dependency is being triggered. This seems to be because of the i40e driver workqueue is allocated with the WQ_MEM_RECLAIM flag, and the i40iw one is not. Similar error was encountered on ice too and it was fixed by removing the flag. Do the same for i40e too. [Feb 9 09:08] ------------[ cut here ]------------ [ +0.000004] workqueue: WQ_MEM_RECLAIM i40e:i40e_service_task [i40e] is flushing !WQ_MEM_RECLAIM infiniband:0x0 [ +0.000060] WARNING: CPU: 0 PID: 937 at kernel/workqueue.c:2966 check_flush_dependency+0x10b/0x120 [ +0.000007] Modules linked in: snd_seq_dummy snd_hrtimer snd_seq snd_timer snd_seq_device snd soundcore nls_utf8 cifs cifs_arc4 nls_ucs2_utils rdma_cm iw_cm ib_cm cifs_md4 dns_resolver netfs qrtr rfkill sunrpc vfat fat intel_rapl_msr intel_rapl_common irdma intel_uncore_frequency intel_uncore_frequency_common ice ipmi_ssif isst_if_common skx_edac nfit libnvdimm x86_pkg_temp_thermal intel_powerclamp gnss coretemp ib_uverbs rapl intel_cstate ib_core iTCO_wdt iTCO_vendor_support acpi_ipmi mei_me ipmi_si intel_uncore ioatdma i2c_i801 joydev pcspkr mei ipmi_devintf lpc_ich intel_pch_thermal i2c_smbus ipmi_msghandler acpi_power_meter acpi_pad xfs libcrc32c ast sd_mod drm_shmem_helper t10_pi drm_kms_helper sg ixgbe drm i40e ahci crct10dif_pclmul libahci crc32_pclmul igb crc32c_intel libata ghash_clmulni_intel i2c_algo_bit mdio dca wmi dm_mirror dm_region_hash dm_log dm_mod fuse [ +0.000050] CPU: 0 PID: 937 Comm: kworker/0:3 Kdump: loaded Not tainted 6.8.0-rc2-Feb-net_dev-Qiueue-00279-gbd43c5687e05 #1 [ +0.000003] Hardware name: Intel Corporation S2600BPB/S2600BPB, BIOS SE5C620.86B.02.01.0013.121520200651 12/15/2020 [ +0.000001] Workqueue: i40e i40e_service_task [i40e] [ +0.000024] RIP: 0010:check_flush_dependency+0x10b/0x120 [ +0.000003] Code: ff 49 8b 54 24 18 48 8d 8b b0 00 00 00 49 89 e8 48 81 c6 b0 00 00 00 48 c7 c7 b0 97 fa 9f c6 05 8a cc 1f 02 01 e8 35 b3 fd ff <0f> 0b e9 10 ff ff ff 80 3d 78 cc 1f 02 00 75 94 e9 46 ff ff ff 90 [ +0.000002] RSP: 0018:ffffbd294976bcf8 EFLAGS: 00010282 [ +0.000002] RAX: 0000000000000000 RBX: ffff94d4c483c000 RCX: 0000000000000027 [ +0.000001] RDX: ffff94d47f620bc8 RSI: 0000000000000001 RDI: ffff94d47f620bc0 [ +0.000001] RBP: 0000000000000000 R08: 0000000000000000 R09: 00000000ffff7fff [ +0.000001] R10: ffffbd294976bb98 R11: ffffffffa0be65e8 R12: ffff94c5451ea180 [ +0.000001] R13: ffff94c5ab5e8000 R14: ffff94c5c20b6e05 R15: ffff94c5f1330ab0 [ +0.000001] FS: 0000000000000000(0000) GS:ffff94d47f600000(0000) knlGS:0000000000000000 [ +0.000002] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ +0.000001] CR2: 00007f9e6f1fca70 CR3: 0000000038e20004 CR4: 00000000007706f0 [ +0.000000] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ +0.000001] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ +0.000001] PKRU: 55555554 [ +0.000001] Call Trace: [ +0.000001] <TASK> [ +0.000002] ? __warn+0x80/0x130 [ +0.000003] ? check_flush_dependency+0x10b/0x120 [ +0.000002] ? report_bug+0x195/0x1a0 [ +0.000005] ? handle_bug+0x3c/0x70 [ +0.000003] ? exc_invalid_op+0x14/0x70 [ +0.000002] ? asm_exc_invalid_op+0x16/0x20 [ +0.000006] ? check_flush_dependency+0x10b/0x120 [ +0.000002] ? check_flush_dependency+0x10b/0x120 [ +0.000002] __flush_workqueue+0x126/0x3f0 [ +0.000015] ib_cache_cleanup_one+0x1c/0xe0 [ib_core] [ +0.000056] __ib_unregister_device+0x6a/0xb0 [ib_core] [ +0.000023] ib_unregister_device_and_put+0x34/0x50 [ib_core] [ +0.000020] i40iw_close+0x4b/0x90 [irdma] [ +0.000022] i40e_notify_client_of_netdev_close+0x54/0xc0 [i40e] [ +0.000035] i40e_service_task+0x126/0x190 [i40e] [ +0.000024] process_one_work+0x174/0x340 [ +0.000003] worker_th ---truncated---
In the Linux kernel, the following vulnerability has been resolved: mlxsw: spectrum_acl_tcam: Fix warning during rehash As previously explained, the rehash delayed work migrates filters from one region to another. This is done by iterating over all chunks (all the filters with the same priority) in the region and in each chunk iterating over all the filters. When the work runs out of credits it stores the current chunk and entry as markers in the per-work context so that it would know where to resume the migration from the next time the work is scheduled. Upon error, the chunk marker is reset to NULL, but without resetting the entry markers despite being relative to it. This can result in migration being resumed from an entry that does not belong to the chunk being migrated. In turn, this will eventually lead to a chunk being iterated over as if it is an entry. Because of how the two structures happen to be defined, this does not lead to KASAN splats, but to warnings such as [1]. Fix by creating a helper that resets all the markers and call it from all the places the currently only reset the chunk marker. For good measures also call it when starting a completely new rehash. Add a warning to avoid future cases. [1] WARNING: CPU: 7 PID: 1076 at drivers/net/ethernet/mellanox/mlxsw/core_acl_flex_keys.c:407 mlxsw_afk_encode+0x242/0x2f0 Modules linked in: CPU: 7 PID: 1076 Comm: kworker/7:24 Tainted: G W 6.9.0-rc3-custom-00880-g29e61d91b77b #29 Hardware name: Mellanox Technologies Ltd. MSN3700/VMOD0005, BIOS 5.11 01/06/2019 Workqueue: mlxsw_core mlxsw_sp_acl_tcam_vregion_rehash_work RIP: 0010:mlxsw_afk_encode+0x242/0x2f0 [...] Call Trace: <TASK> mlxsw_sp_acl_atcam_entry_add+0xd9/0x3c0 mlxsw_sp_acl_tcam_entry_create+0x5e/0xa0 mlxsw_sp_acl_tcam_vchunk_migrate_all+0x109/0x290 mlxsw_sp_acl_tcam_vregion_rehash_work+0x6c/0x470 process_one_work+0x151/0x370 worker_thread+0x2cb/0x3e0 kthread+0xd0/0x100 ret_from_fork+0x34/0x50 </TASK>
A vulnerability was found in the Linux kernel's mpi3mr driver in the mpi3mr_sas_port_add() function, where a lack of proper checks could lead to values that are larger than what the defined size of the num_phys field in the mr_sas_node structure being inserted, causing the field to be overwritten and potentially corrupting the structure. This issue could lead to memory corruption or crashes.
Loading 2.6 MB of JSON…
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.