RHSA-2024:9315
Vulnerability from csaf_redhat - Published: 2024-11-12 09:11 - Updated: 2026-09-13 08:43An out-of-bounds (OOB) memory access flaw was found in the i2c driver module in the Linux kernel.
| Product | Identifier | Version | Remediation |
|---|---|---|---|
| Unresolved product id: AppStream-9.5.0.GA:bpftool-debuginfo-0:7.4.0-503.11.1.el9_5.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-9.5.0.GA:bpftool-debuginfo-0:7.4.0-503.11.1.el9_5.ppc64le | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-9.5.0.GA:bpftool-debuginfo-0:7.4.0-503.11.1.el9_5.s390x | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-9.5.0.GA:bpftool-debuginfo-0:7.4.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-9.5.0.GA:kernel-64k-debug-debuginfo-0:5.14.0-503.11.1.el9_5.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-9.5.0.GA:kernel-64k-debug-devel-0:5.14.0-503.11.1.el9_5.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-9.5.0.GA:kernel-64k-debug-devel-matched-0:5.14.0-503.11.1.el9_5.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-9.5.0.GA:kernel-64k-debuginfo-0:5.14.0-503.11.1.el9_5.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-9.5.0.GA:kernel-64k-devel-0:5.14.0-503.11.1.el9_5.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-9.5.0.GA:kernel-64k-devel-matched-0:5.14.0-503.11.1.el9_5.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-9.5.0.GA:kernel-debug-debuginfo-0:5.14.0-503.11.1.el9_5.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-9.5.0.GA:kernel-debug-debuginfo-0:5.14.0-503.11.1.el9_5.ppc64le | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-9.5.0.GA:kernel-debug-debuginfo-0:5.14.0-503.11.1.el9_5.s390x | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-9.5.0.GA:kernel-debug-debuginfo-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-9.5.0.GA:kernel-debug-devel-0:5.14.0-503.11.1.el9_5.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-9.5.0.GA:kernel-debug-devel-0:5.14.0-503.11.1.el9_5.ppc64le | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-9.5.0.GA:kernel-debug-devel-0:5.14.0-503.11.1.el9_5.s390x | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-9.5.0.GA:kernel-debug-devel-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-9.5.0.GA:kernel-debug-devel-matched-0:5.14.0-503.11.1.el9_5.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-9.5.0.GA:kernel-debug-devel-matched-0:5.14.0-503.11.1.el9_5.ppc64le | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-9.5.0.GA:kernel-debug-devel-matched-0:5.14.0-503.11.1.el9_5.s390x | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-9.5.0.GA:kernel-debug-devel-matched-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-9.5.0.GA:kernel-debuginfo-0:5.14.0-503.11.1.el9_5.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-9.5.0.GA:kernel-debuginfo-0:5.14.0-503.11.1.el9_5.ppc64le | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-9.5.0.GA:kernel-debuginfo-0:5.14.0-503.11.1.el9_5.s390x | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-9.5.0.GA:kernel-debuginfo-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-9.5.0.GA:kernel-debuginfo-common-aarch64-0:5.14.0-503.11.1.el9_5.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-9.5.0.GA:kernel-debuginfo-common-ppc64le-0:5.14.0-503.11.1.el9_5.ppc64le | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-9.5.0.GA:kernel-debuginfo-common-s390x-0:5.14.0-503.11.1.el9_5.s390x | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-9.5.0.GA:kernel-debuginfo-common-x86_64-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-9.5.0.GA:kernel-devel-0:5.14.0-503.11.1.el9_5.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-9.5.0.GA:kernel-devel-0:5.14.0-503.11.1.el9_5.ppc64le | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-9.5.0.GA:kernel-devel-0:5.14.0-503.11.1.el9_5.s390x | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-9.5.0.GA:kernel-devel-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-9.5.0.GA:kernel-devel-matched-0:5.14.0-503.11.1.el9_5.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-9.5.0.GA:kernel-devel-matched-0:5.14.0-503.11.1.el9_5.ppc64le | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-9.5.0.GA:kernel-devel-matched-0:5.14.0-503.11.1.el9_5.s390x | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-9.5.0.GA:kernel-devel-matched-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-9.5.0.GA:kernel-doc-0:5.14.0-503.11.1.el9_5.noarch | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-9.5.0.GA:kernel-rt-debug-debuginfo-0:5.14.0-503.11.1.el9_5.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-9.5.0.GA:kernel-rt-debug-debuginfo-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-9.5.0.GA:kernel-rt-debuginfo-0:5.14.0-503.11.1.el9_5.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-9.5.0.GA:kernel-rt-debuginfo-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-9.5.0.GA:kernel-tools-debuginfo-0:5.14.0-503.11.1.el9_5.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-9.5.0.GA:kernel-tools-debuginfo-0:5.14.0-503.11.1.el9_5.ppc64le | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-9.5.0.GA:kernel-tools-debuginfo-0:5.14.0-503.11.1.el9_5.s390x | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-9.5.0.GA:kernel-tools-debuginfo-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-9.5.0.GA:kernel-zfcpdump-debuginfo-0:5.14.0-503.11.1.el9_5.s390x | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-9.5.0.GA:kernel-zfcpdump-devel-0:5.14.0-503.11.1.el9_5.s390x | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-9.5.0.GA:kernel-zfcpdump-devel-matched-0:5.14.0-503.11.1.el9_5.s390x | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-9.5.0.GA:libperf-debuginfo-0:5.14.0-503.11.1.el9_5.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-9.5.0.GA:libperf-debuginfo-0:5.14.0-503.11.1.el9_5.ppc64le | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-9.5.0.GA:libperf-debuginfo-0:5.14.0-503.11.1.el9_5.s390x | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-9.5.0.GA:libperf-debuginfo-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-9.5.0.GA:perf-0:5.14.0-503.11.1.el9_5.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-9.5.0.GA:perf-0:5.14.0-503.11.1.el9_5.ppc64le | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-9.5.0.GA:perf-0:5.14.0-503.11.1.el9_5.s390x | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-9.5.0.GA:perf-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-9.5.0.GA:perf-debuginfo-0:5.14.0-503.11.1.el9_5.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-9.5.0.GA:perf-debuginfo-0:5.14.0-503.11.1.el9_5.ppc64le | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-9.5.0.GA:perf-debuginfo-0:5.14.0-503.11.1.el9_5.s390x | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-9.5.0.GA:perf-debuginfo-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-9.5.0.GA:python3-perf-debuginfo-0:5.14.0-503.11.1.el9_5.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-9.5.0.GA:python3-perf-debuginfo-0:5.14.0-503.11.1.el9_5.ppc64le | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-9.5.0.GA:python3-perf-debuginfo-0:5.14.0-503.11.1.el9_5.s390x | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-9.5.0.GA:python3-perf-debuginfo-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-9.5.0.GA:rtla-0:5.14.0-503.11.1.el9_5.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-9.5.0.GA:rtla-0:5.14.0-503.11.1.el9_5.ppc64le | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-9.5.0.GA:rtla-0:5.14.0-503.11.1.el9_5.s390x | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-9.5.0.GA:rtla-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-9.5.0.GA:rv-0:5.14.0-503.11.1.el9_5.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-9.5.0.GA:rv-0:5.14.0-503.11.1.el9_5.ppc64le | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-9.5.0.GA:rv-0:5.14.0-503.11.1.el9_5.s390x | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-9.5.0.GA:rv-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:bpftool-0:7.4.0-503.11.1.el9_5.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:bpftool-0:7.4.0-503.11.1.el9_5.ppc64le | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:bpftool-0:7.4.0-503.11.1.el9_5.s390x | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:bpftool-0:7.4.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:bpftool-debuginfo-0:7.4.0-503.11.1.el9_5.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:bpftool-debuginfo-0:7.4.0-503.11.1.el9_5.ppc64le | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:bpftool-debuginfo-0:7.4.0-503.11.1.el9_5.s390x | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:bpftool-debuginfo-0:7.4.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-0:5.14.0-503.11.1.el9_5.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-0:5.14.0-503.11.1.el9_5.ppc64le | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-0:5.14.0-503.11.1.el9_5.s390x | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-0:5.14.0-503.11.1.el9_5.src | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-64k-0:5.14.0-503.11.1.el9_5.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-64k-core-0:5.14.0-503.11.1.el9_5.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-64k-debug-0:5.14.0-503.11.1.el9_5.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-64k-debug-core-0:5.14.0-503.11.1.el9_5.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-64k-debug-debuginfo-0:5.14.0-503.11.1.el9_5.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-64k-debug-modules-0:5.14.0-503.11.1.el9_5.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-64k-debug-modules-core-0:5.14.0-503.11.1.el9_5.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-64k-debug-modules-extra-0:5.14.0-503.11.1.el9_5.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-64k-debuginfo-0:5.14.0-503.11.1.el9_5.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-64k-modules-0:5.14.0-503.11.1.el9_5.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-64k-modules-core-0:5.14.0-503.11.1.el9_5.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-64k-modules-extra-0:5.14.0-503.11.1.el9_5.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-abi-stablelists-0:5.14.0-503.11.1.el9_5.noarch | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-core-0:5.14.0-503.11.1.el9_5.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-core-0:5.14.0-503.11.1.el9_5.ppc64le | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-core-0:5.14.0-503.11.1.el9_5.s390x | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-core-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-debug-0:5.14.0-503.11.1.el9_5.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-debug-0:5.14.0-503.11.1.el9_5.ppc64le | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-debug-0:5.14.0-503.11.1.el9_5.s390x | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-debug-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-debug-core-0:5.14.0-503.11.1.el9_5.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-debug-core-0:5.14.0-503.11.1.el9_5.ppc64le | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-debug-core-0:5.14.0-503.11.1.el9_5.s390x | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-debug-core-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-debug-debuginfo-0:5.14.0-503.11.1.el9_5.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-debug-debuginfo-0:5.14.0-503.11.1.el9_5.ppc64le | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-debug-debuginfo-0:5.14.0-503.11.1.el9_5.s390x | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-debug-debuginfo-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-debug-modules-0:5.14.0-503.11.1.el9_5.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-debug-modules-0:5.14.0-503.11.1.el9_5.ppc64le | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-debug-modules-0:5.14.0-503.11.1.el9_5.s390x | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-debug-modules-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-debug-modules-core-0:5.14.0-503.11.1.el9_5.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-debug-modules-core-0:5.14.0-503.11.1.el9_5.ppc64le | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-debug-modules-core-0:5.14.0-503.11.1.el9_5.s390x | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-debug-modules-core-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-debug-modules-extra-0:5.14.0-503.11.1.el9_5.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-debug-modules-extra-0:5.14.0-503.11.1.el9_5.ppc64le | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-debug-modules-extra-0:5.14.0-503.11.1.el9_5.s390x | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-debug-modules-extra-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-debug-uki-virt-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-debuginfo-0:5.14.0-503.11.1.el9_5.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-debuginfo-0:5.14.0-503.11.1.el9_5.ppc64le | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-debuginfo-0:5.14.0-503.11.1.el9_5.s390x | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-debuginfo-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-debuginfo-common-aarch64-0:5.14.0-503.11.1.el9_5.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-debuginfo-common-ppc64le-0:5.14.0-503.11.1.el9_5.ppc64le | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-debuginfo-common-s390x-0:5.14.0-503.11.1.el9_5.s390x | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-debuginfo-common-x86_64-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-modules-0:5.14.0-503.11.1.el9_5.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-modules-0:5.14.0-503.11.1.el9_5.ppc64le | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-modules-0:5.14.0-503.11.1.el9_5.s390x | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-modules-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-modules-core-0:5.14.0-503.11.1.el9_5.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-modules-core-0:5.14.0-503.11.1.el9_5.ppc64le | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-modules-core-0:5.14.0-503.11.1.el9_5.s390x | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-modules-core-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-modules-extra-0:5.14.0-503.11.1.el9_5.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-modules-extra-0:5.14.0-503.11.1.el9_5.ppc64le | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-modules-extra-0:5.14.0-503.11.1.el9_5.s390x | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-modules-extra-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-rt-debug-debuginfo-0:5.14.0-503.11.1.el9_5.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-rt-debug-debuginfo-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-rt-debuginfo-0:5.14.0-503.11.1.el9_5.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-rt-debuginfo-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-tools-0:5.14.0-503.11.1.el9_5.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-tools-0:5.14.0-503.11.1.el9_5.ppc64le | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-tools-0:5.14.0-503.11.1.el9_5.s390x | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-tools-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-tools-debuginfo-0:5.14.0-503.11.1.el9_5.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-tools-debuginfo-0:5.14.0-503.11.1.el9_5.ppc64le | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-tools-debuginfo-0:5.14.0-503.11.1.el9_5.s390x | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-tools-debuginfo-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-tools-libs-0:5.14.0-503.11.1.el9_5.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-tools-libs-0:5.14.0-503.11.1.el9_5.ppc64le | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-tools-libs-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-uki-virt-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-uki-virt-addons-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-zfcpdump-0:5.14.0-503.11.1.el9_5.s390x | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-zfcpdump-core-0:5.14.0-503.11.1.el9_5.s390x | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-zfcpdump-debuginfo-0:5.14.0-503.11.1.el9_5.s390x | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-zfcpdump-modules-0:5.14.0-503.11.1.el9_5.s390x | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-zfcpdump-modules-core-0:5.14.0-503.11.1.el9_5.s390x | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-zfcpdump-modules-extra-0:5.14.0-503.11.1.el9_5.s390x | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:libperf-debuginfo-0:5.14.0-503.11.1.el9_5.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:libperf-debuginfo-0:5.14.0-503.11.1.el9_5.ppc64le | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:libperf-debuginfo-0:5.14.0-503.11.1.el9_5.s390x | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:libperf-debuginfo-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:perf-debuginfo-0:5.14.0-503.11.1.el9_5.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:perf-debuginfo-0:5.14.0-503.11.1.el9_5.ppc64le | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:perf-debuginfo-0:5.14.0-503.11.1.el9_5.s390x | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:perf-debuginfo-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:python3-perf-0:5.14.0-503.11.1.el9_5.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:python3-perf-0:5.14.0-503.11.1.el9_5.ppc64le | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:python3-perf-0:5.14.0-503.11.1.el9_5.s390x | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:python3-perf-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:python3-perf-debuginfo-0:5.14.0-503.11.1.el9_5.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:python3-perf-debuginfo-0:5.14.0-503.11.1.el9_5.ppc64le | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:python3-perf-debuginfo-0:5.14.0-503.11.1.el9_5.s390x | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:python3-perf-debuginfo-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: CRB-9.5.0.GA:bpftool-debuginfo-0:7.4.0-503.11.1.el9_5.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: CRB-9.5.0.GA:bpftool-debuginfo-0:7.4.0-503.11.1.el9_5.ppc64le | — |
Vendor Fix
fix
|
|
| Unresolved product id: CRB-9.5.0.GA:bpftool-debuginfo-0:7.4.0-503.11.1.el9_5.s390x | — |
Vendor Fix
fix
|
|
| Unresolved product id: CRB-9.5.0.GA:bpftool-debuginfo-0:7.4.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: CRB-9.5.0.GA:kernel-64k-debug-debuginfo-0:5.14.0-503.11.1.el9_5.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: CRB-9.5.0.GA:kernel-64k-debuginfo-0:5.14.0-503.11.1.el9_5.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: CRB-9.5.0.GA:kernel-debug-debuginfo-0:5.14.0-503.11.1.el9_5.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: CRB-9.5.0.GA:kernel-debug-debuginfo-0:5.14.0-503.11.1.el9_5.ppc64le | — |
Vendor Fix
fix
|
|
| Unresolved product id: CRB-9.5.0.GA:kernel-debug-debuginfo-0:5.14.0-503.11.1.el9_5.s390x | — |
Vendor Fix
fix
|
|
| Unresolved product id: CRB-9.5.0.GA:kernel-debug-debuginfo-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: CRB-9.5.0.GA:kernel-debuginfo-0:5.14.0-503.11.1.el9_5.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: CRB-9.5.0.GA:kernel-debuginfo-0:5.14.0-503.11.1.el9_5.ppc64le | — |
Vendor Fix
fix
|
|
| Unresolved product id: CRB-9.5.0.GA:kernel-debuginfo-0:5.14.0-503.11.1.el9_5.s390x | — |
Vendor Fix
fix
|
|
| Unresolved product id: CRB-9.5.0.GA:kernel-debuginfo-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: CRB-9.5.0.GA:kernel-debuginfo-common-aarch64-0:5.14.0-503.11.1.el9_5.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: CRB-9.5.0.GA:kernel-debuginfo-common-ppc64le-0:5.14.0-503.11.1.el9_5.ppc64le | — |
Vendor Fix
fix
|
|
| Unresolved product id: CRB-9.5.0.GA:kernel-debuginfo-common-s390x-0:5.14.0-503.11.1.el9_5.s390x | — |
Vendor Fix
fix
|
|
| Unresolved product id: CRB-9.5.0.GA:kernel-debuginfo-common-x86_64-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: CRB-9.5.0.GA:kernel-rt-debug-debuginfo-0:5.14.0-503.11.1.el9_5.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: CRB-9.5.0.GA:kernel-rt-debug-debuginfo-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: CRB-9.5.0.GA:kernel-rt-debuginfo-0:5.14.0-503.11.1.el9_5.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: CRB-9.5.0.GA:kernel-rt-debuginfo-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: CRB-9.5.0.GA:kernel-tools-debuginfo-0:5.14.0-503.11.1.el9_5.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: CRB-9.5.0.GA:kernel-tools-debuginfo-0:5.14.0-503.11.1.el9_5.ppc64le | — |
Vendor Fix
fix
|
|
| Unresolved product id: CRB-9.5.0.GA:kernel-tools-debuginfo-0:5.14.0-503.11.1.el9_5.s390x | — |
Vendor Fix
fix
|
|
| Unresolved product id: CRB-9.5.0.GA:kernel-tools-debuginfo-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: CRB-9.5.0.GA:kernel-tools-libs-devel-0:5.14.0-503.11.1.el9_5.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: CRB-9.5.0.GA:kernel-tools-libs-devel-0:5.14.0-503.11.1.el9_5.ppc64le | — |
Vendor Fix
fix
|
|
| Unresolved product id: CRB-9.5.0.GA:kernel-tools-libs-devel-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: CRB-9.5.0.GA:kernel-zfcpdump-debuginfo-0:5.14.0-503.11.1.el9_5.s390x | — |
Vendor Fix
fix
|
|
| Unresolved product id: CRB-9.5.0.GA:libperf-0:5.14.0-503.11.1.el9_5.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: CRB-9.5.0.GA:libperf-0:5.14.0-503.11.1.el9_5.ppc64le | — |
Vendor Fix
fix
|
|
| Unresolved product id: CRB-9.5.0.GA:libperf-0:5.14.0-503.11.1.el9_5.s390x | — |
Vendor Fix
fix
|
|
| Unresolved product id: CRB-9.5.0.GA:libperf-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: CRB-9.5.0.GA:libperf-debuginfo-0:5.14.0-503.11.1.el9_5.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: CRB-9.5.0.GA:libperf-debuginfo-0:5.14.0-503.11.1.el9_5.ppc64le | — |
Vendor Fix
fix
|
|
| Unresolved product id: CRB-9.5.0.GA:libperf-debuginfo-0:5.14.0-503.11.1.el9_5.s390x | — |
Vendor Fix
fix
|
|
| Unresolved product id: CRB-9.5.0.GA:libperf-debuginfo-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: CRB-9.5.0.GA:perf-debuginfo-0:5.14.0-503.11.1.el9_5.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: CRB-9.5.0.GA:perf-debuginfo-0:5.14.0-503.11.1.el9_5.ppc64le | — |
Vendor Fix
fix
|
|
| Unresolved product id: CRB-9.5.0.GA:perf-debuginfo-0:5.14.0-503.11.1.el9_5.s390x | — |
Vendor Fix
fix
|
|
| Unresolved product id: CRB-9.5.0.GA:perf-debuginfo-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: CRB-9.5.0.GA:python3-perf-debuginfo-0:5.14.0-503.11.1.el9_5.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: CRB-9.5.0.GA:python3-perf-debuginfo-0:5.14.0-503.11.1.el9_5.ppc64le | — |
Vendor Fix
fix
|
|
| Unresolved product id: CRB-9.5.0.GA:python3-perf-debuginfo-0:5.14.0-503.11.1.el9_5.s390x | — |
Vendor Fix
fix
|
|
| Unresolved product id: CRB-9.5.0.GA:python3-perf-debuginfo-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: NFV-9.5.0.GA:bpftool-debuginfo-0:7.4.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: NFV-9.5.0.GA:kernel-debug-debuginfo-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: NFV-9.5.0.GA:kernel-debuginfo-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: NFV-9.5.0.GA:kernel-debuginfo-common-x86_64-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: NFV-9.5.0.GA:kernel-rt-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: NFV-9.5.0.GA:kernel-rt-core-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: NFV-9.5.0.GA:kernel-rt-debug-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: NFV-9.5.0.GA:kernel-rt-debug-core-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: NFV-9.5.0.GA:kernel-rt-debug-debuginfo-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: NFV-9.5.0.GA:kernel-rt-debug-devel-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: NFV-9.5.0.GA:kernel-rt-debug-kvm-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: NFV-9.5.0.GA:kernel-rt-debug-modules-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: NFV-9.5.0.GA:kernel-rt-debug-modules-core-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: NFV-9.5.0.GA:kernel-rt-debug-modules-extra-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: NFV-9.5.0.GA:kernel-rt-debuginfo-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: NFV-9.5.0.GA:kernel-rt-devel-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: NFV-9.5.0.GA:kernel-rt-kvm-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: NFV-9.5.0.GA:kernel-rt-modules-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: NFV-9.5.0.GA:kernel-rt-modules-core-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: NFV-9.5.0.GA:kernel-rt-modules-extra-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: NFV-9.5.0.GA:kernel-tools-debuginfo-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: NFV-9.5.0.GA:libperf-debuginfo-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: NFV-9.5.0.GA:perf-debuginfo-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: NFV-9.5.0.GA:python3-perf-debuginfo-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: RT-9.5.0.GA:bpftool-debuginfo-0:7.4.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: RT-9.5.0.GA:kernel-debug-debuginfo-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: RT-9.5.0.GA:kernel-debuginfo-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: RT-9.5.0.GA:kernel-debuginfo-common-x86_64-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: RT-9.5.0.GA:kernel-rt-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: RT-9.5.0.GA:kernel-rt-core-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: RT-9.5.0.GA:kernel-rt-debug-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: RT-9.5.0.GA:kernel-rt-debug-core-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: RT-9.5.0.GA:kernel-rt-debug-debuginfo-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: RT-9.5.0.GA:kernel-rt-debug-devel-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: RT-9.5.0.GA:kernel-rt-debug-modules-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: RT-9.5.0.GA:kernel-rt-debug-modules-core-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: RT-9.5.0.GA:kernel-rt-debug-modules-extra-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: RT-9.5.0.GA:kernel-rt-debuginfo-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: RT-9.5.0.GA:kernel-rt-devel-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: RT-9.5.0.GA:kernel-rt-modules-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: RT-9.5.0.GA:kernel-rt-modules-core-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: RT-9.5.0.GA:kernel-rt-modules-extra-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: RT-9.5.0.GA:kernel-tools-debuginfo-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: RT-9.5.0.GA:libperf-debuginfo-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: RT-9.5.0.GA:perf-debuginfo-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: RT-9.5.0.GA:python3-perf-debuginfo-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
| Product | Identifier | Version | Remediation |
|---|---|---|---|
| Unresolved product id: AppStream-9.5.0.GA:kernel-headers-0:5.14.0-503.11.1.el9_5.aarch64 | — | ||
| Unresolved product id: AppStream-9.5.0.GA:kernel-headers-0:5.14.0-503.11.1.el9_5.ppc64le | — | ||
| Unresolved product id: AppStream-9.5.0.GA:kernel-headers-0:5.14.0-503.11.1.el9_5.s390x | — | ||
| Unresolved product id: AppStream-9.5.0.GA:kernel-headers-0:5.14.0-503.11.1.el9_5.x86_64 | — | ||
| Unresolved product id: CRB-9.5.0.GA:kernel-cross-headers-0:5.14.0-503.11.1.el9_5.aarch64 | — | ||
| Unresolved product id: CRB-9.5.0.GA:kernel-cross-headers-0:5.14.0-503.11.1.el9_5.ppc64le | — | ||
| Unresolved product id: CRB-9.5.0.GA:kernel-cross-headers-0:5.14.0-503.11.1.el9_5.s390x | — | ||
| Unresolved product id: CRB-9.5.0.GA:kernel-cross-headers-0:5.14.0-503.11.1.el9_5.x86_64 | — |
A flaw was discovered in the Bluetooth protocol affecting the Bluetooth BR/EDR authentication. An attacker with physical access to the Bluetooth connection could perform a spoofing attack impersonating the address of a previously paired remote device. This attack may result in the attacking device completing the authentication procedure successfully despite not possessing the link key. This flaw, in turn, could permit an attacker to initiate the Bluetooth Key Negotiation (KNOB) attack more efficiently, potentially gaining full access as the remote paired device.
In the Linux kernel, the following vulnerability has been resolved: hwmon: (lm90) Prevent integer overflow/underflow in hysteresis calculations Commit b50aa49638c7 ("hwmon: (lm90) Prevent integer underflows of temperature calculations") addressed a number of underflow situations when writing temperature limits. However, it missed one situation, seen when an attempt is made to set the hysteresis value to MAX_LONG and the critical temperature limit is negative. Use clamp_val() when setting the hysteresis temperature to ensure that the provided value can never overflow or underflow.
In the Linux kernel, the following vulnerability has been resolved: asix: fix uninit-value in asix_mdio_read() asix_read_cmd() may read less than sizeof(smsr) bytes and in this case smsr will be uninitialized. Fail log: BUG: KMSAN: uninit-value in asix_check_host_enable drivers/net/usb/asix_common.c:82 [inline] BUG: KMSAN: uninit-value in asix_check_host_enable drivers/net/usb/asix_common.c:82 [inline] drivers/net/usb/asix_common.c:497 BUG: KMSAN: uninit-value in asix_mdio_read+0x3c1/0xb00 drivers/net/usb/asix_common.c:497 drivers/net/usb/asix_common.c:497 asix_check_host_enable drivers/net/usb/asix_common.c:82 [inline] asix_check_host_enable drivers/net/usb/asix_common.c:82 [inline] drivers/net/usb/asix_common.c:497 asix_mdio_read+0x3c1/0xb00 drivers/net/usb/asix_common.c:497 drivers/net/usb/asix_common.c:497
In the Linux kernel, the following vulnerability has been resolved: tty: tty_buffer: Fix the softlockup issue in flush_to_ldisc When running ltp testcase(ltp/testcases/kernel/pty/pty04.c) with arm64, there is a soft lockup, which look like this one: Workqueue: events_unbound flush_to_ldisc Call trace: dump_backtrace+0x0/0x1ec show_stack+0x24/0x30 dump_stack+0xd0/0x128 panic+0x15c/0x374 watchdog_timer_fn+0x2b8/0x304 __run_hrtimer+0x88/0x2c0 __hrtimer_run_queues+0xa4/0x120 hrtimer_interrupt+0xfc/0x270 arch_timer_handler_phys+0x40/0x50 handle_percpu_devid_irq+0x94/0x220 __handle_domain_irq+0x88/0xf0 gic_handle_irq+0x84/0xfc el1_irq+0xc8/0x180 slip_unesc+0x80/0x214 [slip] tty_ldisc_receive_buf+0x64/0x80 tty_port_default_receive_buf+0x50/0x90 flush_to_ldisc+0xbc/0x110 process_one_work+0x1d4/0x4b0 worker_thread+0x180/0x430 kthread+0x11c/0x120 In the testcase pty04, The first process call the write syscall to send data to the pty master. At the same time, the workqueue will do the flush_to_ldisc to pop data in a loop until there is no more data left. When the sender and workqueue running in different core, the sender sends data fastly in full time which will result in workqueue doing work in loop for a long time and occuring softlockup in flush_to_ldisc with kernel configured without preempt. So I add need_resched check and cond_resched in the flush_to_ldisc loop to avoid it.
A vulnerability was found in the Linux kernel's hwmon driver for the w83793 module where NULL pointer dereference caused by an obsolete structure field lm75[]. During specific device read operations, if certain values are read from the device, the driver could attempt to access a NULL pointer, leading to potential system crashes or instability.
A vulnerability was found in the Linux kernel's hwmon driver in the w83791d module where the driver performs a read operation, which can result in a NULL pointer dereference. This occurs due to an unnecessary field (lm75[]) that is no longer needed after updates to device handling functions, the driver could attempt to access a NULL pointer, leading to potential system crashes.
In the Linux kernel, the following vulnerability has been resolved: powerpc/64s: fix program check interrupt emergency stack path Emergency stack path was jumping into a 3: label inside the __GEN_COMMON_BODY macro for the normal path after it had finished, rather than jumping over it. By a small miracle this is the correct place to build up a new interrupt frame with the existing stack pointer, so things basically worked okay with an added weird looking 700 trap frame on top (which had the wrong ->nip so it didn't decode bug messages either). Fix this by avoiding using numeric labels when jumping over non-trivial macros. Before: LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA PowerNV Modules linked in: CPU: 0 PID: 88 Comm: sh Not tainted 5.15.0-rc2-00034-ge057cdade6e5 #2637 NIP: 7265677368657265 LR: c00000000006c0c8 CTR: c0000000000097f0 REGS: c0000000fffb3a50 TRAP: 0700 Not tainted MSR: 9000000000021031 <SF,HV,ME,IR,DR,LE> CR: 00000700 XER: 20040000 CFAR: c0000000000098b0 IRQMASK: 0 GPR00: c00000000006c964 c0000000fffb3cf0 c000000001513800 0000000000000000 GPR04: 0000000048ab0778 0000000042000000 0000000000000000 0000000000001299 GPR08: 000001e447c718ec 0000000022424282 0000000000002710 c00000000006bee8 GPR12: 9000000000009033 c0000000016b0000 00000000000000b0 0000000000000001 GPR16: 0000000000000000 0000000000000002 0000000000000000 0000000000000ff8 GPR20: 0000000000001fff 0000000000000007 0000000000000080 00007fff89d90158 GPR24: 0000000002000000 0000000002000000 0000000000000255 0000000000000300 GPR28: c000000001270000 0000000042000000 0000000048ab0778 c000000080647e80 NIP [7265677368657265] 0x7265677368657265 LR [c00000000006c0c8] ___do_page_fault+0x3f8/0xb10 Call Trace: [c0000000fffb3cf0] [c00000000000bdac] soft_nmi_common+0x13c/0x1d0 (unreliable) --- interrupt: 700 at decrementer_common_virt+0xb8/0x230 NIP: c0000000000098b8 LR: c00000000006c0c8 CTR: c0000000000097f0 REGS: c0000000fffb3d60 TRAP: 0700 Not tainted MSR: 9000000000021031 <SF,HV,ME,IR,DR,LE> CR: 22424282 XER: 20040000 CFAR: c0000000000098b0 IRQMASK: 0 GPR00: c00000000006c964 0000000000002400 c000000001513800 0000000000000000 GPR04: 0000000048ab0778 0000000042000000 0000000000000000 0000000000001299 GPR08: 000001e447c718ec 0000000022424282 0000000000002710 c00000000006bee8 GPR12: 9000000000009033 c0000000016b0000 00000000000000b0 0000000000000001 GPR16: 0000000000000000 0000000000000002 0000000000000000 0000000000000ff8 GPR20: 0000000000001fff 0000000000000007 0000000000000080 00007fff89d90158 GPR24: 0000000002000000 0000000002000000 0000000000000255 0000000000000300 GPR28: c000000001270000 0000000042000000 0000000048ab0778 c000000080647e80 NIP [c0000000000098b8] decrementer_common_virt+0xb8/0x230 LR [c00000000006c0c8] ___do_page_fault+0x3f8/0xb10 --- interrupt: 700 Instruction dump: XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX ---[ end trace 6d28218e0cc3c949 ]--- After: ------------[ cut here ]------------ kernel BUG at arch/powerpc/kernel/exceptions-64s.S:491! Oops: Exception in kernel mode, sig: 5 [#1] LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA PowerNV Modules linked in: CPU: 0 PID: 88 Comm: login Not tainted 5.15.0-rc2-00034-ge057cdade6e5-dirty #2638 NIP: c0000000000098b8 LR: c00000000006bf04 CTR: c0000000000097f0 REGS: c0000000fffb3d60 TRAP: 0700 Not tainted MSR: 9000000000021031 <SF,HV,ME,IR,DR,LE> CR: 24482227 XER: 00040000 CFAR: c0000000000098b0 IRQMASK: 0 GPR00: c00000000006bf04 0000000000002400 c000000001513800 c000000001271868 GPR04: 00000000100f0d29 0000000042000000 0000000000000007 0000000000000009 GPR08: 00000000100f0d29 0000000024482227 0000000000002710 c000000000181b3c GPR12: 9000000000009033 c0000000016b0000 00000000100f0d29 c000000005b22f00 GPR16: 00000000ffff0000 0000000000000001 0000000000000009 00000000100eed90 GPR20: 00000000100eed90 00000 ---truncated---
In the Linux kernel, the following vulnerability has been resolved: powerpc/64s: Fix unrecoverable MCE calling async handler from NMI The machine check handler is not considered NMI on 64s. The early handler is the true NMI handler, and then it schedules the machine_check_exception handler to run when interrupts are enabled. This works fine except the case of an unrecoverable MCE, where the true NMI is taken when MSR[RI] is clear, it can not recover, so it calls machine_check_exception directly so something might be done about it. Calling an async handler from NMI context can result in irq state and other things getting corrupted. This can also trigger the BUG at arch/powerpc/include/asm/interrupt.h:168 BUG_ON(!arch_irq_disabled_regs(regs) && !(regs->msr & MSR_EE)); Fix this by making an _async version of the handler which is called in the normal case, and a NMI version that is called for unrecoverable interrupts.
In the Linux kernel, the following vulnerability has been resolved: lib/generic-radix-tree.c: Don't overflow in peek() When we started spreading new inode numbers throughout most of the 64 bit inode space, that triggered some corner case bugs, in particular some integer overflows related to the radix tree code. Oops.
A vulnerability was found in the Linux kernel's powerpc/smp architecture, where the idle task's preemption count was incorrectly decremented during the CPU offline process. This issue caused a "scheduling while atomic" error when a CPU was offlined and then onlined again, leading to potential system instability.
In the Linux kernel, the following vulnerability has been resolved: can: isotp: isotp_sendmsg(): add result check for wait_event_interruptible() Using wait_event_interruptible() to wait for complete transmission, but do not check the result of wait_event_interruptible() which can be interrupted. It will result in TX buffer has multiple accessors and the later process interferes with the previous process. Following is one of the problems reported by syzbot. ============================================================= WARNING: CPU: 0 PID: 0 at net/can/isotp.c:840 isotp_tx_timer_handler+0x2e0/0x4c0 CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.13.0-rc7+ #68 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1 04/01/2014 RIP: 0010:isotp_tx_timer_handler+0x2e0/0x4c0 Call Trace: <IRQ> ? isotp_setsockopt+0x390/0x390 __hrtimer_run_queues+0xb8/0x610 hrtimer_run_softirq+0x91/0xd0 ? rcu_read_lock_sched_held+0x4d/0x80 __do_softirq+0xe8/0x553 irq_exit_rcu+0xf8/0x100 sysvec_apic_timer_interrupt+0x9e/0xc0 </IRQ> asm_sysvec_apic_timer_interrupt+0x12/0x20 Add result check for wait_event_interruptible() in isotp_sendmsg() to avoid multiple accessers for tx buffer.
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: nvmem: Fix shift-out-of-bound (UBSAN) with byte size cells If a cell has 'nbits' equal to a multiple of BITS_PER_BYTE the logic *p &= GENMASK((cell->nbits%BITS_PER_BYTE) - 1, 0); will become undefined behavior because nbits modulo BITS_PER_BYTE is 0, and we subtract one from that making a large number that is then shifted more than the number of bits that fit into an unsigned long. UBSAN reports this problem: UBSAN: shift-out-of-bounds in drivers/nvmem/core.c:1386:8 shift exponent 64 is too large for 64-bit type 'unsigned long' CPU: 6 PID: 7 Comm: kworker/u16:0 Not tainted 5.15.0-rc3+ #9 Hardware name: Google Lazor (rev3+) with KB Backlight (DT) Workqueue: events_unbound deferred_probe_work_func Call trace: dump_backtrace+0x0/0x170 show_stack+0x24/0x30 dump_stack_lvl+0x64/0x7c dump_stack+0x18/0x38 ubsan_epilogue+0x10/0x54 __ubsan_handle_shift_out_of_bounds+0x180/0x194 __nvmem_cell_read+0x1ec/0x21c nvmem_cell_read+0x58/0x94 nvmem_cell_read_variable_common+0x4c/0xb0 nvmem_cell_read_variable_le_u32+0x40/0x100 a6xx_gpu_init+0x170/0x2f4 adreno_bind+0x174/0x284 component_bind_all+0xf0/0x264 msm_drm_bind+0x1d8/0x7a0 try_to_bring_up_master+0x164/0x1ac __component_add+0xbc/0x13c component_add+0x20/0x2c dp_display_probe+0x340/0x384 platform_probe+0xc0/0x100 really_probe+0x110/0x304 __driver_probe_device+0xb8/0x120 driver_probe_device+0x4c/0xfc __device_attach_driver+0xb0/0x128 bus_for_each_drv+0x90/0xdc __device_attach+0xc8/0x174 device_initial_probe+0x20/0x2c bus_probe_device+0x40/0xa4 deferred_probe_work_func+0x7c/0xb8 process_one_work+0x128/0x21c process_scheduled_works+0x40/0x54 worker_thread+0x1ec/0x2a8 kthread+0x138/0x158 ret_from_fork+0x10/0x20 Fix it by making sure there are any bits to mask out.
In the Linux kernel, the following vulnerability has been resolved: aio: fix use-after-free due to missing POLLFREE handling signalfd_poll() and binder_poll() are special in that they use a waitqueue whose lifetime is the current task, rather than the struct file as is normally the case. This is okay for blocking polls, since a blocking poll occurs within one task; however, non-blocking polls require another solution. This solution is for the queue to be cleared before it is freed, by sending a POLLFREE notification to all waiters. Unfortunately, only eventpoll handles POLLFREE. A second type of non-blocking poll, aio poll, was added in kernel v4.18, and it doesn't handle POLLFREE. This allows a use-after-free to occur if a signalfd or binder fd is polled with aio poll, and the waitqueue gets freed. Fix this by making aio poll handle POLLFREE. A patch by Ramji Jiyani <ramjiyani@google.com> (https://lore.kernel.org/r/20211027011834.2497484-1-ramjiyani@google.com) tried to do this by making aio_poll_wake() always complete the request inline if POLLFREE is seen. However, that solution had two bugs. First, it introduced a deadlock, as it unconditionally locked the aio context while holding the waitqueue lock, which inverts the normal locking order. Second, it didn't consider that POLLFREE notifications are missed while the request has been temporarily de-queued. The second problem was solved by my previous patch. This patch then properly fixes the use-after-free by handling POLLFREE in a deadlock-free way. It does this by taking advantage of the fact that freeing of the waitqueue is RCU-delayed, similar to what eventpoll does.
A flaw was found in the Linux kernel. A potential memleak in papr_get_attr() may lead to compromised availability.
In the Linux kernel, the following vulnerability has been resolved: of: fdt: fix off-by-one error in unflatten_dt_nodes() The Linux kernel CVE team has assigned CVE-2022-48672 to this issue. Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024050318-CVE-2022-48672-b6d9@gregkh/T
A flaw was found in the Linux kernel in the `thermal/int340x_thermal` driver. This issue occurs when the Global Device Data Vault (GDDV) returns a zero-length buffer, causing the `kmemdup()` function to return a `ZERO_SIZE_PTR` (0x10), leading to a NULL pointer dereference in `data_vault_read()`, potentially causing a kernel crash. The issue has been fixed by adding checks for `ZERO_SIZE_PTR` or `NULL` using the `ZERO_OR_NULL_PTR()` macro.
A vulnerability was found in the Linux kernel's vt_ioctl subsystem, where the vt_setactivate function can lead to a transient integer underflow due to improper handling of the vsa.console value. The vulnerability arises when an out-of-bounds value is decreased before being sanitized using array_index_nospec. This can potentially allow unauthorized access or manipulation of memory.
bpf in linux kernel incorrectly managed register types, leading to out of bounds access and possible kernel crashing when bad pointer gets dereferenced.
In the Linux kernel, the following vulnerability has been resolved: lz4: fix LZ4_decompress_safe_partial read out of bound When partialDecoding, it is EOF if we've either filled the output buffer or can't proceed with reading an offset for following match. In some extreme corner cases when compressed data is suitably corrupted, UAF will occur. As reported by KASAN [1], LZ4_decompress_safe_partial may lead to read out of bound problem during decoding. lz4 upstream has fixed it [2] and this issue has been disscussed here [3] before. current decompression routine was ported from lz4 v1.8.3, bumping lib/lz4 to v1.9.+ is certainly a huge work to be done later, so, we'd better fix it first. [1] https://lore.kernel.org/all/000000000000830d1205cf7f0477@google.com/ [2] https://github.com/lz4/lz4/commit/c5d6f8a8be3927c0bec91bcc58667a6cfad244ad# [3] https://lore.kernel.org/all/CC666AE8-4CA4-4951-B6FB-A2EFDE3AC03B@fb.com/
In the Linux kernel, the following vulnerability has been resolved: x86/mce: Work around an erratum on fast string copy instructions A rare kernel panic scenario can happen when the following conditions are met due to an erratum on fast string copy instructions: 1) An uncorrected error. 2) That error must be in first cache line of a page. 3) Kernel must execute page_copy from the page immediately before that page. The fast string copy instructions ("REP; MOVS*") could consume an uncorrectable memory error in the cache line _right after_ the desired region to copy and raise an MCE. Bit 0 of MSR_IA32_MISC_ENABLE can be cleared to disable fast string copy and will avoid such spurious machine checks. However, that is less preferable due to the permanent performance impact. Considering memory poison is rare, it's desirable to keep fast string copy enabled until an MCE is seen. Intel has confirmed the following: 1. The CPU erratum of fast string copy only applies to Skylake, Cascade Lake and Cooper Lake generations. Directly return from the MCE handler: 2. Will result in complete execution of the "REP; MOVS*" with no data loss or corruption. 3. Will not result in another MCE firing on the next poisoned cache line due to "REP; MOVS*". 4. Will resume execution from a correct point in code. 5. Will result in the same instruction that triggered the MCE firing a second MCE immediately for any other software recoverable data fetch errors. 6. Is not safe without disabling the fast string copy, as the next fast string copy of the same buffer on the same CPU would result in a PANIC MCE. This should mitigate the erratum completely with the only caveat that the fast string copy is disabled on the affected hyper thread thus performance degradation. This is still better than the OS crashing on MCEs raised on an irrelevant process due to "REP; MOVS*' accesses in a kernel context, e.g., copy_page. Injected errors on 1st cache line of 8 anonymous pages of process 'proc1' and observed MCE consumption from 'proc2' with no panic (directly returned). Without the fix, the host panicked within a few minutes on a random 'proc2' process due to kernel access from copy_page. [ bp: Fix comment style + touch ups, zap an unlikely(), improve the quirk function's readability. ]
In the Linux kernel, the following vulnerability has been resolved: af_netlink: Fix shift out of bounds in group mask calculation When a netlink message is received, netlink_recvmsg() fills in the address of the sender. One of the fields is the 32-bit bitfield nl_groups, which carries the multicast group on which the message was received. The least significant bit corresponds to group 1, and therefore the highest group that the field can represent is 32. Above that, the UB sanitizer flags the out-of-bounds shift attempts. Which bits end up being set in such case is implementation defined, but it's either going to be a wrong non-zero value, or zero, which is at least not misleading. Make the latter choice deterministic by always setting to 0 for higher-numbered multicast groups. To get information about membership in groups >= 32, userspace is expected to use nl_pktinfo control messages[0], which are enabled by NETLINK_PKTINFO socket option. [0] https://lwn.net/Articles/147608/ The way to trigger this issue is e.g. through monitoring the BRVLAN group: # bridge monitor vlan & # ip link add name br type bridge Which produces the following citation: UBSAN: shift-out-of-bounds in net/netlink/af_netlink.c:162:19 shift exponent 32 is too large for 32-bit type 'int'
In the Linux kernel, the following vulnerability has been resolved: net: asix: add proper error handling of usb read errors Syzbot once again hit uninit value in asix driver. The problem still the same -- asix_read_cmd() reads less bytes, than was requested by caller. Since all read requests are performed via asix_read_cmd() let's catch usb related error there and add __must_check notation to be sure all callers actually check return value. So, this patch adds sanity check inside asix_read_cmd(), that simply checks if bytes read are not less, than was requested and adds missing error handling of asix_read_cmd() all across the driver code.
No description is available for this CVE.
In the Linux kernel, the following vulnerability has been resolved: extcon: Modify extcon device to be created after driver data is set Currently, someone can invoke the sysfs such as state_show() intermittently before dev_set_drvdata() is done. And it can be a cause of kernel Oops because of edev is Null at that time. So modified the driver registration to after setting drviver data. - Oops's backtrace. Backtrace: [<c067865c>] (state_show) from [<c05222e8>] (dev_attr_show) [<c05222c0>] (dev_attr_show) from [<c02c66e0>] (sysfs_kf_seq_show) [<c02c6648>] (sysfs_kf_seq_show) from [<c02c496c>] (kernfs_seq_show) [<c02c4938>] (kernfs_seq_show) from [<c025e2a0>] (seq_read) [<c025e11c>] (seq_read) from [<c02c50a0>] (kernfs_fop_read) [<c02c5064>] (kernfs_fop_read) from [<c0231cac>] (__vfs_read) [<c0231c5c>] (__vfs_read) from [<c0231ee0>] (vfs_read) [<c0231e34>] (vfs_read) from [<c0232464>] (ksys_read) [<c02323f0>] (ksys_read) from [<c02324fc>] (sys_read) [<c02324e4>] (sys_read) from [<c00091d0>] (__sys_trace_return)
In the Linux kernel, the following vulnerability has been resolved: vduse: Fix NULL pointer dereference on sysfs access The control device has no drvdata. So we will get a NULL pointer dereference when accessing control device's msg_timeout attribute via sysfs: [ 132.841881][ T3644] BUG: kernel NULL pointer dereference, address: 00000000000000f8 [ 132.850619][ T3644] RIP: 0010:msg_timeout_show (drivers/vdpa/vdpa_user/vduse_dev.c:1271) [ 132.869447][ T3644] dev_attr_show (drivers/base/core.c:2094) [ 132.870215][ T3644] sysfs_kf_seq_show (fs/sysfs/file.c:59) [ 132.871164][ T3644] ? device_remove_bin_file (drivers/base/core.c:2088) [ 132.872082][ T3644] kernfs_seq_show (fs/kernfs/file.c:164) [ 132.872838][ T3644] seq_read_iter (fs/seq_file.c:230) [ 132.873578][ T3644] ? __vmalloc_area_node (mm/vmalloc.c:3041) [ 132.874532][ T3644] kernfs_fop_read_iter (fs/kernfs/file.c:238) [ 132.875513][ T3644] __kernel_read (fs/read_write.c:440 (discriminator 1)) [ 132.876319][ T3644] kernel_read (fs/read_write.c:459) [ 132.877129][ T3644] kernel_read_file (fs/kernel_read_file.c:94) [ 132.877978][ T3644] kernel_read_file_from_fd (include/linux/file.h:45 fs/kernel_read_file.c:186) [ 132.879019][ T3644] __do_sys_finit_module (kernel/module.c:4207) [ 132.879930][ T3644] __ia32_sys_finit_module (kernel/module.c:4189) [ 132.880930][ T3644] do_int80_syscall_32 (arch/x86/entry/common.c:112 arch/x86/entry/common.c:132) [ 132.881847][ T3644] entry_INT80_compat (arch/x86/entry/entry_64_compat.S:419) To fix it, don't create the unneeded attribute for control device anymore.
In the Linux kernel, the following vulnerability has been resolved: Input: gpio-keys - cancel delayed work only in case of GPIO gpio_keys module can either accept gpios or interrupts. The module initializes delayed work in case of gpios only and is only used if debounce timer is not used, so make sure cancel_delayed_work_sync() is called only when its gpio-backed and debounce_use_hrtimer is false. This fixes the issue seen below when the gpio_keys module is unloaded and an interrupt pin is used instead of GPIO: [ 360.297569] ------------[ cut here ]------------ [ 360.302303] WARNING: CPU: 0 PID: 237 at kernel/workqueue.c:3066 __flush_work+0x414/0x470 [ 360.310531] Modules linked in: gpio_keys(-) [ 360.314797] CPU: 0 PID: 237 Comm: rmmod Not tainted 5.18.0-rc5-arm64-renesas-00116-g73636105874d-dirty #166 [ 360.324662] Hardware name: Renesas SMARC EVK based on r9a07g054l2 (DT) [ 360.331270] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 360.338318] pc : __flush_work+0x414/0x470 [ 360.342385] lr : __cancel_work_timer+0x140/0x1b0 [ 360.347065] sp : ffff80000a7fba00 [ 360.350423] x29: ffff80000a7fba00 x28: ffff000012b9c5c0 x27: 0000000000000000 [ 360.357664] x26: ffff80000a7fbb80 x25: ffff80000954d0a8 x24: 0000000000000001 [ 360.364904] x23: ffff800009757000 x22: 0000000000000000 x21: ffff80000919b000 [ 360.372143] x20: ffff00000f5974e0 x19: ffff00000f5974e0 x18: ffff8000097fcf48 [ 360.379382] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000053f40 [ 360.386622] x14: ffff800009850e88 x13: 0000000000000002 x12: 000000000000a60c [ 360.393861] x11: 000000000000a610 x10: 0000000000000000 x9 : 0000000000000008 [ 360.401100] x8 : 0101010101010101 x7 : 00000000a473c394 x6 : 0080808080808080 [ 360.408339] x5 : 0000000000000001 x4 : 0000000000000000 x3 : ffff80000919b458 [ 360.415578] x2 : ffff8000097577f0 x1 : 0000000000000001 x0 : 0000000000000000 [ 360.422818] Call trace: [ 360.425299] __flush_work+0x414/0x470 [ 360.429012] __cancel_work_timer+0x140/0x1b0 [ 360.433340] cancel_delayed_work_sync+0x10/0x18 [ 360.437931] gpio_keys_quiesce_key+0x28/0x58 [gpio_keys] [ 360.443327] devm_action_release+0x10/0x18 [ 360.447481] release_nodes+0x8c/0x1a0 [ 360.451194] devres_release_all+0x90/0x100 [ 360.455346] device_unbind_cleanup+0x14/0x60 [ 360.459677] device_release_driver_internal+0xe8/0x168 [ 360.464883] driver_detach+0x4c/0x90 [ 360.468509] bus_remove_driver+0x54/0xb0 [ 360.472485] driver_unregister+0x2c/0x58 [ 360.476462] platform_driver_unregister+0x10/0x18 [ 360.481230] gpio_keys_exit+0x14/0x828 [gpio_keys] [ 360.486088] __arm64_sys_delete_module+0x1e0/0x270 [ 360.490945] invoke_syscall+0x40/0xf8 [ 360.494661] el0_svc_common.constprop.3+0xf0/0x110 [ 360.499515] do_el0_svc+0x20/0x78 [ 360.502877] el0_svc+0x48/0xf8 [ 360.505977] el0t_64_sync_handler+0x88/0xb0 [ 360.510216] el0t_64_sync+0x148/0x14c [ 360.513930] irq event stamp: 4306 [ 360.517288] hardirqs last enabled at (4305): [<ffff8000080b0300>] __cancel_work_timer+0x130/0x1b0 [ 360.526359] hardirqs last disabled at (4306): [<ffff800008d194fc>] el1_dbg+0x24/0x88 [ 360.534204] softirqs last enabled at (4278): [<ffff8000080104a0>] _stext+0x4a0/0x5e0 [ 360.542133] softirqs last disabled at (4267): [<ffff8000080932ac>] irq_exit_rcu+0x18c/0x1b0 [ 360.550591] ---[ end trace 0000000000000000 ]---
In the Linux kernel, the following vulnerability has been resolved: x86/MCE/AMD: Fix memory leak when threshold_create_bank() fails In mce_threshold_create_device(), if threshold_create_bank() fails, the previously allocated threshold banks array @bp will be leaked because the call to mce_threshold_remove_device() will not free it. This happens because mce_threshold_remove_device() fetches the pointer through the threshold_banks per-CPU variable but bp is written there only after the bank creation is successful, and not before, when threshold_create_bank() fails. Add a helper which unwinds all the bank creation work previously done and pass into it the previously allocated threshold banks array for freeing. [ bp: Massage. ]
In the Linux kernel, the following vulnerability has been resolved: tick/nohz: unexport __init-annotated tick_nohz_full_setup() EXPORT_SYMBOL and __init is a bad combination because the .init.text section is freed up after the initialization. Hence, modules cannot use symbols annotated __init. The access to a freed symbol may end up with kernel panic. modpost used to detect it, but it had been broken for a decade. Commit 28438794aba4 ("modpost: fix section mismatch check for exported init/exit sections") fixed it so modpost started to warn it again, then this showed up: MODPOST vmlinux.symvers WARNING: modpost: vmlinux.o(___ksymtab_gpl+tick_nohz_full_setup+0x0): Section mismatch in reference from the variable __ksymtab_tick_nohz_full_setup to the function .init.text:tick_nohz_full_setup() The symbol tick_nohz_full_setup is exported and annotated __init Fix this by removing the __init annotation of tick_nohz_full_setup or drop the export. Drop the export because tick_nohz_full_setup() is only called from the built-in code in kernel/sched/isolation.c.
In the Linux kernel, the following vulnerability has been resolved: mmc: sdhci-pci: Fix possible memory leak caused by missing pci_dev_put() pci_get_device() will increase the reference count for the returned pci_dev. We need to use pci_dev_put() to decrease the reference count before amd_probe() returns. There is no problem for the 'smbus_dev == NULL' branch because pci_dev_put() can also handle the NULL input parameter case.
In the Linux kernel, the following vulnerability has been resolved: dmaengine: ti: k3-udma-glue: fix memory leak when register device fail If device_register() fails, it should call put_device() to give up reference, the name allocated in dev_set_name() can be freed in callback function kobject_cleanup().
[REJECTED CVE] In the Linux kernel, the following vulnerability has been resolved: tty: n_gsm: avoid call of sleeping functions from atomic context
In the Linux kernel, the following vulnerability has been resolved: tty: serial: Fix refcount leak bug in ucc_uart.c In soc_info(), of_find_node_by_type() will return a node pointer with refcount incremented. We should use of_node_put() when it is not used anymore.
A flaw was found in the tap module in the Linux kernel. A NULL pointer dereference can be triggered due to a missing initialization, resulting in a denial of service.
In the Linux kernel, the following vulnerability has been resolved: x86/kprobes: Update kcb status flag after singlestepping Fix kprobes to update kcb (kprobes control block) status flag to KPROBE_HIT_SSDONE even if the kp->post_handler is not set. This bug may cause a kernel panic if another INT3 user runs right after kprobes because kprobe_int3_handler() misunderstands the INT3 is kprobe's single stepping INT3.
In the Linux kernel, the following vulnerability has been resolved: mmc: sdhci-of-esdhc: Fix refcount leak in esdhc_signal_voltage_switch of_find_matching_node() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. Add missing of_node_put() to avoid refcount leak. of_node_put() checks null pointer.
In the Linux kernel, the following vulnerability has been resolved: rcutorture: Fix ksoftirqd boosting timing and iteration The RCU priority boosting can fail in two situations: 1) If (nr_cpus= > maxcpus=), which means if the total number of CPUs is higher than those brought online at boot, then torture_onoff() may later bring up CPUs that weren't online on boot. Now since rcutorture initialization only boosts the ksoftirqds of the CPUs that have been set online on boot, the CPUs later set online by torture_onoff won't benefit from the boost, making RCU priority boosting fail. 2) The ksoftirqd kthreads are boosted after the creation of rcu_torture_boost() kthreads, which opens a window large enough for these rcu_torture_boost() kthreads to wait (despite running at FIFO priority) for ksoftirqds that are still running at SCHED_NORMAL priority. The issues can trigger for example with: ./kvm.sh --configs TREE01 --kconfig "CONFIG_RCU_BOOST=y" [ 34.968561] rcu-torture: !!! [ 34.968627] ------------[ cut here ]------------ [ 35.014054] WARNING: CPU: 4 PID: 114 at kernel/rcu/rcutorture.c:1979 rcu_torture_stats_print+0x5ad/0x610 [ 35.052043] Modules linked in: [ 35.069138] CPU: 4 PID: 114 Comm: rcu_torture_sta Not tainted 5.18.0-rc1 #1 [ 35.096424] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.14.0-0-g155821a-rebuilt.opensuse.org 04/01/2014 [ 35.154570] RIP: 0010:rcu_torture_stats_print+0x5ad/0x610 [ 35.198527] Code: 63 1b 02 00 74 02 0f 0b 48 83 3d 35 63 1b 02 00 74 02 0f 0b 48 83 3d 21 63 1b 02 00 74 02 0f 0b 48 83 3d 0d 63 1b 02 00 74 02 <0f> 0b 83 eb 01 0f 8e ba fc ff ff 0f 0b e9 b3 fc ff f82 [ 37.251049] RSP: 0000:ffffa92a0050bdf8 EFLAGS: 00010202 [ 37.277320] rcu: De-offloading 8 [ 37.290367] RAX: 0000000000000000 RBX: 0000000000000001 RCX: 0000000000000001 [ 37.290387] RDX: 0000000000000000 RSI: 00000000ffffbfff RDI: 00000000ffffffff [ 37.290398] RBP: 000000000000007b R08: 0000000000000000 R09: c0000000ffffbfff [ 37.290407] R10: 000000000000002a R11: ffffa92a0050bc18 R12: ffffa92a0050be20 [ 37.290417] R13: ffffa92a0050be78 R14: 0000000000000000 R15: 000000000001bea0 [ 37.290427] FS: 0000000000000000(0000) GS:ffff96045eb00000(0000) knlGS:0000000000000000 [ 37.290448] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 37.290460] CR2: 0000000000000000 CR3: 000000001dc0c000 CR4: 00000000000006e0 [ 37.290470] Call Trace: [ 37.295049] <TASK> [ 37.295065] ? preempt_count_add+0x63/0x90 [ 37.295095] ? _raw_spin_lock_irqsave+0x12/0x40 [ 37.295125] ? rcu_torture_stats_print+0x610/0x610 [ 37.295143] rcu_torture_stats+0x29/0x70 [ 37.295160] kthread+0xe3/0x110 [ 37.295176] ? kthread_complete_and_exit+0x20/0x20 [ 37.295193] ret_from_fork+0x22/0x30 [ 37.295218] </TASK> Fix this with boosting the ksoftirqds kthreads from the boosting hotplug callback itself and before the boosting kthreads are created.
A flaw was found in the Linux kernel's mmc: vub300 module. An incorrect return value check for mmc_add_host() and a missing call to mmc_free_host() when usb_control_msg() fails can lead to memory leaks. A local attacker could exploit this vulnerability, causing the kernel to crash and resulting in a Denial of Service (DoS).
A flaw was found in the Linux kernel component mmc: moxart. A local attacker with low privileges could exploit this vulnerability by triggering an improper return value check in the mmc_add_host() function. This oversight can lead to a memory leak, which may ultimately cause a kernel crash, resulting in a Denial of Service (DoS) for the system.
In the Linux kernel, the following vulnerability has been resolved: ipc: fix memory leak in init_mqueue_fs() When setup_mq_sysctls() failed in init_mqueue_fs(), mqueue_inode_cachep is not released. In order to fix this issue, the release path is reordered.
In the Linux kernel, the following vulnerability has been resolved: drivers: serial: jsm: fix some leaks in probe This error path needs to unwind instead of just returning directly.
In the Linux kernel, the following vulnerability has been resolved: mmc: rtsx_usb_sdmmc: fix return value check of mmc_add_host() mmc_add_host() may return error, if we ignore its return value, the memory that allocated in mmc_alloc_host() will be leaked and it will lead a kernel crash because of deleting not added device in the remove path. So fix this by checking the return value and calling mmc_free_host() in the error path, besides, led_classdev_unregister() and pm_runtime_disable() also need be called.
CWE-252 - Unchecked Return ValueA flaw was found in the Linux kernel's mmc: wmt-sdmmc component. An improper return value check in the mmc_add_host() function may allow a local attacker to cause a memory leak. This can lead to a kernel crash, resulting in a Denial of Service (DoS).
| Product | Identifier | Version | Remediation |
|---|---|---|---|
| Unresolved product id: AppStream-9.5.0.GA:bpftool-debuginfo-0:7.4.0-503.11.1.el9_5.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-9.5.0.GA:bpftool-debuginfo-0:7.4.0-503.11.1.el9_5.ppc64le | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-9.5.0.GA:bpftool-debuginfo-0:7.4.0-503.11.1.el9_5.s390x | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-9.5.0.GA:bpftool-debuginfo-0:7.4.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-9.5.0.GA:kernel-64k-debug-debuginfo-0:5.14.0-503.11.1.el9_5.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-9.5.0.GA:kernel-64k-debug-devel-0:5.14.0-503.11.1.el9_5.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-9.5.0.GA:kernel-64k-debug-devel-matched-0:5.14.0-503.11.1.el9_5.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-9.5.0.GA:kernel-64k-debuginfo-0:5.14.0-503.11.1.el9_5.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-9.5.0.GA:kernel-64k-devel-0:5.14.0-503.11.1.el9_5.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-9.5.0.GA:kernel-64k-devel-matched-0:5.14.0-503.11.1.el9_5.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-9.5.0.GA:kernel-debug-debuginfo-0:5.14.0-503.11.1.el9_5.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-9.5.0.GA:kernel-debug-debuginfo-0:5.14.0-503.11.1.el9_5.ppc64le | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-9.5.0.GA:kernel-debug-debuginfo-0:5.14.0-503.11.1.el9_5.s390x | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-9.5.0.GA:kernel-debug-debuginfo-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-9.5.0.GA:kernel-debug-devel-0:5.14.0-503.11.1.el9_5.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-9.5.0.GA:kernel-debug-devel-0:5.14.0-503.11.1.el9_5.ppc64le | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-9.5.0.GA:kernel-debug-devel-0:5.14.0-503.11.1.el9_5.s390x | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-9.5.0.GA:kernel-debug-devel-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-9.5.0.GA:kernel-debug-devel-matched-0:5.14.0-503.11.1.el9_5.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-9.5.0.GA:kernel-debug-devel-matched-0:5.14.0-503.11.1.el9_5.ppc64le | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-9.5.0.GA:kernel-debug-devel-matched-0:5.14.0-503.11.1.el9_5.s390x | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-9.5.0.GA:kernel-debug-devel-matched-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-9.5.0.GA:kernel-debuginfo-0:5.14.0-503.11.1.el9_5.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-9.5.0.GA:kernel-debuginfo-0:5.14.0-503.11.1.el9_5.ppc64le | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-9.5.0.GA:kernel-debuginfo-0:5.14.0-503.11.1.el9_5.s390x | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-9.5.0.GA:kernel-debuginfo-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-9.5.0.GA:kernel-debuginfo-common-aarch64-0:5.14.0-503.11.1.el9_5.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-9.5.0.GA:kernel-debuginfo-common-ppc64le-0:5.14.0-503.11.1.el9_5.ppc64le | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-9.5.0.GA:kernel-debuginfo-common-s390x-0:5.14.0-503.11.1.el9_5.s390x | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-9.5.0.GA:kernel-debuginfo-common-x86_64-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-9.5.0.GA:kernel-devel-0:5.14.0-503.11.1.el9_5.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-9.5.0.GA:kernel-devel-0:5.14.0-503.11.1.el9_5.ppc64le | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-9.5.0.GA:kernel-devel-0:5.14.0-503.11.1.el9_5.s390x | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-9.5.0.GA:kernel-devel-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-9.5.0.GA:kernel-devel-matched-0:5.14.0-503.11.1.el9_5.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-9.5.0.GA:kernel-devel-matched-0:5.14.0-503.11.1.el9_5.ppc64le | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-9.5.0.GA:kernel-devel-matched-0:5.14.0-503.11.1.el9_5.s390x | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-9.5.0.GA:kernel-devel-matched-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-9.5.0.GA:kernel-doc-0:5.14.0-503.11.1.el9_5.noarch | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-9.5.0.GA:kernel-headers-0:5.14.0-503.11.1.el9_5.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-9.5.0.GA:kernel-headers-0:5.14.0-503.11.1.el9_5.ppc64le | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-9.5.0.GA:kernel-headers-0:5.14.0-503.11.1.el9_5.s390x | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-9.5.0.GA:kernel-headers-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-9.5.0.GA:kernel-rt-debug-debuginfo-0:5.14.0-503.11.1.el9_5.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-9.5.0.GA:kernel-rt-debug-debuginfo-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-9.5.0.GA:kernel-rt-debuginfo-0:5.14.0-503.11.1.el9_5.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-9.5.0.GA:kernel-rt-debuginfo-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-9.5.0.GA:kernel-tools-debuginfo-0:5.14.0-503.11.1.el9_5.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-9.5.0.GA:kernel-tools-debuginfo-0:5.14.0-503.11.1.el9_5.ppc64le | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-9.5.0.GA:kernel-tools-debuginfo-0:5.14.0-503.11.1.el9_5.s390x | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-9.5.0.GA:kernel-tools-debuginfo-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-9.5.0.GA:kernel-zfcpdump-debuginfo-0:5.14.0-503.11.1.el9_5.s390x | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-9.5.0.GA:kernel-zfcpdump-devel-0:5.14.0-503.11.1.el9_5.s390x | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-9.5.0.GA:kernel-zfcpdump-devel-matched-0:5.14.0-503.11.1.el9_5.s390x | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-9.5.0.GA:libperf-debuginfo-0:5.14.0-503.11.1.el9_5.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-9.5.0.GA:libperf-debuginfo-0:5.14.0-503.11.1.el9_5.ppc64le | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-9.5.0.GA:libperf-debuginfo-0:5.14.0-503.11.1.el9_5.s390x | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-9.5.0.GA:libperf-debuginfo-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-9.5.0.GA:perf-0:5.14.0-503.11.1.el9_5.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-9.5.0.GA:perf-0:5.14.0-503.11.1.el9_5.ppc64le | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-9.5.0.GA:perf-0:5.14.0-503.11.1.el9_5.s390x | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-9.5.0.GA:perf-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-9.5.0.GA:perf-debuginfo-0:5.14.0-503.11.1.el9_5.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-9.5.0.GA:perf-debuginfo-0:5.14.0-503.11.1.el9_5.ppc64le | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-9.5.0.GA:perf-debuginfo-0:5.14.0-503.11.1.el9_5.s390x | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-9.5.0.GA:perf-debuginfo-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-9.5.0.GA:python3-perf-debuginfo-0:5.14.0-503.11.1.el9_5.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-9.5.0.GA:python3-perf-debuginfo-0:5.14.0-503.11.1.el9_5.ppc64le | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-9.5.0.GA:python3-perf-debuginfo-0:5.14.0-503.11.1.el9_5.s390x | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-9.5.0.GA:python3-perf-debuginfo-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-9.5.0.GA:rtla-0:5.14.0-503.11.1.el9_5.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-9.5.0.GA:rtla-0:5.14.0-503.11.1.el9_5.ppc64le | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-9.5.0.GA:rtla-0:5.14.0-503.11.1.el9_5.s390x | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-9.5.0.GA:rtla-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-9.5.0.GA:rv-0:5.14.0-503.11.1.el9_5.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-9.5.0.GA:rv-0:5.14.0-503.11.1.el9_5.ppc64le | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-9.5.0.GA:rv-0:5.14.0-503.11.1.el9_5.s390x | — |
Vendor Fix
fix
|
|
| Unresolved product id: AppStream-9.5.0.GA:rv-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:bpftool-0:7.4.0-503.11.1.el9_5.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:bpftool-0:7.4.0-503.11.1.el9_5.ppc64le | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:bpftool-0:7.4.0-503.11.1.el9_5.s390x | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:bpftool-0:7.4.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:bpftool-debuginfo-0:7.4.0-503.11.1.el9_5.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:bpftool-debuginfo-0:7.4.0-503.11.1.el9_5.ppc64le | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:bpftool-debuginfo-0:7.4.0-503.11.1.el9_5.s390x | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:bpftool-debuginfo-0:7.4.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-0:5.14.0-503.11.1.el9_5.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-0:5.14.0-503.11.1.el9_5.ppc64le | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-0:5.14.0-503.11.1.el9_5.s390x | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-0:5.14.0-503.11.1.el9_5.src | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-64k-0:5.14.0-503.11.1.el9_5.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-64k-core-0:5.14.0-503.11.1.el9_5.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-64k-debug-0:5.14.0-503.11.1.el9_5.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-64k-debug-core-0:5.14.0-503.11.1.el9_5.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-64k-debug-debuginfo-0:5.14.0-503.11.1.el9_5.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-64k-debug-modules-0:5.14.0-503.11.1.el9_5.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-64k-debug-modules-core-0:5.14.0-503.11.1.el9_5.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-64k-debug-modules-extra-0:5.14.0-503.11.1.el9_5.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-64k-debuginfo-0:5.14.0-503.11.1.el9_5.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-64k-modules-0:5.14.0-503.11.1.el9_5.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-64k-modules-core-0:5.14.0-503.11.1.el9_5.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-64k-modules-extra-0:5.14.0-503.11.1.el9_5.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-abi-stablelists-0:5.14.0-503.11.1.el9_5.noarch | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-core-0:5.14.0-503.11.1.el9_5.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-core-0:5.14.0-503.11.1.el9_5.ppc64le | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-core-0:5.14.0-503.11.1.el9_5.s390x | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-core-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-debug-0:5.14.0-503.11.1.el9_5.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-debug-0:5.14.0-503.11.1.el9_5.ppc64le | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-debug-0:5.14.0-503.11.1.el9_5.s390x | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-debug-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-debug-core-0:5.14.0-503.11.1.el9_5.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-debug-core-0:5.14.0-503.11.1.el9_5.ppc64le | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-debug-core-0:5.14.0-503.11.1.el9_5.s390x | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-debug-core-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-debug-debuginfo-0:5.14.0-503.11.1.el9_5.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-debug-debuginfo-0:5.14.0-503.11.1.el9_5.ppc64le | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-debug-debuginfo-0:5.14.0-503.11.1.el9_5.s390x | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-debug-debuginfo-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-debug-modules-0:5.14.0-503.11.1.el9_5.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-debug-modules-0:5.14.0-503.11.1.el9_5.ppc64le | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-debug-modules-0:5.14.0-503.11.1.el9_5.s390x | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-debug-modules-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-debug-modules-core-0:5.14.0-503.11.1.el9_5.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-debug-modules-core-0:5.14.0-503.11.1.el9_5.ppc64le | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-debug-modules-core-0:5.14.0-503.11.1.el9_5.s390x | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-debug-modules-core-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-debug-modules-extra-0:5.14.0-503.11.1.el9_5.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-debug-modules-extra-0:5.14.0-503.11.1.el9_5.ppc64le | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-debug-modules-extra-0:5.14.0-503.11.1.el9_5.s390x | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-debug-modules-extra-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-debug-uki-virt-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-debuginfo-0:5.14.0-503.11.1.el9_5.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-debuginfo-0:5.14.0-503.11.1.el9_5.ppc64le | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-debuginfo-0:5.14.0-503.11.1.el9_5.s390x | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-debuginfo-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-debuginfo-common-aarch64-0:5.14.0-503.11.1.el9_5.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-debuginfo-common-ppc64le-0:5.14.0-503.11.1.el9_5.ppc64le | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-debuginfo-common-s390x-0:5.14.0-503.11.1.el9_5.s390x | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-debuginfo-common-x86_64-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-modules-0:5.14.0-503.11.1.el9_5.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-modules-0:5.14.0-503.11.1.el9_5.ppc64le | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-modules-0:5.14.0-503.11.1.el9_5.s390x | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-modules-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-modules-core-0:5.14.0-503.11.1.el9_5.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-modules-core-0:5.14.0-503.11.1.el9_5.ppc64le | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-modules-core-0:5.14.0-503.11.1.el9_5.s390x | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-modules-core-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-modules-extra-0:5.14.0-503.11.1.el9_5.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-modules-extra-0:5.14.0-503.11.1.el9_5.ppc64le | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-modules-extra-0:5.14.0-503.11.1.el9_5.s390x | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-modules-extra-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-rt-debug-debuginfo-0:5.14.0-503.11.1.el9_5.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-rt-debug-debuginfo-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-rt-debuginfo-0:5.14.0-503.11.1.el9_5.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-rt-debuginfo-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-tools-0:5.14.0-503.11.1.el9_5.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-tools-0:5.14.0-503.11.1.el9_5.ppc64le | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-tools-0:5.14.0-503.11.1.el9_5.s390x | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-tools-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-tools-debuginfo-0:5.14.0-503.11.1.el9_5.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-tools-debuginfo-0:5.14.0-503.11.1.el9_5.ppc64le | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-tools-debuginfo-0:5.14.0-503.11.1.el9_5.s390x | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-tools-debuginfo-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-tools-libs-0:5.14.0-503.11.1.el9_5.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-tools-libs-0:5.14.0-503.11.1.el9_5.ppc64le | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-tools-libs-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-uki-virt-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-uki-virt-addons-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-zfcpdump-0:5.14.0-503.11.1.el9_5.s390x | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-zfcpdump-core-0:5.14.0-503.11.1.el9_5.s390x | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-zfcpdump-debuginfo-0:5.14.0-503.11.1.el9_5.s390x | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-zfcpdump-modules-0:5.14.0-503.11.1.el9_5.s390x | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-zfcpdump-modules-core-0:5.14.0-503.11.1.el9_5.s390x | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:kernel-zfcpdump-modules-extra-0:5.14.0-503.11.1.el9_5.s390x | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:libperf-debuginfo-0:5.14.0-503.11.1.el9_5.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:libperf-debuginfo-0:5.14.0-503.11.1.el9_5.ppc64le | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:libperf-debuginfo-0:5.14.0-503.11.1.el9_5.s390x | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:libperf-debuginfo-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:perf-debuginfo-0:5.14.0-503.11.1.el9_5.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:perf-debuginfo-0:5.14.0-503.11.1.el9_5.ppc64le | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:perf-debuginfo-0:5.14.0-503.11.1.el9_5.s390x | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:perf-debuginfo-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:python3-perf-0:5.14.0-503.11.1.el9_5.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:python3-perf-0:5.14.0-503.11.1.el9_5.ppc64le | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:python3-perf-0:5.14.0-503.11.1.el9_5.s390x | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:python3-perf-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:python3-perf-debuginfo-0:5.14.0-503.11.1.el9_5.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:python3-perf-debuginfo-0:5.14.0-503.11.1.el9_5.ppc64le | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:python3-perf-debuginfo-0:5.14.0-503.11.1.el9_5.s390x | — |
Vendor Fix
fix
|
|
| Unresolved product id: BaseOS-9.5.0.GA:python3-perf-debuginfo-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: CRB-9.5.0.GA:bpftool-debuginfo-0:7.4.0-503.11.1.el9_5.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: CRB-9.5.0.GA:bpftool-debuginfo-0:7.4.0-503.11.1.el9_5.ppc64le | — |
Vendor Fix
fix
|
|
| Unresolved product id: CRB-9.5.0.GA:bpftool-debuginfo-0:7.4.0-503.11.1.el9_5.s390x | — |
Vendor Fix
fix
|
|
| Unresolved product id: CRB-9.5.0.GA:bpftool-debuginfo-0:7.4.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: CRB-9.5.0.GA:kernel-64k-debug-debuginfo-0:5.14.0-503.11.1.el9_5.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: CRB-9.5.0.GA:kernel-64k-debuginfo-0:5.14.0-503.11.1.el9_5.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: CRB-9.5.0.GA:kernel-cross-headers-0:5.14.0-503.11.1.el9_5.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: CRB-9.5.0.GA:kernel-cross-headers-0:5.14.0-503.11.1.el9_5.ppc64le | — |
Vendor Fix
fix
|
|
| Unresolved product id: CRB-9.5.0.GA:kernel-cross-headers-0:5.14.0-503.11.1.el9_5.s390x | — |
Vendor Fix
fix
|
|
| Unresolved product id: CRB-9.5.0.GA:kernel-cross-headers-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: CRB-9.5.0.GA:kernel-debug-debuginfo-0:5.14.0-503.11.1.el9_5.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: CRB-9.5.0.GA:kernel-debug-debuginfo-0:5.14.0-503.11.1.el9_5.ppc64le | — |
Vendor Fix
fix
|
|
| Unresolved product id: CRB-9.5.0.GA:kernel-debug-debuginfo-0:5.14.0-503.11.1.el9_5.s390x | — |
Vendor Fix
fix
|
|
| Unresolved product id: CRB-9.5.0.GA:kernel-debug-debuginfo-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: CRB-9.5.0.GA:kernel-debuginfo-0:5.14.0-503.11.1.el9_5.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: CRB-9.5.0.GA:kernel-debuginfo-0:5.14.0-503.11.1.el9_5.ppc64le | — |
Vendor Fix
fix
|
|
| Unresolved product id: CRB-9.5.0.GA:kernel-debuginfo-0:5.14.0-503.11.1.el9_5.s390x | — |
Vendor Fix
fix
|
|
| Unresolved product id: CRB-9.5.0.GA:kernel-debuginfo-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: CRB-9.5.0.GA:kernel-debuginfo-common-aarch64-0:5.14.0-503.11.1.el9_5.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: CRB-9.5.0.GA:kernel-debuginfo-common-ppc64le-0:5.14.0-503.11.1.el9_5.ppc64le | — |
Vendor Fix
fix
|
|
| Unresolved product id: CRB-9.5.0.GA:kernel-debuginfo-common-s390x-0:5.14.0-503.11.1.el9_5.s390x | — |
Vendor Fix
fix
|
|
| Unresolved product id: CRB-9.5.0.GA:kernel-debuginfo-common-x86_64-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: CRB-9.5.0.GA:kernel-rt-debug-debuginfo-0:5.14.0-503.11.1.el9_5.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: CRB-9.5.0.GA:kernel-rt-debug-debuginfo-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: CRB-9.5.0.GA:kernel-rt-debuginfo-0:5.14.0-503.11.1.el9_5.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: CRB-9.5.0.GA:kernel-rt-debuginfo-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: CRB-9.5.0.GA:kernel-tools-debuginfo-0:5.14.0-503.11.1.el9_5.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: CRB-9.5.0.GA:kernel-tools-debuginfo-0:5.14.0-503.11.1.el9_5.ppc64le | — |
Vendor Fix
fix
|
|
| Unresolved product id: CRB-9.5.0.GA:kernel-tools-debuginfo-0:5.14.0-503.11.1.el9_5.s390x | — |
Vendor Fix
fix
|
|
| Unresolved product id: CRB-9.5.0.GA:kernel-tools-debuginfo-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: CRB-9.5.0.GA:kernel-tools-libs-devel-0:5.14.0-503.11.1.el9_5.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: CRB-9.5.0.GA:kernel-tools-libs-devel-0:5.14.0-503.11.1.el9_5.ppc64le | — |
Vendor Fix
fix
|
|
| Unresolved product id: CRB-9.5.0.GA:kernel-tools-libs-devel-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: CRB-9.5.0.GA:kernel-zfcpdump-debuginfo-0:5.14.0-503.11.1.el9_5.s390x | — |
Vendor Fix
fix
|
|
| Unresolved product id: CRB-9.5.0.GA:libperf-0:5.14.0-503.11.1.el9_5.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: CRB-9.5.0.GA:libperf-0:5.14.0-503.11.1.el9_5.ppc64le | — |
Vendor Fix
fix
|
|
| Unresolved product id: CRB-9.5.0.GA:libperf-0:5.14.0-503.11.1.el9_5.s390x | — |
Vendor Fix
fix
|
|
| Unresolved product id: CRB-9.5.0.GA:libperf-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: CRB-9.5.0.GA:libperf-debuginfo-0:5.14.0-503.11.1.el9_5.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: CRB-9.5.0.GA:libperf-debuginfo-0:5.14.0-503.11.1.el9_5.ppc64le | — |
Vendor Fix
fix
|
|
| Unresolved product id: CRB-9.5.0.GA:libperf-debuginfo-0:5.14.0-503.11.1.el9_5.s390x | — |
Vendor Fix
fix
|
|
| Unresolved product id: CRB-9.5.0.GA:libperf-debuginfo-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: CRB-9.5.0.GA:perf-debuginfo-0:5.14.0-503.11.1.el9_5.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: CRB-9.5.0.GA:perf-debuginfo-0:5.14.0-503.11.1.el9_5.ppc64le | — |
Vendor Fix
fix
|
|
| Unresolved product id: CRB-9.5.0.GA:perf-debuginfo-0:5.14.0-503.11.1.el9_5.s390x | — |
Vendor Fix
fix
|
|
| Unresolved product id: CRB-9.5.0.GA:perf-debuginfo-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: CRB-9.5.0.GA:python3-perf-debuginfo-0:5.14.0-503.11.1.el9_5.aarch64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: CRB-9.5.0.GA:python3-perf-debuginfo-0:5.14.0-503.11.1.el9_5.ppc64le | — |
Vendor Fix
fix
|
|
| Unresolved product id: CRB-9.5.0.GA:python3-perf-debuginfo-0:5.14.0-503.11.1.el9_5.s390x | — |
Vendor Fix
fix
|
|
| Unresolved product id: CRB-9.5.0.GA:python3-perf-debuginfo-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: NFV-9.5.0.GA:bpftool-debuginfo-0:7.4.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: NFV-9.5.0.GA:kernel-debug-debuginfo-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: NFV-9.5.0.GA:kernel-debuginfo-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: NFV-9.5.0.GA:kernel-debuginfo-common-x86_64-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: NFV-9.5.0.GA:kernel-rt-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: NFV-9.5.0.GA:kernel-rt-core-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: NFV-9.5.0.GA:kernel-rt-debug-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: NFV-9.5.0.GA:kernel-rt-debug-core-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: NFV-9.5.0.GA:kernel-rt-debug-debuginfo-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: NFV-9.5.0.GA:kernel-rt-debug-devel-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: NFV-9.5.0.GA:kernel-rt-debug-kvm-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: NFV-9.5.0.GA:kernel-rt-debug-modules-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: NFV-9.5.0.GA:kernel-rt-debug-modules-core-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: NFV-9.5.0.GA:kernel-rt-debug-modules-extra-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: NFV-9.5.0.GA:kernel-rt-debuginfo-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: NFV-9.5.0.GA:kernel-rt-devel-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: NFV-9.5.0.GA:kernel-rt-kvm-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: NFV-9.5.0.GA:kernel-rt-modules-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: NFV-9.5.0.GA:kernel-rt-modules-core-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: NFV-9.5.0.GA:kernel-rt-modules-extra-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: NFV-9.5.0.GA:kernel-tools-debuginfo-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: NFV-9.5.0.GA:libperf-debuginfo-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: NFV-9.5.0.GA:perf-debuginfo-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: NFV-9.5.0.GA:python3-perf-debuginfo-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: RT-9.5.0.GA:bpftool-debuginfo-0:7.4.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: RT-9.5.0.GA:kernel-debug-debuginfo-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: RT-9.5.0.GA:kernel-debuginfo-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: RT-9.5.0.GA:kernel-debuginfo-common-x86_64-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: RT-9.5.0.GA:kernel-rt-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: RT-9.5.0.GA:kernel-rt-core-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: RT-9.5.0.GA:kernel-rt-debug-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: RT-9.5.0.GA:kernel-rt-debug-core-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: RT-9.5.0.GA:kernel-rt-debug-debuginfo-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: RT-9.5.0.GA:kernel-rt-debug-devel-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: RT-9.5.0.GA:kernel-rt-debug-modules-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: RT-9.5.0.GA:kernel-rt-debug-modules-core-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: RT-9.5.0.GA:kernel-rt-debug-modules-extra-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: RT-9.5.0.GA:kernel-rt-debuginfo-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: RT-9.5.0.GA:kernel-rt-devel-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: RT-9.5.0.GA:kernel-rt-modules-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: RT-9.5.0.GA:kernel-rt-modules-core-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: RT-9.5.0.GA:kernel-rt-modules-extra-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: RT-9.5.0.GA:kernel-tools-debuginfo-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: RT-9.5.0.GA:libperf-debuginfo-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: RT-9.5.0.GA:perf-debuginfo-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
|
| Unresolved product id: RT-9.5.0.GA:python3-perf-debuginfo-0:5.14.0-503.11.1.el9_5.x86_64 | — |
Vendor Fix
fix
|
In the Linux kernel, the following vulnerability has been resolved: platform/chrome: cros_usbpd_notify: Fix error handling in cros_usbpd_notify_init() The following WARNING message was given when rmmod cros_usbpd_notify: Unexpected driver unregister! WARNING: CPU: 0 PID: 253 at drivers/base/driver.c:270 driver_unregister+0x8a/0xb0 Modules linked in: cros_usbpd_notify(-) CPU: 0 PID: 253 Comm: rmmod Not tainted 6.1.0-rc3 #24 ... Call Trace: <TASK> cros_usbpd_notify_exit+0x11/0x1e [cros_usbpd_notify] __x64_sys_delete_module+0x3c7/0x570 ? __ia32_sys_delete_module+0x570/0x570 ? lock_is_held_type+0xe3/0x140 ? syscall_enter_from_user_mode+0x17/0x50 ? rcu_read_lock_sched_held+0xa0/0xd0 ? syscall_enter_from_user_mode+0x1c/0x50 do_syscall_64+0x37/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x7f333fe9b1b7 The reason is that the cros_usbpd_notify_init() does not check the return value of platform_driver_register(), and the cros_usbpd_notify can install successfully even if platform_driver_register() failed. Fix by checking the return value of platform_driver_register() and unregister cros_usbpd_notify_plat_driver when it failed.
A type confusion flaw was found in the Linux kernel's Texas Instruments NETCP Ethernet driver in the packet transmit function signature. A local user can trigger this issue on systems with kernel Control Flow Integrity enabled, where the incorrect return type of the ndo_start_xmit function causes CFI validation failures during indirect function calls. This results in either a kernel panic or thread termination, leading to denial of service.
A memory leak was found in the Linux kernel's Xen SMP interrupt initialization functions for x86 architectures. When interrupt handler binding fails during setup, the error path frees various resources but neglects to free dynamically allocated interrupt name strings created via kasprintf. This causes memory to leak with each failed initialization attempt, leading to resource exhaustion and denial of service.
A counter-overflow flaw was found in the Linux kernel Texas Instruments K3 Universal Direct Memory Access (UDMA) driver. During long data transfers exceeding four gigabytes, the hardware byte-count registers could wrap and misreport progress, causing the transfer to hang indefinitely. A local user could use this flaw to cause a denial of service due to a stalled input/output operation.
A flaw was found in the Linux kernel’s AMBA-PL011 serial driver used on ARM Server Base System Architecture platforms. The existing stop_rx operation shared between generic SBSA UARTs and AMBA-PL011 UARTs invoked pl011_dma_rx_stop, which attempts to access the DMA Control Register (DMACR). SBSA generic UART hardware does not support DMA, and accessing the DMACR register on such hardwarecan trigger an unhandled data abort, causing a segmentation fault or crash.
A flaw in the Linux kernel mmc core driver was discovered that could lead to a kernel panic and memory corruption when a non-standard SDIO card is removed. The Vulnerability arises because SDIO tuples are only allocated for standard SDIO cards, resulting in an inconsistent reference count for the device structure. When the non-standard card is removed, the reference counter is decremented without the corresponding earlier increment, potentially triggering use of freed memory or panic conditions. A local user with access to the affected subsystem could trigger this behavior, causing the kernel to crash.
In the Linux kernel, the following vulnerability has been resolved: mmc: atmel-mci: fix return value check of mmc_add_host() mmc_add_host() may return error, if we ignore its return value, it will lead two issues: 1. The memory that allocated in mmc_alloc_host() is leaked. 2. In the remove() path, mmc_remove_host() will be called to delete device, but it's not added yet, it will lead a kernel crash because of null-ptr-deref in device_del(). So fix this by checking the return value and calling mmc_free_host() in the error path.
A memory leak vulnerability was found in the stmmac network driver in the Linux kernel. When create_singlethread_workqueue() fails during probe, the previously allocated bitmap (priv->af_xdp_zc_qps) is not freed. This can lead to memory resource exhaustion if the error condition is repeatedly triggered.
A flaw was found in the OMAP HSMMC driver in the Linux kernel. The driver does not check the return value of mmc_add_host(), which can lead to a memory leak from mmc_alloc_host() and a null pointer dereference crash in mmc_remove_host() when attempting to remove a device that was never successfully added.
In the Linux kernel, the following vulnerability has been resolved: x86/apic: Don't disable x2APIC if locked The APIC supports two modes, legacy APIC (or xAPIC), and Extended APIC (or x2APIC). X2APIC mode is mostly compatible with legacy APIC, but it disables the memory-mapped APIC interface in favor of one that uses MSRs. The APIC mode is controlled by the EXT bit in the APIC MSR. The MMIO/xAPIC interface has some problems, most notably the APIC LEAK [1]. This bug allows an attacker to use the APIC MMIO interface to extract data from the SGX enclave. Introduce support for a new feature that will allow the BIOS to lock the APIC in x2APIC mode. If the APIC is locked in x2APIC mode and the kernel tries to disable the APIC or revert to legacy APIC mode a GP fault will occur. Introduce support for a new MSR (IA32_XAPIC_DISABLE_STATUS) and handle the new locked mode when the LEGACY_XAPIC_DISABLED bit is set by preventing the kernel from trying to disable the x2APIC. On platforms with the IA32_XAPIC_DISABLE_STATUS MSR, if SGX or TDX are enabled the LEGACY_XAPIC_DISABLED will be set by the BIOS. If legacy APIC is required, then it SGX and TDX need to be disabled in the BIOS. [1]: https://aepicleak.com/aepicleak.pdf
A flaw was found in the Linux kernel's mqueue (message queue) component. A local attacker with low privileges could exploit a memory leak in the `init_mqueue_fs()` function. This vulnerability occurs when `retire_mq_sysctls` is not called after `setup_mq_sysctls` fails, leading to resource exhaustion. This could result in a Denial of Service (DoS) condition, making the system unavailable.
A flaw was found in the Linux kernel's x86/xen component. A local user could exploit a memory leak vulnerability during the initialization of the CPU lock in the `xen_init_lock_cpu()` function. If a specific internal function fails after memory allocation, the allocated memory is not properly released. This can lead to resource exhaustion and a Denial of Service (DoS) condition on the affected system.
A flaw was found in the Linux kernel's Freescale MXC MMC driver. The mxcmmc driver fails to check the return value of mmc_add_host(). If this function fails, memory allocated by mmc_alloc_host() is leaked, and a subsequent driver removal will crash the kernel when attempting to delete a device that was never successfully added.
CWE-252 - Unchecked Return ValueA flaw was found in the VIA SD/MMC host controller driver. When mmc_add_host() fails, the error is not checked, leading to memory leaks and potential null pointer dereference during driver removal.
CWE-390 - Detection of Error Condition Without ActionA flaw was found in the Linux kernel's Alcor Micro MMC card reader driver. When mmc_add_host() fails, its return value is not checked, causing memory allocated by mmc_alloc_host() to leak. Additionally, the remove path may attempt to delete a device that was never added, leading to a kernel crash.
CWE-252 - Unchecked Return ValueA flaw was found in the Linux kernel's Toshiba SD/MMC card reader driver (toshsd). The driver fails to check the return value of mmc_add_host(). If this function fails, memory allocated by mmc_alloc_host() is leaked, and a subsequent driver removal attempt will crash the kernel by trying to delete a device that was never added.
CWE-252 - Unchecked Return ValueIn the Linux kernel, the following vulnerability has been resolved: media: pvrusb2: fix use after free on context disconnection Upon module load, a kthread is created targeting the pvr2_context_thread_func function, which may call pvr2_context_destroy and thus call kfree() on the context object. However, that might happen before the usb hub_event handler is able to notify the driver. This patch adds a sanity check before the invalid read reported by syzbot, within the context disconnection call stack.
CWE-416 - Use After FreeA flaw was found in the Linux kernel, specifically affecting the PowerPC architecture's pseries memory hotplug functionality. The issue arises from the dlpar_memory_remove_by_index() function, which may access memory beyond the bounds of the drmem logical memory block (LMB) array when it fails to find a matching entry for a given Dynamic Reconfiguration Connector (DRC) index. This out-of-bounds access can lead to unintended behavior, including potential system crashes or exposure of sensitive information.
A flaw was found in the Linux kernel. When the bootloader/firmware does not set up the framebuffers, the address and size are 0 in the "iommu-addresses" property. If the IOVA region is reserved with a 0 length, it corrupts the IOVA rbtree with an entry that has pfn_hi < pfn_lo. If the intent is to use the display driver in the kernel without the framebuffer, it causes the display IOMMU mappings to fail, as an entire valid IOVA space is reserved when the address and length are passed as 0. An ideal solution would be for the firmware to remove the "iommu-addresses" property and the corresponding "memory-region" if the display is not present. The kernel should be able to handle this by checking the size of the IOVA region and skipping the IOVA reservation if its size is 0. Also, add a warning if the firmware is requesting a 0-length IOVA region reservation.
A flaw was found in the Linux kernel. When the register is spilled onto a stack as a 1/2/4-byte register, the slot_type[BPF_REG_SIZE - 1] is set, possibly including a few more below it, depending on the actual spill size. To confirm if some stack slots have a spilled register, consult slot_type[7], not slot_type[0]. To avoid the need to remember and double-check this in the future, use the is_spilled_reg() helper.
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 ValueAn out-of-bounds read flaw was found in pci_dev_for_each_resource() in the Linux Kernel. The pointer in the pci_dev_for_each_resource() may be wrong. For example, it might be used for the out-of-bounds read. This issue was identified by the Coverity static analysis tool, which flagged a pointer (res) that could be used incorrectly, potentially leading to accessing memory outside its bounds.
A vulnerability was found in the Linux kernel, where A NULL pointer dereference flaw may occur in _syscon_register(). In this issue, kasprintf() returns a pointer to dynamically allocated memory, which can be NULL upon failure.
is a security vulnerability in the Linux kernel, specifically within the thermal management subsystem. This vulnerability is a NULL pointer dereference that occurs in the thermal_zone_device_register_with_trips() function during the thermal zone registration error path. This issue can cause crashes and system instability.
CWE-476 - NULL Pointer DereferenceA use-after-free flaw was found in powermate_config_complete in drivers/input/misc/powermate.c in the Linux kernel. This issue may allow an attacker to crash the system at device disconnect, possibly leading to a kernel information leak problem.
In the Linux kernel, the following vulnerability has been resolved: usb: hub: Guard against accesses to uninitialized BOS descriptors Many functions in drivers/usb/core/hub.c and drivers/usb/core/hub.h access fields inside udev->bos without checking if it was allocated and initialized. If usb_get_bos_descriptor() fails for whatever reason, udev->bos will be NULL and those accesses will result in a crash: BUG: kernel NULL pointer dereference, address: 0000000000000018 PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 5 PID: 17818 Comm: kworker/5:1 Tainted: G W 5.15.108-18910-gab0e1cb584e1 #1 <HASH:1f9e 1> Hardware name: Google Kindred/Kindred, BIOS Google_Kindred.12672.413.0 02/03/2021 Workqueue: usb_hub_wq hub_event RIP: 0010:hub_port_reset+0x193/0x788 Code: 89 f7 e8 20 f7 15 00 48 8b 43 08 80 b8 96 03 00 00 03 75 36 0f b7 88 92 03 00 00 81 f9 10 03 00 00 72 27 48 8b 80 a8 03 00 00 <48> 83 78 18 00 74 19 48 89 df 48 8b 75 b0 ba 02 00 00 00 4c 89 e9 RSP: 0018:ffffab740c53fcf8 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffffa1bc5f678000 RCX: 0000000000000310 RDX: fffffffffffffdff RSI: 0000000000000286 RDI: ffffa1be9655b840 RBP: ffffab740c53fd70 R08: 00001b7d5edaa20c R09: ffffffffb005e060 R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000 R13: ffffab740c53fd3e R14: 0000000000000032 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffffa1be96540000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000018 CR3: 000000022e80c005 CR4: 00000000003706e0 Call Trace: hub_event+0x73f/0x156e ? hub_activate+0x5b7/0x68f process_one_work+0x1a2/0x487 worker_thread+0x11a/0x288 kthread+0x13a/0x152 ? process_one_work+0x487/0x487 ? kthread_associate_blkcg+0x70/0x70 ret_from_fork+0x1f/0x30 Fall back to a default behavior if the BOS descriptor isn't accessible and skip all the functionalities that depend on it: LPM support checks, Super Speed capabilitiy checks, U1/U2 states setup.
A vulnerability was found in the Linux kernel, where the Hygon x86 processor is susceptible to a speculative return stack overflow.
A flaw was found in the Linux kernel. A frame buffer can be freed while still in use in a specific situation in drivers/gpu/drm/drm_plane.c. This issue may compromise the availability.
In the Linux kernel, the following vulnerability has been resolved: dmaengine: fix NULL pointer in channel unregistration function The Linux kernel CVE team has assigned CVE-2023-52492 to this issue. Upstream advisory: https://lore.kernel.org/linux-cve-announce/20240229155245.1571576-33-lee@kernel.org/T
A flaw was found in the Linux Kernel. In low-memory situations, there is a possibility of a code deadlock that may lead to a hang.
In the Linux kernel, the following vulnerability has been resolved: ring-buffer: Do not attempt to read past "commit" The Linux kernel CVE team has assigned CVE-2023-52501 to this issue. Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024030248-CVE-2023-52501-75ba@gregkh/T/#u
A NULL dereference vulnerability was found in the Linux kernel, which is caused when the siw_cm_work_handler() function attempts to dereference a NULL listener that may be created when immediate MPA request processing fails and the newly created endpoint unlinks the listening endpoint ready to be dropped.
In the Linux kernel, the following vulnerability has been resolved: platform/x86: think-lmi: Fix reference leak The Linux kernel CVE team has assigned CVE-2023-52520 to this issue. Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024030252-CVE-2023-52520-0a4e@gregkh/T/#u
In the Linux kernel, the following vulnerability has been resolved: net: usb: smsc75xx: Fix uninit-value access in __smsc75xx_read_reg The Linux kernel CVE team has assigned CVE-2023-52528 to this issue. Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024030254-CVE-2023-52528-c33b@gregkh/T/#u
A 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 LifetimeIn the Linux kernel, the following vulnerability has been resolved: media: uvcvideo: Fix OOB read If the index provided by the user is bigger than the mask size, we might do an out of bound read.
CWE-125 - Out-of-bounds ReadA vulnerability was found in the amdgpu_ras_query_error_status_helper() function in the Linunx kernel which could lead to a possible NULL pointer dereference, causing data corruption or crashes.
A potential array-index-out-of-bounds read flaw was found in the Linux kernel in ath9k_htc_txstatus(). This issue may lead to a crash.
A flaw was found in the Linux kernel. When a hardware reset is triggered, all registers are reset, so all queues are forced to stop in the hardware interface. However, mac80211 will not automatically stop the queue. If the beacon queue is not manually stopped, it will be deadlocked and unable to restart.
A potential stack corruption flaw was found in arch/powerpc/lib/sstep.c in the Linux kernel. This may lead to compromised Confidentiality, Integrity, or Availability.
In the Linux kernel, the following vulnerability has been resolved: PM / devfreq: Fix buffer overflow in trans_stat_show Fix buffer overflow in trans_stat_show(). Convert simple snprintf to the more secure scnprintf with size of PAGE_SIZE. Add condition checking if we are exceeding PAGE_SIZE and exit early from loop. Also add at the end a warning that we exceeded PAGE_SIZE and that stats is disabled. Return -EFBIG in the case where we don't have enough space to write the full transition table. Also document in the ABI that this function can return -EFBIG error.
A 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.
A vulnerability was found in the pstore/ram component of the Linux kernel, which caused crashes when the number of CPU cores was set to an odd number. This issue occurs because the odd-numbered zones became misaligned. This flaw allows a local, authenticated attacker to cause a denial of service.
In the Linux kernel, the following vulnerability has been resolved: bpf: Check rcu_read_lock_trace_held() before calling bpf map helpers These three bpf_map_{lookup,update,delete}_elem() helpers are also available for sleepable bpf program, so add the corresponding lock assertion for sleepable bpf program, otherwise the following warning will be reported when a sleepable bpf program manipulates bpf map under interpreter mode (aka bpf_jit_enable=0): WARNING: CPU: 3 PID: 4985 at kernel/bpf/helpers.c:40 ...... CPU: 3 PID: 4985 Comm: test_progs Not tainted 6.6.0+ #2 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) ...... RIP: 0010:bpf_map_lookup_elem+0x54/0x60 ...... Call Trace: <TASK> ? __warn+0xa5/0x240 ? bpf_map_lookup_elem+0x54/0x60 ? report_bug+0x1ba/0x1f0 ? handle_bug+0x40/0x80 ? exc_invalid_op+0x18/0x50 ? asm_exc_invalid_op+0x1b/0x20 ? __pfx_bpf_map_lookup_elem+0x10/0x10 ? rcu_lockdep_current_cpu_online+0x65/0xb0 ? rcu_is_watching+0x23/0x50 ? bpf_map_lookup_elem+0x54/0x60 ? __pfx_bpf_map_lookup_elem+0x10/0x10 ___bpf_prog_run+0x513/0x3b70 __bpf_prog_run32+0x9d/0xd0 ? __bpf_prog_enter_sleepable_recur+0xad/0x120 ? __bpf_prog_enter_sleepable_recur+0x3e/0x120 bpf_trampoline_6442580665+0x4d/0x1000 __x64_sys_getpgid+0x5/0x30 ? do_syscall_64+0x36/0xb0 entry_SYSCALL_64_after_hwframe+0x6e/0x76 </TASK>
In the Linux kernel, the following vulnerability has been resolved: ext4: avoid online resizing failures due to oversized flex bg When we online resize an ext4 filesystem with a oversized flexbg_size, mkfs.ext4 -F -G 67108864 $dev -b 4096 100M mount $dev $dir resize2fs $dev 16G the following WARN_ON is triggered: ================================================================== WARNING: CPU: 0 PID: 427 at mm/page_alloc.c:4402 __alloc_pages+0x411/0x550 Modules linked in: sg(E) CPU: 0 PID: 427 Comm: resize2fs Tainted: G E 6.6.0-rc5+ #314 RIP: 0010:__alloc_pages+0x411/0x550 Call Trace: <TASK> __kmalloc_large_node+0xa2/0x200 __kmalloc+0x16e/0x290 ext4_resize_fs+0x481/0xd80 __ext4_ioctl+0x1616/0x1d90 ext4_ioctl+0x12/0x20 __x64_sys_ioctl+0xf0/0x150 do_syscall_64+0x3b/0x90 ================================================================== This is because flexbg_size is too large and the size of the new_group_data array to be allocated exceeds MAX_ORDER. Currently, the minimum value of MAX_ORDER is 8, the minimum value of PAGE_SIZE is 4096, the corresponding maximum number of groups that can be allocated is: (PAGE_SIZE << MAX_ORDER) / sizeof(struct ext4_new_group_data) ≈ 21845 And the value that is down-aligned to the power of 2 is 16384. Therefore, this value is defined as MAX_RESIZE_BG, and the number of groups added each time does not exceed this value during resizing, and is added multiple times to complete the online resizing. The difference is that the metadata in a flex_bg may be more dispersed.
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Wake DMCUB before executing GPINT commands [Why] DMCUB can be in idle when we attempt to interface with the HW through the GPINT mailbox resulting in a system hang. [How] Add dc_wake_and_execute_gpint() to wrap the wake, execute, sleep sequence. If the GPINT executes successfully then DMCUB will be put back into sleep after the optional response is returned. It functions similar to the inbox command interface.
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Refactor DMCUB enter/exit idle interface [Why] We can hang in place trying to send commands when the DMCUB isn't powered on. [How] We need to exit out of the idle state prior to sending a command, but the process that performs the exit also invokes a command itself. Fixing this issue involves the following: 1. Using a software state to track whether or not we need to start the process to exit idle or notify idle. It's possible for the hardware to have exited an idle state without driver knowledge, but entering one is always restricted to a driver allow - which makes the SW state vs HW state mismatch issue purely one of optimization, which should seldomly be hit, if at all. 2. Refactor any instances of exit/notify idle to use a single wrapper that maintains this SW state. This works simialr to dc_allow_idle_optimizations, but works at the DMCUB level and makes sure the state is marked prior to any notify/exit idle so we don't enter an infinite loop. 3. Make sure we exit out of idle prior to sending any commands or waiting for DMCUB idle. This patch takes care of 1/2. A future patch will take care of wrapping DMCUB command submission with calls to this new interface.
In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Fix lock dependency warning with srcu ====================================================== WARNING: possible circular locking dependency detected 6.5.0-kfd-yangp #2289 Not tainted ------------------------------------------------------ kworker/0:2/996 is trying to acquire lock: (srcu){.+.+}-{0:0}, at: __synchronize_srcu+0x5/0x1a0 but task is already holding lock: ((work_completion)(&svms->deferred_list_work)){+.+.}-{0:0}, at: process_one_work+0x211/0x560 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #3 ((work_completion)(&svms->deferred_list_work)){+.+.}-{0:0}: __flush_work+0x88/0x4f0 svm_range_list_lock_and_flush_work+0x3d/0x110 [amdgpu] svm_range_set_attr+0xd6/0x14c0 [amdgpu] kfd_ioctl+0x1d1/0x630 [amdgpu] __x64_sys_ioctl+0x88/0xc0 -> #2 (&info->lock#2){+.+.}-{3:3}: __mutex_lock+0x99/0xc70 amdgpu_amdkfd_gpuvm_restore_process_bos+0x54/0x740 [amdgpu] restore_process_helper+0x22/0x80 [amdgpu] restore_process_worker+0x2d/0xa0 [amdgpu] process_one_work+0x29b/0x560 worker_thread+0x3d/0x3d0 -> #1 ((work_completion)(&(&process->restore_work)->work)){+.+.}-{0:0}: __flush_work+0x88/0x4f0 __cancel_work_timer+0x12c/0x1c0 kfd_process_notifier_release_internal+0x37/0x1f0 [amdgpu] __mmu_notifier_release+0xad/0x240 exit_mmap+0x6a/0x3a0 mmput+0x6a/0x120 do_exit+0x322/0xb90 do_group_exit+0x37/0xa0 __x64_sys_exit_group+0x18/0x20 do_syscall_64+0x38/0x80 -> #0 (srcu){.+.+}-{0:0}: __lock_acquire+0x1521/0x2510 lock_sync+0x5f/0x90 __synchronize_srcu+0x4f/0x1a0 __mmu_notifier_release+0x128/0x240 exit_mmap+0x6a/0x3a0 mmput+0x6a/0x120 svm_range_deferred_list_work+0x19f/0x350 [amdgpu] process_one_work+0x29b/0x560 worker_thread+0x3d/0x3d0 other info that might help us debug this: Chain exists of: srcu --> &info->lock#2 --> (work_completion)(&svms->deferred_list_work) Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock((work_completion)(&svms->deferred_list_work)); lock(&info->lock#2); lock((work_completion)(&svms->deferred_list_work)); sync(srcu);
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix disable_otg_wa logic [Why] When switching to another HDMI mode, we are unnecesarilly disabling/enabling FIFO causing both HPO and DIG registers to be set at the same time when only HPO is supposed to be set. This can lead to a system hang the next time we change refresh rates as there are cases when we don't disable OTG/FIFO but FIFO is enabled when it isn't supposed to be. [How] Removing the enable/disable FIFO entirely.
A flaw was found in the Linux kernel resulting from race conditions and a lack of synchronization in handling the delayed work timers in the devfreq component. This issue can lead to inconsistencies and a corruption of the timer list.
In the Linux kernel, the following vulnerability has been resolved: can: j1939: Fix UAF in j1939_sk_match_filter during setsockopt(SO_J1939_FILTER) Lock jsk->sk to prevent UAF when setsockopt(..., SO_J1939_FILTER, ...) modifies jsk->filters while receiving packets. Following trace was seen on affected system: ================================================================== BUG: KASAN: slab-use-after-free in j1939_sk_recv_match_one+0x1af/0x2d0 [can_j1939] Read of size 4 at addr ffff888012144014 by task j1939/350 CPU: 0 PID: 350 Comm: j1939 Tainted: G W OE 6.5.0-rc5 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 Call Trace: print_report+0xd3/0x620 ? kasan_complete_mode_report_info+0x7d/0x200 ? j1939_sk_recv_match_one+0x1af/0x2d0 [can_j1939] kasan_report+0xc2/0x100 ? j1939_sk_recv_match_one+0x1af/0x2d0 [can_j1939] __asan_load4+0x84/0xb0 j1939_sk_recv_match_one+0x1af/0x2d0 [can_j1939] j1939_sk_recv+0x20b/0x320 [can_j1939] ? __kasan_check_write+0x18/0x20 ? __pfx_j1939_sk_recv+0x10/0x10 [can_j1939] ? j1939_simple_recv+0x69/0x280 [can_j1939] ? j1939_ac_recv+0x5e/0x310 [can_j1939] j1939_can_recv+0x43f/0x580 [can_j1939] ? __pfx_j1939_can_recv+0x10/0x10 [can_j1939] ? raw_rcv+0x42/0x3c0 [can_raw] ? __pfx_j1939_can_recv+0x10/0x10 [can_j1939] can_rcv_filter+0x11f/0x350 [can] can_receive+0x12f/0x190 [can] ? __pfx_can_rcv+0x10/0x10 [can] can_rcv+0xdd/0x130 [can] ? __pfx_can_rcv+0x10/0x10 [can] __netif_receive_skb_one_core+0x13d/0x150 ? __pfx___netif_receive_skb_one_core+0x10/0x10 ? __kasan_check_write+0x18/0x20 ? _raw_spin_lock_irq+0x8c/0xe0 __netif_receive_skb+0x23/0xb0 process_backlog+0x107/0x260 __napi_poll+0x69/0x310 net_rx_action+0x2a1/0x580 ? __pfx_net_rx_action+0x10/0x10 ? __pfx__raw_spin_lock+0x10/0x10 ? handle_irq_event+0x7d/0xa0 __do_softirq+0xf3/0x3f8 do_softirq+0x53/0x80 </IRQ> <TASK> __local_bh_enable_ip+0x6e/0x70 netif_rx+0x16b/0x180 can_send+0x32b/0x520 [can] ? __pfx_can_send+0x10/0x10 [can] ? __check_object_size+0x299/0x410 raw_sendmsg+0x572/0x6d0 [can_raw] ? __pfx_raw_sendmsg+0x10/0x10 [can_raw] ? apparmor_socket_sendmsg+0x2f/0x40 ? __pfx_raw_sendmsg+0x10/0x10 [can_raw] sock_sendmsg+0xef/0x100 sock_write_iter+0x162/0x220 ? __pfx_sock_write_iter+0x10/0x10 ? __rtnl_unlock+0x47/0x80 ? security_file_permission+0x54/0x320 vfs_write+0x6ba/0x750 ? __pfx_vfs_write+0x10/0x10 ? __fget_light+0x1ca/0x1f0 ? __rcu_read_unlock+0x5b/0x280 ksys_write+0x143/0x170 ? __pfx_ksys_write+0x10/0x10 ? __kasan_check_read+0x15/0x20 ? fpregs_assert_state_consistent+0x62/0x70 __x64_sys_write+0x47/0x60 do_syscall_64+0x60/0x90 ? do_syscall_64+0x6d/0x90 ? irqentry_exit+0x3f/0x50 ? exc_page_fault+0x79/0xf0 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 Allocated by task 348: kasan_save_stack+0x2a/0x50 kasan_set_track+0x29/0x40 kasan_save_alloc_info+0x1f/0x30 __kasan_kmalloc+0xb5/0xc0 __kmalloc_node_track_caller+0x67/0x160 j1939_sk_setsockopt+0x284/0x450 [can_j1939] __sys_setsockopt+0x15c/0x2f0 __x64_sys_setsockopt+0x6b/0x80 do_syscall_64+0x60/0x90 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 Freed by task 349: kasan_save_stack+0x2a/0x50 kasan_set_track+0x29/0x40 kasan_save_free_info+0x2f/0x50 __kasan_slab_free+0x12e/0x1c0 __kmem_cache_free+0x1b9/0x380 kfree+0x7a/0x120 j1939_sk_setsockopt+0x3b2/0x450 [can_j1939] __sys_setsockopt+0x15c/0x2f0 __x64_sys_setsockopt+0x6b/0x80 do_syscall_64+0x60/0x90 entry_SYSCALL_64_after_hwframe+0x6e/0xd8
In the Linux kernel, the following vulnerability has been resolved: iio: core: fix memleak in iio_device_register_sysfs When iio_device_register_sysfs_group() fails, we should free iio_dev_opaque->chan_attr_group.attrs to prevent potential memleak.
In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: Unmap the surface before resetting it on a plane state Switch to a new plane state requires unreferencing of all held surfaces. In the work required for mob cursors the mapped surfaces started being cached but the variable indicating whether the surface is currently mapped was not being reset. This leads to crashes as the duplicated state, incorrectly, indicates the that surface is mapped even when no surface is present. That's because after unreferencing the surface it's perfectly possible for the plane to be backed by a bo instead of a surface. Reset the surface mapped flag when unreferencing the plane state surface to fix null derefs in cleanup. Fixes crashes in KDE KWin 6.0 on Wayland: Oops: 0000 [#1] PREEMPT SMP PTI CPU: 4 PID: 2533 Comm: kwin_wayland Not tainted 6.7.0-rc3-vmwgfx #2 Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020 RIP: 0010:vmw_du_cursor_plane_cleanup_fb+0x124/0x140 [vmwgfx] Code: 00 00 00 75 3a 48 83 c4 10 5b 5d c3 cc cc cc cc 48 8b b3 a8 00 00 00 48 c7 c7 99 90 43 c0 e8 93 c5 db ca 48 8b 83 a8 00 00 00 <48> 8b 78 28 e8 e3 f> RSP: 0018:ffffb6b98216fa80 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff969d84cdcb00 RCX: 0000000000000027 RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffff969e75f21600 RBP: ffff969d4143dc50 R08: 0000000000000000 R09: ffffb6b98216f920 R10: 0000000000000003 R11: ffff969e7feb3b10 R12: 0000000000000000 R13: 0000000000000000 R14: 000000000000027b R15: ffff969d49c9fc00 FS: 00007f1e8f1b4180(0000) GS:ffff969e75f00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000028 CR3: 0000000104006004 CR4: 00000000003706f0 Call Trace: <TASK> ? __die+0x23/0x70 ? page_fault_oops+0x171/0x4e0 ? exc_page_fault+0x7f/0x180 ? asm_exc_page_fault+0x26/0x30 ? vmw_du_cursor_plane_cleanup_fb+0x124/0x140 [vmwgfx] drm_atomic_helper_cleanup_planes+0x9b/0xc0 commit_tail+0xd1/0x130 drm_atomic_helper_commit+0x11a/0x140 drm_atomic_commit+0x97/0xd0 ? __pfx___drm_printfn_info+0x10/0x10 drm_atomic_helper_update_plane+0xf5/0x160 drm_mode_cursor_universal+0x10e/0x270 drm_mode_cursor_common+0x102/0x230 ? __pfx_drm_mode_cursor2_ioctl+0x10/0x10 drm_ioctl_kernel+0xb2/0x110 drm_ioctl+0x26d/0x4b0 ? __pfx_drm_mode_cursor2_ioctl+0x10/0x10 ? __pfx_drm_ioctl+0x10/0x10 vmw_generic_ioctl+0xa4/0x110 [vmwgfx] __x64_sys_ioctl+0x94/0xd0 do_syscall_64+0x61/0xe0 ? __x64_sys_ioctl+0xaf/0xd0 ? syscall_exit_to_user_mode+0x2b/0x40 ? do_syscall_64+0x70/0xe0 ? __x64_sys_ioctl+0xaf/0xd0 ? syscall_exit_to_user_mode+0x2b/0x40 ? do_syscall_64+0x70/0xe0 ? exc_page_fault+0x7f/0x180 entry_SYSCALL_64_after_hwframe+0x6e/0x76 RIP: 0033:0x7f1e93f279ed Code: 04 25 28 00 00 00 48 89 45 c8 31 c0 48 8d 45 10 c7 45 b0 10 00 00 00 48 89 45 b8 48 8d 45 d0 48 89 45 c0 b8 10 00 00 00 0f 05 <89> c2 3d 00 f0 ff f> RSP: 002b:00007ffca0faf600 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 000055db876ed2c0 RCX: 00007f1e93f279ed RDX: 00007ffca0faf6c0 RSI: 00000000c02464bb RDI: 0000000000000015 RBP: 00007ffca0faf650 R08: 000055db87184010 R09: 0000000000000007 R10: 000055db886471a0 R11: 0000000000000246 R12: 00007ffca0faf6c0 R13: 00000000c02464bb R14: 0000000000000015 R15: 00007ffca0faf790 </TASK> Modules linked in: snd_seq_dummy snd_hrtimer nf_conntrack_netbios_ns nf_conntrack_broadcast nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_ine> CR2: 0000000000000028 ---[ end trace 0000000000000000 ]--- RIP: 0010:vmw_du_cursor_plane_cleanup_fb+0x124/0x140 [vmwgfx] Code: 00 00 00 75 3a 48 83 c4 10 5b 5d c3 cc cc cc cc 48 8b b3 a8 00 00 00 48 c7 c7 99 90 43 c0 e8 93 c5 db ca 48 8b 83 a8 00 00 00 <48> 8b 78 28 e8 e3 f> RSP: 0018:ffffb6b98216fa80 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff969d84cdcb00 RCX: 0000000000000027 RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffff969e75f21600 RBP: ffff969d4143 ---truncated---
An array read overflow vulnerability was found in drivers/gpu/drm/vkms/vkms_composer.c in the Linux kernel. This issue may lead to a crash.
In the Linux kernel, the following vulnerability has been resolved: drm/tegra: dsi: Add missing check for of_find_device_by_node The Linux kernel CVE team has assigned CVE-2023-52650 to this issue. Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024050109-CVE-2023-52650-e2d1@gregkh/T
A flaw was found in the Linux kernel that addresses the removal of dead code related to `SCM_RIGHTS` support within the `io_uring`. This code was deemed unnecessary after the kernel dropped the ability to pass `io_uring` file descriptors over `SCM_RIGHTS`. The vulnerability was assigned CVE status due to removing this code, which was part of a cleanup process following the resolution of a previous CVE (CVE-2023-52654).
A vulnerability in the Linux kernel affected the x86/mm code, specifically in the `pfn_to_kaddr()` macro. The issue arises when the macro does not correctly handle input as a 64-bit type, causing crashes on 64-bit platforms, especially for SEV-SNP guests, when processing addresses above the 1TB range.
In the Linux kernel, the following vulnerability has been resolved: drm/tegra: rgb: Fix missing clk_put() in the error handling paths of tegra_dc_rgb_probe() The Linux kernel CVE team has assigned CVE-2023-52661 to this issue. Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024051738-CVE-2023-52661-5539@gregkh/T
In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: fix a memleak in vmw_gmrid_man_get_node The Linux kernel CVE team has assigned CVE-2023-52662 to this issue. Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024051740-CVE-2023-52662-1536@gregkh/T
In the Linux kernel, the following vulnerability has been resolved: ASoC: SOF: amd: Fix memory leak in amd_sof_acp_probe() The Linux kernel CVE team has assigned CVE-2023-52663 to this issue. Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024051740-CVE-2023-52663-1045@gregkh/T
A double free vulnerability exists in the linux kernel error handling logic such that aq_ring_free could be called multiple times on the same ring,if the system is under stress and gets a memory allocation error.This vulnerability could lead to the loss of system availability.
In the Linux kernel, the following vulnerability has been resolved: ALSA: scarlett2: Add clamp() in scarlett2_mixer_ctl_put() The Linux kernel CVE team has assigned CVE-2023-52674 to this issue. Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024051747-CVE-2023-52674-2aec@gregkh/T
In the Linux kernel, the following vulnerability has been resolved: bpf: Guard stack limits against 32bit overflow The Linux kernel CVE team has assigned CVE-2023-52676 to this issue. Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024051749-CVE-2023-52676-e224@gregkh/T
In the Linux kernel, the following vulnerability has been resolved: of: Fix double free in of_parse_phandle_with_args_map The Linux kernel CVE team has assigned CVE-2023-52679 to this issue. Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024051750-CVE-2023-52679-948f@gregkh/T
In the Linux kernel, the following vulnerability has been resolved: ALSA: scarlett2: Add missing error checks to *_ctl_get() The Linux kernel CVE team has assigned CVE-2023-52680 to this issue. Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024051750-CVE-2023-52680-1f4a@gregkh/T
In the Linux kernel, the following vulnerability has been resolved: ACPI: LPIT: Avoid u32 multiplication overflow The Linux kernel CVE team has assigned CVE-2023-52683 to this issue. Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024051751-CVE-2023-52683-f280@gregkh/T
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: ALSA: scarlett2: Add missing mutex lock around get meter levels The Linux kernel CVE team has assigned CVE-2023-52689 to this issue. Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024051753-CVE-2023-52689-f657@gregkh/T
In the Linux kernel, the following vulnerability has been resolved: powerpc/powernv: Add a null pointer check to scom_debug_init_one() The Linux kernel CVE team has assigned CVE-2023-52690 to this issue. Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024051753-CVE-2023-52690-f225@gregkh/T
In the Linux kernel, the following vulnerability has been resolved: powerpc/powernv: Add a null pointer check in opal_powercap_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: ASoC: Intel: sof_sdw_rt_sdca_jack_common: ctx->headset_codec_dev = NULL The Linux kernel CVE team has assigned CVE-2023-52697 to this issue. Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024051755-CVE-2023-52697-1b7f@gregkh/T
In the Linux kernel, the following vulnerability has been resolved: calipso: fix memory leak in netlbl_calipso_add_pass() The Linux kernel CVE team has assigned CVE-2023-52698 to this issue. Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024051756-CVE-2023-52698-bbc2@gregkh/T
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: mmc: sdio: fix possible resource leaks in some error paths If sdio_add_func() or sdio_init_func() fails, sdio_remove_func() can not release the resources, because the sdio function is not presented in these two cases, it won't call of_node_put() or put_device(). To fix these leaks, make sdio_func_present() only control whether device_del() needs to be called or not, then always call of_node_put() and put_device(). In error case in sdio_init_func(), the reference of 'card->dev' is not get, to avoid redundant put in sdio_free_func_cis(), move the get_device() to sdio_alloc_func() and put_device() to sdio_release_func(), it can keep the get/put function be balanced. Without this patch, while doing fault inject test, it can get the following leak reports, after this fix, the leak is gone. unreferenced object 0xffff888112514000 (size 2048): comm "kworker/3:2", pid 65, jiffies 4294741614 (age 124.774s) hex dump (first 32 bytes): 00 e0 6f 12 81 88 ff ff 60 58 8d 06 81 88 ff ff ..o.....`X...... 10 40 51 12 81 88 ff ff 10 40 51 12 81 88 ff ff .@Q......@Q..... backtrace: [<000000009e5931da>] kmalloc_trace+0x21/0x110 [<000000002f839ccb>] mmc_alloc_card+0x38/0xb0 [mmc_core] [<0000000004adcbf6>] mmc_sdio_init_card+0xde/0x170 [mmc_core] [<000000007538fea0>] mmc_attach_sdio+0xcb/0x1b0 [mmc_core] [<00000000d4fdeba7>] mmc_rescan+0x54a/0x640 [mmc_core] unreferenced object 0xffff888112511000 (size 2048): comm "kworker/3:2", pid 65, jiffies 4294741623 (age 124.766s) hex dump (first 32 bytes): 00 40 51 12 81 88 ff ff e0 58 8d 06 81 88 ff ff .@Q......X...... 10 10 51 12 81 88 ff ff 10 10 51 12 81 88 ff ff ..Q.......Q..... backtrace: [<000000009e5931da>] kmalloc_trace+0x21/0x110 [<00000000fcbe706c>] sdio_alloc_func+0x35/0x100 [mmc_core] [<00000000c68f4b50>] mmc_attach_sdio.cold.18+0xb1/0x395 [mmc_core] [<00000000d4fdeba7>] mmc_rescan+0x54a/0x640 [mmc_core]
In the Linux kernel, the following vulnerability has been resolved: fbdev: Fix invalid page access after closing deferred I/O devices When a fbdev with deferred I/O is once opened and closed, the dirty pages still remain queued in the pageref list, and eventually later those may be processed in the delayed work. This may lead to a corruption of pages, hitting an Oops. This patch makes sure to cancel the delayed work and clean up the pageref list at closing the device for addressing the bug. A part of the cleanup code is factored out as a new helper function that is called from the common fb_release().
In the Linux kernel, the following vulnerability has been resolved: powerpc/64s/interrupt: Fix interrupt exit race with security mitigation switch The RFI and STF security mitigation options can flip the interrupt_exit_not_reentrant static branch condition concurrently with the interrupt exit code which tests that branch. Interrupt exit tests this condition to set MSR[EE|RI] for exit, then again in the case a soft-masked interrupt is found pending, to recover the MSR so the interrupt can be replayed before attempting to exit again. If the condition changes between these two tests, the MSR and irq soft-mask state will become corrupted, leading to warnings and possible crashes. For example, if the branch is initially true then false, MSR[EE] will be 0 but PACA_IRQ_HARD_DIS clear and EE may not get enabled, leading to warnings in irq_64.c.
In the Linux kernel, the following vulnerability has been resolved: spi: Fix null dereference on suspend A race condition exists where a synchronous (noqueue) transfer can be active during a system suspend. This can cause a null pointer dereference exception to occur when the system resumes. Example order of events leading to the exception: 1. spi_sync() calls __spi_transfer_message_noqueue() which sets ctlr->cur_msg 2. Spi transfer begins via spi_transfer_one_message() 3. System is suspended interrupting the transfer context 4. System is resumed 6. spi_controller_resume() calls spi_start_queue() which resets cur_msg to NULL 7. Spi transfer context resumes and spi_finalize_current_message() is called which dereferences cur_msg (which is now NULL) Wait for synchronous transfers to complete before suspending by acquiring the bus mutex and setting/checking a suspend flag.
In the Linux kernel, the following vulnerability has been resolved: smb: client: fix use-after-free in smb2_query_info_compound() The following UAF was triggered when running fstests generic/072 with KASAN enabled against Windows Server 2022 and mount options 'multichannel,max_channels=2,vers=3.1.1,mfsymlinks,noperm' BUG: KASAN: slab-use-after-free in smb2_query_info_compound+0x423/0x6d0 [cifs] Read of size 8 at addr ffff888014941048 by task xfs_io/27534 CPU: 0 PID: 27534 Comm: xfs_io Not tainted 6.6.0-rc7 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.2-3-gd478f380-rebuilt.opensuse.org 04/01/2014 Call Trace: dump_stack_lvl+0x4a/0x80 print_report+0xcf/0x650 ? srso_alias_return_thunk+0x5/0x7f ? srso_alias_return_thunk+0x5/0x7f ? __phys_addr+0x46/0x90 kasan_report+0xda/0x110 ? smb2_query_info_compound+0x423/0x6d0 [cifs] ? smb2_query_info_compound+0x423/0x6d0 [cifs] smb2_query_info_compound+0x423/0x6d0 [cifs] ? __pfx_smb2_query_info_compound+0x10/0x10 [cifs] ? srso_alias_return_thunk+0x5/0x7f ? __stack_depot_save+0x39/0x480 ? kasan_save_stack+0x33/0x60 ? kasan_set_track+0x25/0x30 ? ____kasan_slab_free+0x126/0x170 smb2_queryfs+0xc2/0x2c0 [cifs] ? __pfx_smb2_queryfs+0x10/0x10 [cifs] ? __pfx___lock_acquire+0x10/0x10 smb311_queryfs+0x210/0x220 [cifs] ? __pfx_smb311_queryfs+0x10/0x10 [cifs] ? srso_alias_return_thunk+0x5/0x7f ? __lock_acquire+0x480/0x26c0 ? lock_release+0x1ed/0x640 ? srso_alias_return_thunk+0x5/0x7f ? do_raw_spin_unlock+0x9b/0x100 cifs_statfs+0x18c/0x4b0 [cifs] statfs_by_dentry+0x9b/0xf0 fd_statfs+0x4e/0xb0 __do_sys_fstatfs+0x7f/0xe0 ? __pfx___do_sys_fstatfs+0x10/0x10 ? srso_alias_return_thunk+0x5/0x7f ? lockdep_hardirqs_on_prepare+0x136/0x200 ? srso_alias_return_thunk+0x5/0x7f do_syscall_64+0x3f/0x90 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 Allocated by task 27534: kasan_save_stack+0x33/0x60 kasan_set_track+0x25/0x30 __kasan_kmalloc+0x8f/0xa0 open_cached_dir+0x71b/0x1240 [cifs] smb2_query_info_compound+0x5c3/0x6d0 [cifs] smb2_queryfs+0xc2/0x2c0 [cifs] smb311_queryfs+0x210/0x220 [cifs] cifs_statfs+0x18c/0x4b0 [cifs] statfs_by_dentry+0x9b/0xf0 fd_statfs+0x4e/0xb0 __do_sys_fstatfs+0x7f/0xe0 do_syscall_64+0x3f/0x90 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 Freed by task 27534: kasan_save_stack+0x33/0x60 kasan_set_track+0x25/0x30 kasan_save_free_info+0x2b/0x50 ____kasan_slab_free+0x126/0x170 slab_free_freelist_hook+0xd0/0x1e0 __kmem_cache_free+0x9d/0x1b0 open_cached_dir+0xff5/0x1240 [cifs] smb2_query_info_compound+0x5c3/0x6d0 [cifs] smb2_queryfs+0xc2/0x2c0 [cifs] This is a race between open_cached_dir() and cached_dir_lease_break() where the cache entry for the open directory handle receives a lease break while creating it. And before returning from open_cached_dir(), we put the last reference of the new @cfid because of !@cfid->has_lease. Besides the UAF, while running xfstests a lot of missed lease breaks have been noticed in tests that run several concurrent statfs(2) calls on those cached fids CIFS: VFS: \\w22-root1.gandalf.test No task to wake, unknown frame... CIFS: VFS: \\w22-root1.gandalf.test Cmd: 18 Err: 0x0 Flags: 0x1... CIFS: VFS: \\w22-root1.gandalf.test smb buf 00000000715bfe83 len 108 CIFS: VFS: Dump pending requests: CIFS: VFS: \\w22-root1.gandalf.test No task to wake, unknown frame... CIFS: VFS: \\w22-root1.gandalf.test Cmd: 18 Err: 0x0 Flags: 0x1... CIFS: VFS: \\w22-root1.gandalf.test smb buf 000000005aa7316e len 108 ... To fix both, in open_cached_dir() ensure that @cfid->has_lease is set right before sending out compounded request so that any potential lease break will be get processed by demultiplex thread while we're still caching @cfid. And, if open failed for some reason, re-check @cfid->has_lease to decide whether or not put lease reference.
[REJECTED CVE] A double shift vulnerability was identified in the Linux kernel's pwm subsystem. The issue involves passing a shifted value instead of a bit number to set/test_bit() functions, resulting in a double shift (e.g., BIT(BIT(1))). While this doesn't cause problems for values 0 or 1, values of 5 or higher could lead to a buffer overflow, potentially allowing attackers to cause a denial of service.
In the Linux kernel, the following vulnerability has been resolved: smb: client: fix potential deadlock when releasing mids All release_mid() callers seem to hold a reference of @mid so there is no need to call kref_put(&mid->refcount, __release_mid) under @server->mid_lock spinlock. If they don't, then an use-after-free bug would have occurred anyways. By getting rid of such spinlock also fixes a potential deadlock as shown below CPU 0 CPU 1 ------------------------------------------------------------------ cifs_demultiplex_thread() cifs_debug_data_proc_show() release_mid() spin_lock(&server->mid_lock); spin_lock(&cifs_tcp_ses_lock) spin_lock(&server->mid_lock) __release_mid() smb2_find_smb_tcon() spin_lock(&cifs_tcp_ses_lock) *deadlock*
[REJECTED CVE] In the Linux kernel, the following vulnerability has been resolved: i2c: dev: copy userspace array safely i2c-dev.c utilizes memdup_user() to copy a userspace array. This is done without an overflow check. Use the new wrapper memdup_array_user() to copy the array more safely.
In the Linux kernel, the following vulnerability has been resolved: virtio-blk: fix implicit overflow on virtio_max_dma_size The following codes have an implicit conversion from size_t to u32: (u32)max_size = (size_t)virtio_max_dma_size(vdev); This may lead overflow, Ex (size_t)4G -> (u32)0. Once virtio_max_dma_size() has a larger size than U32_MAX, use U32_MAX instead.
In the Linux kernel, the following vulnerability has been resolved: net/smc: avoid data corruption caused by decline We found a data corruption issue during testing of SMC-R on Redis applications. The benchmark has a low probability of reporting a strange error as shown below. "Error: Protocol error, got "\xe2" as reply type byte" Finally, we found that the retrieved error data was as follows: 0xE2 0xD4 0xC3 0xD9 0x04 0x00 0x2C 0x20 0xA6 0x56 0x00 0x16 0x3E 0x0C 0xCB 0x04 0x02 0x01 0x00 0x00 0x20 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0xE2 It is quite obvious that this is a SMC DECLINE message, which means that the applications received SMC protocol message. We found that this was caused by the following situations: client server ¦ clc proposal -------------> ¦ clc accept <------------- ¦ clc confirm -------------> wait llc confirm send llc confirm ¦failed llc confirm ¦ x------ (after 2s)timeout wait llc confirm rsp wait decline (after 1s) timeout (after 2s) timeout ¦ decline --------------> ¦ decline <-------------- As a result, a decline message was sent in the implementation, and this message was read from TCP by the already-fallback connection. This patch double the client timeout as 2x of the server value, With this simple change, the Decline messages should never cross or collide (during Confirm link timeout). This issue requires an immediate solution, since the protocol updates involve a more long-term solution.
In the Linux kernel, the following vulnerability has been resolved: bonding: stop the device in bond_setup_by_slave() Commit 9eed321cde22 ("net: lapbether: only support ethernet devices") has been able to keep syzbot away from net/lapb, until today. In the following splat [1], the issue is that a lapbether device has been created on a bonding device without members. Then adding a non ARPHRD_ETHER member forced the bonding master to change its type. The fix is to make sure we call dev_close() in bond_setup_by_slave() so that the potential linked lapbether devices (or any other devices having assumptions on the physical device) are removed. A similar bug has been addressed in commit 40baec225765 ("bonding: fix panic on non-ARPHRD_ETHER enslave failure") [1] skbuff: skb_under_panic: text:ffff800089508810 len:44 put:40 head:ffff0000c78e7c00 data:ffff0000c78e7bea tail:0x16 end:0x140 dev:bond0 kernel BUG at net/core/skbuff.c:192 ! Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP Modules linked in: CPU: 0 PID: 6007 Comm: syz-executor383 Not tainted 6.6.0-rc3-syzkaller-gbf6547d8715b #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/04/2023 pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : skb_panic net/core/skbuff.c:188 [inline] pc : skb_under_panic+0x13c/0x140 net/core/skbuff.c:202 lr : skb_panic net/core/skbuff.c:188 [inline] lr : skb_under_panic+0x13c/0x140 net/core/skbuff.c:202 sp : ffff800096a06aa0 x29: ffff800096a06ab0 x28: ffff800096a06ba0 x27: dfff800000000000 x26: ffff0000ce9b9b50 x25: 0000000000000016 x24: ffff0000c78e7bea x23: ffff0000c78e7c00 x22: 000000000000002c x21: 0000000000000140 x20: 0000000000000028 x19: ffff800089508810 x18: ffff800096a06100 x17: 0000000000000000 x16: ffff80008a629a3c x15: 0000000000000001 x14: 1fffe00036837a32 x13: 0000000000000000 x12: 0000000000000000 x11: 0000000000000201 x10: 0000000000000000 x9 : cb50b496c519aa00 x8 : cb50b496c519aa00 x7 : 0000000000000001 x6 : 0000000000000001 x5 : ffff800096a063b8 x4 : ffff80008e280f80 x3 : ffff8000805ad11c x2 : 0000000000000001 x1 : 0000000100000201 x0 : 0000000000000086 Call trace: skb_panic net/core/skbuff.c:188 [inline] skb_under_panic+0x13c/0x140 net/core/skbuff.c:202 skb_push+0xf0/0x108 net/core/skbuff.c:2446 ip6gre_header+0xbc/0x738 net/ipv6/ip6_gre.c:1384 dev_hard_header include/linux/netdevice.h:3136 [inline] lapbeth_data_transmit+0x1c4/0x298 drivers/net/wan/lapbether.c:257 lapb_data_transmit+0x8c/0xb0 net/lapb/lapb_iface.c:447 lapb_transmit_buffer+0x178/0x204 net/lapb/lapb_out.c:149 lapb_send_control+0x220/0x320 net/lapb/lapb_subr.c:251 __lapb_disconnect_request+0x9c/0x17c net/lapb/lapb_iface.c:326 lapb_device_event+0x288/0x4e0 net/lapb/lapb_iface.c:492 notifier_call_chain+0x1a4/0x510 kernel/notifier.c:93 raw_notifier_call_chain+0x3c/0x50 kernel/notifier.c:461 call_netdevice_notifiers_info net/core/dev.c:1970 [inline] call_netdevice_notifiers_extack net/core/dev.c:2008 [inline] call_netdevice_notifiers net/core/dev.c:2022 [inline] __dev_close_many+0x1b8/0x3c4 net/core/dev.c:1508 dev_close_many+0x1e0/0x470 net/core/dev.c:1559 dev_close+0x174/0x250 net/core/dev.c:1585 lapbeth_device_event+0x2e4/0x958 drivers/net/wan/lapbether.c:466 notifier_call_chain+0x1a4/0x510 kernel/notifier.c:93 raw_notifier_call_chain+0x3c/0x50 kernel/notifier.c:461 call_netdevice_notifiers_info net/core/dev.c:1970 [inline] call_netdevice_notifiers_extack net/core/dev.c:2008 [inline] call_netdevice_notifiers net/core/dev.c:2022 [inline] __dev_close_many+0x1b8/0x3c4 net/core/dev.c:1508 dev_close_many+0x1e0/0x470 net/core/dev.c:1559 dev_close+0x174/0x250 net/core/dev.c:1585 bond_enslave+0x2298/0x30cc drivers/net/bonding/bond_main.c:2332 bond_do_ioctl+0x268/0xc64 drivers/net/bonding/bond_main.c:4539 dev_ifsioc+0x754/0x9ac dev_ioctl+0x4d8/0xd34 net/core/dev_ioctl.c:786 sock_do_ioctl+0x1d4/0x2d0 net/socket.c:1217 sock_ioctl+0x4e8/0x834 net/socket.c:1322 vfs_ioctl fs/ioctl.c:51 [inline] __do_ ---truncated---
In the Linux kernel, the following vulnerability has been resolved: i915/perf: Fix NULL deref bugs with drm_dbg() calls When i915 perf interface is not available dereferencing it will lead to NULL dereferences. As returning -ENOTSUPP is pretty clear return when perf interface is not available. [tursulin: added stable tag] (cherry picked from commit 36f27350ff745bd228ab04d7845dfbffc177a889)
In the Linux kernel, the following vulnerability has been resolved: i2c: core: Run atomic i2c xfer when !preemptible Since bae1d3a05a8b, i2c transfers are non-atomic if preemption is disabled. However, non-atomic i2c transfers require preemption (e.g. in wait_for_completion() while waiting for the DMA). panic() calls preempt_disable_notrace() before calling emergency_restart(). Therefore, if an i2c device is used for the restart, the xfer should be atomic. This avoids warnings like: [ 12.667612] WARNING: CPU: 1 PID: 1 at kernel/rcu/tree_plugin.h:318 rcu_note_context_switch+0x33c/0x6b0 [ 12.676926] Voluntary context switch within RCU read-side critical section! ... [ 12.742376] schedule_timeout from wait_for_completion_timeout+0x90/0x114 [ 12.749179] wait_for_completion_timeout from tegra_i2c_wait_completion+0x40/0x70 ... [ 12.994527] atomic_notifier_call_chain from machine_restart+0x34/0x58 [ 13.001050] machine_restart from panic+0x2a8/0x32c Use !preemptible() instead, which is basically the same check as pre-v5.2.
In the Linux kernel, the following vulnerability has been resolved: scsi: ibmvfc: Remove BUG_ON in the case of an empty event pool In practice the driver should never send more commands than are allocated to a queue's event pool. In the unlikely event that this happens, the code asserts a BUG_ON, and in the case that the kernel is not configured to crash on panic returns a junk event pointer from the empty event list causing things to spiral from there. This BUG_ON is a historical artifact of the ibmvfc driver first being upstreamed, and it is well known now that the use of BUG_ON is bad practice except in the most unrecoverable scenario. There is nothing about this scenario that prevents the driver from recovering and carrying on. Remove the BUG_ON in question from ibmvfc_get_event() and return a NULL pointer in the case of an empty event pool. Update all call sites to ibmvfc_get_event() to check for a NULL pointer and perfrom the appropriate failure or recovery action.
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: drm/amdgpu: Fix potential null pointer derefernce The amdgpu_ras_get_context may return NULL if device not support ras feature, so add check before using.
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Fix a null pointer access when the smc_rreg pointer is NULL In certain types of chips, such as VEGA20, reading the amdgpu_regs_smc file could result in an abnormal null pointer access when the smc_rreg pointer is NULL. Below are the steps to reproduce this issue and the corresponding exception log: 1. Navigate to the directory: /sys/kernel/debug/dri/0 2. Execute command: cat amdgpu_regs_smc 3. Exception Log:: [4005007.702554] BUG: kernel NULL pointer dereference, address: 0000000000000000 [4005007.702562] #PF: supervisor instruction fetch in kernel mode [4005007.702567] #PF: error_code(0x0010) - not-present page [4005007.702570] PGD 0 P4D 0 [4005007.702576] Oops: 0010 [#1] SMP NOPTI [4005007.702581] CPU: 4 PID: 62563 Comm: cat Tainted: G OE 5.15.0-43-generic #46-Ubunt u [4005007.702590] RIP: 0010:0x0 [4005007.702598] Code: Unable to access opcode bytes at RIP 0xffffffffffffffd6. [4005007.702600] RSP: 0018:ffffa82b46d27da0 EFLAGS: 00010206 [4005007.702605] RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffa82b46d27e68 [4005007.702609] RDX: 0000000000000001 RSI: 0000000000000000 RDI: ffff9940656e0000 [4005007.702612] RBP: ffffa82b46d27dd8 R08: 0000000000000000 R09: ffff994060c07980 [4005007.702615] R10: 0000000000020000 R11: 0000000000000000 R12: 00007f5e06753000 [4005007.702618] R13: ffff9940656e0000 R14: ffffa82b46d27e68 R15: 00007f5e06753000 [4005007.702622] FS: 00007f5e0755b740(0000) GS:ffff99479d300000(0000) knlGS:0000000000000000 [4005007.702626] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [4005007.702629] CR2: ffffffffffffffd6 CR3: 00000003253fc000 CR4: 00000000003506e0 [4005007.702633] Call Trace: [4005007.702636] <TASK> [4005007.702640] amdgpu_debugfs_regs_smc_read+0xb0/0x120 [amdgpu] [4005007.703002] full_proxy_read+0x5c/0x80 [4005007.703011] vfs_read+0x9f/0x1a0 [4005007.703019] ksys_read+0x67/0xe0 [4005007.703023] __x64_sys_read+0x19/0x20 [4005007.703028] do_syscall_64+0x5c/0xc0 [4005007.703034] ? do_user_addr_fault+0x1e3/0x670 [4005007.703040] ? exit_to_user_mode_prepare+0x37/0xb0 [4005007.703047] ? irqentry_exit_to_user_mode+0x9/0x20 [4005007.703052] ? irqentry_exit+0x19/0x30 [4005007.703057] ? exc_page_fault+0x89/0x160 [4005007.703062] ? asm_exc_page_fault+0x8/0x30 [4005007.703068] entry_SYSCALL_64_after_hwframe+0x44/0xae [4005007.703075] RIP: 0033:0x7f5e07672992 [4005007.703079] Code: c0 e9 b2 fe ff ff 50 48 8d 3d fa b2 0c 00 e8 c5 1d 02 00 0f 1f 44 00 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 0f 05 <48> 3d 00 f0 ff ff 77 56 c3 0f 1f 44 00 00 48 83 e c 28 48 89 54 24 [4005007.703083] RSP: 002b:00007ffe03097898 EFLAGS: 00000246 ORIG_RAX: 0000000000000000 [4005007.703088] RAX: ffffffffffffffda RBX: 0000000000020000 RCX: 00007f5e07672992 [4005007.703091] RDX: 0000000000020000 RSI: 00007f5e06753000 RDI: 0000000000000003 [4005007.703094] RBP: 00007f5e06753000 R08: 00007f5e06752010 R09: 00007f5e06752010 [4005007.703096] R10: 0000000000000022 R11: 0000000000000246 R12: 0000000000022000 [4005007.703099] R13: 0000000000000003 R14: 0000000000020000 R15: 0000000000020000 [4005007.703105] </TASK> [4005007.703107] Modules linked in: nf_tables libcrc32c nfnetlink algif_hash af_alg binfmt_misc nls_ iso8859_1 ipmi_ssif ast intel_rapl_msr intel_rapl_common drm_vram_helper drm_ttm_helper amd64_edac t tm edac_mce_amd kvm_amd ccp mac_hid k10temp kvm acpi_ipmi ipmi_si rapl sch_fq_codel ipmi_devintf ipm i_msghandler msr parport_pc ppdev lp parport mtd pstore_blk efi_pstore ramoops pstore_zone reed_solo mon ip_tables x_tables autofs4 ib_uverbs ib_core amdgpu(OE) amddrm_ttm_helper(OE) amdttm(OE) iommu_v 2 amd_sched(OE) amdkcl(OE) drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops cec rc_core drm igb ahci xhci_pci libahci i2c_piix4 i2c_algo_bit xhci_pci_renesas dca [4005007.703184] CR2: 0000000000000000 [4005007.703188] ---[ en ---truncated---
In the Linux kernel, the following vulnerability has been resolved: drm/amd: Fix UBSAN array-index-out-of-bounds for Polaris and Tonga For pptable structs that use flexible array sizes, use flexible arrays.
In the Linux kernel, the following vulnerability has been resolved: cpu/hotplug: Don't offline the last non-isolated CPU If a system has isolated CPUs via the "isolcpus=" command line parameter, then an attempt to offline the last housekeeping CPU will result in a WARN_ON() when rebuilding the scheduler domains and a subsequent panic due to and unhandled empty CPU mas in partition_sched_domains_locked(). cpuset_hotplug_workfn() rebuild_sched_domains_locked() ndoms = generate_sched_domains(&doms, &attr); cpumask_and(doms[0], top_cpuset.effective_cpus, housekeeping_cpumask(HK_FLAG_DOMAIN)); Thus results in an empty CPU mask which triggers the warning and then the subsequent crash: WARNING: CPU: 4 PID: 80 at kernel/sched/topology.c:2366 build_sched_domains+0x120c/0x1408 Call trace: build_sched_domains+0x120c/0x1408 partition_sched_domains_locked+0x234/0x880 rebuild_sched_domains_locked+0x37c/0x798 rebuild_sched_domains+0x30/0x58 cpuset_hotplug_workfn+0x2a8/0x930 Unable to handle kernel paging request at virtual address fffe80027ab37080 partition_sched_domains_locked+0x318/0x880 rebuild_sched_domains_locked+0x37c/0x798 Aside of the resulting crash, it does not make any sense to offline the last last housekeeping CPU. Prevent this by masking out the non-housekeeping CPUs when selecting a target CPU for initiating the CPU unplug operation via the work queue.
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btusb: Add date->evt_skb is NULL check fix crash because of null pointers [ 6104.969662] BUG: kernel NULL pointer dereference, address: 00000000000000c8 [ 6104.969667] #PF: supervisor read access in kernel mode [ 6104.969668] #PF: error_code(0x0000) - not-present page [ 6104.969670] PGD 0 P4D 0 [ 6104.969673] Oops: 0000 [#1] SMP NOPTI [ 6104.969684] RIP: 0010:btusb_mtk_hci_wmt_sync+0x144/0x220 [btusb] [ 6104.969688] RSP: 0018:ffffb8d681533d48 EFLAGS: 00010246 [ 6104.969689] RAX: 0000000000000000 RBX: ffff8ad560bb2000 RCX: 0000000000000006 [ 6104.969691] RDX: 0000000000000000 RSI: ffffb8d681533d08 RDI: 0000000000000000 [ 6104.969692] RBP: ffffb8d681533d70 R08: 0000000000000001 R09: 0000000000000001 [ 6104.969694] R10: 0000000000000001 R11: 00000000fa83b2da R12: ffff8ad461d1d7c0 [ 6104.969695] R13: 0000000000000000 R14: ffff8ad459618c18 R15: ffffb8d681533d90 [ 6104.969697] FS: 00007f5a1cab9d40(0000) GS:ffff8ad578200000(0000) knlGS:00000 [ 6104.969699] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 6104.969700] CR2: 00000000000000c8 CR3: 000000018620c001 CR4: 0000000000760ef0 [ 6104.969701] PKRU: 55555554 [ 6104.969702] Call Trace: [ 6104.969708] btusb_mtk_shutdown+0x44/0x80 [btusb] [ 6104.969732] hci_dev_do_close+0x470/0x5c0 [bluetooth] [ 6104.969748] hci_rfkill_set_block+0x56/0xa0 [bluetooth] [ 6104.969753] rfkill_set_block+0x92/0x160 [ 6104.969755] rfkill_fop_write+0x136/0x1e0 [ 6104.969759] __vfs_write+0x18/0x40 [ 6104.969761] vfs_write+0xdf/0x1c0 [ 6104.969763] ksys_write+0xb1/0xe0 [ 6104.969765] __x64_sys_write+0x1a/0x20 [ 6104.969769] do_syscall_64+0x51/0x180 [ 6104.969771] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 6104.969773] RIP: 0033:0x7f5a21f18fef [ 6104.9] RSP: 002b:00007ffeefe39010 EFLAGS: 00000293 ORIG_RAX: 0000000000000001 [ 6104.969780] RAX: ffffffffffffffda RBX: 000055c10a7560a0 RCX: 00007f5a21f18fef [ 6104.969781] RDX: 0000000000000008 RSI: 00007ffeefe39060 RDI: 0000000000000012 [ 6104.969782] RBP: 00007ffeefe39060 R08: 0000000000000000 R09: 0000000000000017 [ 6104.969784] R10: 00007ffeefe38d97 R11: 0000000000000293 R12: 0000000000000002 [ 6104.969785] R13: 00007ffeefe39220 R14: 00007ffeefe391a0 R15: 000055c10a72acf0
In the Linux kernel, the following vulnerability has been resolved: atl1c: Work around the DMA RX overflow issue This is based on alx driver commit 881d0327db37 ("net: alx: Work around the DMA RX overflow issue"). The alx and atl1c drivers had RX overflow error which was why a custom allocator was created to avoid certain addresses. The simpler workaround then created for alx driver, but not for atl1c due to lack of tester. Instead of using a custom allocator, check the allocated skb address and use skb_reserve() to move away from problematic 0x...fc0 address. Tested on AR8131 on Acer 4540.
In the Linux kernel, the following vulnerability has been resolved: nbd: fix uaf in nbd_open Commit 4af5f2e03013 ("nbd: use blk_mq_alloc_disk and blk_cleanup_disk") cleans up disk by blk_cleanup_disk() and it won't set disk->private_data as NULL as before. UAF may be triggered in nbd_open() if someone tries to open nbd device right after nbd_put() since nbd has been free in nbd_dev_remove(). Fix this by implementing ->free_disk and free private data in it.
In the Linux kernel, the following vulnerability has been resolved: Input: synaptics-rmi4 - fix use after free in rmi_unregister_function() The put_device() calls rmi_release_function() which frees "fn" so the dereference on the next line "fn->num_of_irqs" is a use after free. Move the put_device() to the end to fix this.
In the Linux kernel, the following vulnerability has been resolved: perf: hisi: Fix use-after-free when register pmu fails When we fail to register the uncore pmu, the pmu context may not been allocated. The error handing will call cpuhp_state_remove_instance() to call uncore pmu offline callback, which migrate the pmu context. Since that's liable to lead to some kind of use-after-free. Use cpuhp_state_remove_instance_nocalls() instead of cpuhp_state_remove_instance() so that the notifiers don't execute after the PMU device has been failed to register.
In the Linux kernel, the following vulnerability has been resolved: drm/radeon: possible buffer overflow Buffer 'afmt_status' of size 6 could overflow, since index 'afmt_idx' is checked after access.
In the Linux kernel, the following vulnerability has been resolved: pstore/platform: Add check for kstrdup Add check for the return value of kstrdup() and return the error if it fails in order to avoid NULL pointer dereference.
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.
In the Linux kernel, the following vulnerability has been resolved: nommu: fix memory leak in do_mmap() error path The preallocation of the maple tree nodes may leak if the error path to "error_just_free" is taken. Fix this by moving the freeing of the maple tree nodes to a shared location for all error paths.
In the Linux kernel, the following vulnerability has been resolved: mm/swapfile: add cond_resched() in get_swap_pages() The softlockup still occurs in get_swap_pages() under memory pressure. 64 CPU cores, 64GB memory, and 28 zram devices, the disksize of each zram device is 50MB with same priority as si. Use the stress-ng tool to increase memory pressure, causing the system to oom frequently. The plist_for_each_entry_safe() loops in get_swap_pages() could reach tens of thousands of times to find available space (extreme case: cond_resched() is not called in scan_swap_map_slots()). Let's add cond_resched() into get_swap_pages() when failed to find available space to avoid softlockup.
A vulnerability was found in the Linux kernel's memory management subsystem in the `retract_page_tables()` function. A race condition involving locks during page table removal may cause a use-after-free scenario.
In the Linux kernel, the following vulnerability has been resolved: platform/chrome: cros_ec_chardev: fix kernel data leak from ioctl It is possible to peep kernel page's data by providing larger `insize` in struct cros_ec_command[1] when invoking EC host commands. Fix it by using zeroed memory. [1]: https://elixir.bootlin.com/linux/v6.2/source/include/linux/platform_data/cros_ec_proto.h#L74
In the Linux kernel, the following vulnerability has been resolved: net: usb: lan78xx: Limit packet length to skb->len Packet length retrieved from descriptor may be larger than the actual socket buffer length. In such case the cloned skb passed up the network stack will leak kernel memory contents. Additionally prevent integer underflow when size is less than ETH_FCS_LEN.
In the Linux kernel, the following vulnerability has been resolved: tty: pcn_uart: fix memory leak with using debugfs_lookup() When calling debugfs_lookup() the result must have dput() called on it, otherwise the memory will leak over time. To make things simpler, just call debugfs_lookup_and_remove() instead which handles all of the logic at once.
In the Linux kernel, the following vulnerability has been resolved: serial: 8250: Reinit port->pm on port specific driver unbind When we unbind a serial port hardware specific 8250 driver, the generic serial8250 driver takes over the port. After that we see an oops about 10 seconds later. This can produce the following at least on some TI SoCs: Unhandled fault: imprecise external abort (0x1406) Internal error: : 1406 [#1] SMP ARM Turns out that we may still have the serial port hardware specific driver port->pm in use, and serial8250_pm() tries to call it after the port specific driver is gone: serial8250_pm [8250_base] from uart_change_pm+0x54/0x8c [serial_base] uart_change_pm [serial_base] from uart_hangup+0x154/0x198 [serial_base] uart_hangup [serial_base] from __tty_hangup.part.0+0x328/0x37c __tty_hangup.part.0 from disassociate_ctty+0x154/0x20c disassociate_ctty from do_exit+0x744/0xaac do_exit from do_group_exit+0x40/0x8c do_group_exit from __wake_up_parent+0x0/0x1c Let's fix the issue by calling serial8250_set_defaults() in serial8250_unregister_port(). This will set the port back to using the serial8250 default functions, and sets the port->pm to point to serial8250_pm.
In the Linux kernel, the following vulnerability has been resolved: mm: fix zswap writeback race condition The zswap writeback mechanism can cause a race condition resulting in memory corruption, where a swapped out page gets swapped in with data that was written to a different page. The race unfolds like this: 1. a page with data A and swap offset X is stored in zswap 2. page A is removed off the LRU by zpool driver for writeback in zswap-shrink work, data for A is mapped by zpool driver 3. user space program faults and invalidates page entry A, offset X is considered free 4. kswapd stores page B at offset X in zswap (zswap could also be full, if so, page B would then be IOed to X, then skip step 5.) 5. entry A is replaced by B in tree->rbroot, this doesn't affect the local reference held by zswap-shrink work 6. zswap-shrink work writes back A at X, and frees zswap entry A 7. swapin of slot X brings A in memory instead of B The fix: Once the swap page cache has been allocated (case ZSWAP_SWAPCACHE_NEW), zswap-shrink work just checks that the local zswap_entry reference is still the same as the one in the tree. If it's not the same it means that it's either been invalidated or replaced, in both cases the writeback is aborted because the local entry contains stale data. Reproducer: I originally found this by running `stress` overnight to validate my work on the zswap writeback mechanism, it manifested after hours on my test machine. The key to make it happen is having zswap writebacks, so whatever setup pumps /sys/kernel/debug/zswap/written_back_pages should do the trick. In order to reproduce this faster on a vm, I setup a system with ~100M of available memory and a 500M swap file, then running `stress --vm 1 --vm-bytes 300000000 --vm-stride 4000` makes it happen in matter of tens of minutes. One can speed things up even more by swinging /sys/module/zswap/parameters/max_pool_percent up and down between, say, 20 and 1; this makes it reproduce in tens of seconds. It's crucial to set `--vm-stride` to something other than 4096 otherwise `stress` won't realize that memory has been corrupted because all pages would have the same data.
A flaw was found in ACPICA in the Linux kernel. This vulnerability allows for a denial of service via a null pointer dereference.
In the Linux kernel, the following vulnerability has been resolved: media: az6007: Fix null-ptr-deref in az6007_i2c_xfer() In az6007_i2c_xfer, msg is controlled by user. When msg[i].buf is null and msg[i].len is zero, former checks on msg[i].buf would be passed. Malicious data finally reach az6007_i2c_xfer. If accessing msg[i].buf[0] without sanity check, null ptr deref would happen. We add check on msg[i].len to prevent crash. Similar commit: commit 0ed554fd769a ("media: dvb-usb: az6027: fix null-ptr-deref in az6027_i2c_xfer()")
A flaw was found in the Linux kernel's Server Message Block (SMB) client. A local attacker with low privileges could exploit a memory leak in the `cifs_smb3_do_mount()` function. This could lead to a Denial of Service (DoS) due to resource exhaustion.
CWE-772 - Missing Release of Resource after Effective LifetimeIn the Linux kernel, the following vulnerability has been resolved: clk: imx: clk-imx8mn: fix memory leak in imx8mn_clocks_probe Use devm_of_iomap() instead of of_iomap() to automatically handle the unused ioremap region. If any error occurs, regions allocated by kzalloc() will leak, but using devm_kzalloc() instead will automatically free the memory using devm_kfree().
In the Linux kernel, the following vulnerability has been resolved: clk: imx: clk-imxrt1050: fix memory leak in imxrt1050_clocks_probe Use devm_of_iomap() instead of of_iomap() to automatically handle the unused ioremap region. If any error occurs, regions allocated by kzalloc() will leak, but using devm_kzalloc() instead will automatically free the memory using devm_kfree(). Also, fix error handling of hws by adding unregister_hws label, which unregisters remaining hws when iomap failed.
A flaw was found in the Linux kernel. A local attacker can exploit this vulnerability by loading and then unloading the `rcuscale` module while a specific test case is active. This improper handling of thread termination can lead to a use-after-free condition, causing a kernel crash and resulting in a Denial of Service (DoS).
A flaw was found in the Linux kernel's shared memory (shmem) component, specifically within its ramfs-based temporary file system (tmpfs) implementation. A local user could exploit this vulnerability due to improper memory deallocation. This oversight can lead to a memory leak, potentially causing a Denial of Service (DoS) by exhausting system resources.
In the Linux kernel, the following vulnerability has been resolved: ACPICA: Add AML_NO_OPERAND_RESOLVE flag to Timer ACPICA commit 90310989a0790032f5a0140741ff09b545af4bc5 According to the ACPI specification 19.6.134, no argument is required to be passed for ASL Timer instruction. For taking care of no argument, AML_NO_OPERAND_RESOLVE flag is added to ASL Timer instruction opcode. When ASL timer instruction interpreted by ACPI interpreter, getting error. After adding AML_NO_OPERAND_RESOLVE flag to ASL Timer instruction opcode, issue is not observed. ============================================================= UBSAN: array-index-out-of-bounds in acpica/dswexec.c:401:12 index -1 is out of range for type 'union acpi_operand_object *[9]' CPU: 37 PID: 1678 Comm: cat Not tainted 6.0.0-dev-th500-6.0.y-1+bcf8c46459e407-generic-64k HW name: NVIDIA BIOS v1.1.1-d7acbfc-dirty 12/19/2022 Call trace: dump_backtrace+0xe0/0x130 show_stack+0x20/0x60 dump_stack_lvl+0x68/0x84 dump_stack+0x18/0x34 ubsan_epilogue+0x10/0x50 __ubsan_handle_out_of_bounds+0x80/0x90 acpi_ds_exec_end_op+0x1bc/0x6d8 acpi_ps_parse_loop+0x57c/0x618 acpi_ps_parse_aml+0x1e0/0x4b4 acpi_ps_execute_method+0x24c/0x2b8 acpi_ns_evaluate+0x3a8/0x4bc acpi_evaluate_object+0x15c/0x37c acpi_evaluate_integer+0x54/0x15c show_power+0x8c/0x12c [acpi_power_meter]
A flaw was exist's in the Linux kernel’s module-post processing component, in the function is_executable_section(). Due to an off-by-one error (using > instead of >=), the code may perform an out-of-bounds array access.
A null pointer dereference exists in the linux kernel such that in obj_stock_flush_required():stock->cached_objcg can be reset between the check and dereference, resulting in damage to the availability of the system.
In the Linux kernel, the following vulnerability has been resolved: kernel/printk/index.c: fix memory leak with using debugfs_lookup() When calling debugfs_lookup() the result must have dput() called on it, otherwise the memory will leak over time. To make things simpler, just call debugfs_lookup_and_remove() instead which handles all of the logic at once.
In the Linux kernel, the following vulnerability has been resolved: ionic: catch failure from devlink_alloc Add a check for NULL on the alloc return. If devlink_alloc() fails and we try to use devlink_priv() on the NULL return, the kernel gets very unhappy and panics. With this fix, the driver load will still fail, but at least it won't panic the kernel.
In the Linux kernel, the following vulnerability has been resolved: ACPI: processor: Check for null return of devm_kzalloc() in fch_misc_setup() devm_kzalloc() may fail, clk_data->name might be NULL and will cause a NULL pointer dereference later. [ rjw: Subject and changelog edits ]
In the Linux kernel, the following vulnerability has been resolved: ext4: allow ext4_get_group_info() to fail Previously, ext4_get_group_info() would treat an invalid group number as BUG(), since in theory it should never happen. However, if a malicious attaker (or fuzzer) modifies the superblock via the block device while it is the file system is mounted, it is possible for s_first_data_block to get set to a very large number. In that case, when calculating the block group of some block number (such as the starting block of a preallocation region), could result in an underflow and very large block group number. Then the BUG_ON check in ext4_get_group_info() would fire, resutling in a denial of service attack that can be triggered by root or someone with write access to the block device. For a quality of implementation perspective, it's best that even if the system administrator does something that they shouldn't, that it will not trigger a BUG. So instead of BUG'ing, ext4_get_group_info() will call ext4_error and return NULL. We also add fallback code in all of the callers of ext4_get_group_info() that it might NULL. Also, since ext4_get_group_info() was already borderline to be an inline function, un-inline it. The results in a next reduction of the compiled text size of ext4 by roughly 2k.
In the Linux kernel, the following vulnerability has been resolved: clk: tegra: tegra124-emc: Fix potential memory leak The tegra and tegra needs to be freed in the error handling path, otherwise it will be leaked.
In the Linux kernel, the following vulnerability has been resolved: null_blk: fix poll request timeout handling When doing io_uring benchmark on /dev/nullb0, it's easy to crash the kernel if poll requests timeout triggered, as reported by David. [1] BUG: kernel NULL pointer dereference, address: 0000000000000008 Workqueue: kblockd blk_mq_timeout_work RIP: 0010:null_timeout_rq+0x4e/0x91 Call Trace: ? null_timeout_rq+0x4e/0x91 blk_mq_handle_expired+0x31/0x4b bt_iter+0x68/0x84 ? bt_tags_iter+0x81/0x81 __sbitmap_for_each_set.constprop.0+0xb0/0xf2 ? __blk_mq_complete_request_remote+0xf/0xf bt_for_each+0x46/0x64 ? __blk_mq_complete_request_remote+0xf/0xf ? percpu_ref_get_many+0xc/0x2a blk_mq_queue_tag_busy_iter+0x14d/0x18e blk_mq_timeout_work+0x95/0x127 process_one_work+0x185/0x263 worker_thread+0x1b5/0x227 This is indeed a race problem between null_timeout_rq() and null_poll(). null_poll() null_timeout_rq() spin_lock(&nq->poll_lock) list_splice_init(&nq->poll_list, &list) spin_unlock(&nq->poll_lock) while (!list_empty(&list)) req = list_first_entry() list_del_init() ... blk_mq_add_to_batch() // req->rq_next = NULL spin_lock(&nq->poll_lock) // rq->queuelist->next == NULL list_del_init(&rq->queuelist) spin_unlock(&nq->poll_lock) Fix these problems by setting requests state to MQ_RQ_COMPLETE under nq->poll_lock protection, in which null_timeout_rq() can safely detect this race and early return. Note this patch just fix the kernel panic when request timeout happen. [1] https://lore.kernel.org/all/3893581.1691785261@warthog.procyon.org.uk/
A locking violation was found in the Linux kernel RCU-tasks subsystem's callback list initialization. During system boot, the initialization code calls pr_info() while holding the rtp->cbs_gbl_lock spinlock, causing a potentially sleeping function to be called in atomic context, which results in kernel lockdep warnings and potential deadlock leading to denial of service.
A use-after-free flaw was found in the Linux kernel's i.MX system control unit clock driver in the error cleanup path. A local user can trigger this issue during clock initialization failure scenarios on i.MX hardware with System Control Unit firmware, where the cleanup loop incorrectly uses a standard list iterator instead of the safe variant while freeing clock structures. This causes the kernel to dereference freed memory when traversing to the next list element, resulting in memory corruption that can lead to a crash or denial of service.
A resource management issue was found in the Linux kernel's driver core regarding device-managed (devm) resource cleanup. When devices without buses or drivers are unregistered, their managed resources aren't properly freed because devres_release_all is only called for devices that have been probed. This causes resource leaks—particularly problematic when managed resources hold references to the device itself—preventing device objects from ever being freed and leading to denial of service through resource exhaustion.
In the Linux kernel, the following vulnerability has been resolved: cifs: fix mid leak during reconnection after timeout threshold When the number of responses with status of STATUS_IO_TIMEOUT exceeds a specified threshold (NUM_STATUS_IO_TIMEOUT), we reconnect the connection. But we do not return the mid, or the credits returned for the mid, or reduce the number of in-flight requests. This bug could result in the server->in_flight count to go bad, and also cause a leak in the mids. This change moves the check to a few lines below where the response is decrypted, even of the response is read from the transform header. This way, the code for returning the mids can be reused. Also, the cifs_reconnect was reconnecting just the transport connection before. In case of multi-channel, this may not be what we want to do after several timeouts. Changed that to reconnect the session and the tree too. Also renamed NUM_STATUS_IO_TIMEOUT to a more appropriate name MAX_STATUS_IO_TIMEOUT.
A use-after-free vulnerability was found in the Linux kernel's device-dax subsystem during mapping object cleanup. When removing a dax region provider, the child dax_mapping objects attempt to free their ID allocator after the parent dev_dax object has already been released. This causes ida_free to operate on freed memory, triggering lockdep warnings and potentially causing crashes or memory corruption, leading to denial of service.
A memory leak flaw was found in the Linux kernel's ext4 filesystem in the filename casefolding error paths. A local user can trigger this issue by performing directory operations on ext4 filesystems with casefolding enabled when filename setup or lookup operations fail, causing the crypto_buf.name field from the fscrypt_name structure to remain allocated. This results in permanent memory leaks leading to resource exhaustion and denial of service.
A resource-management flaw was found in the Linux kernel Common Clock Framework. The device-managed clock notifier registration function failed to register its allocated resource, preventing cleanup on device detach. A local user repeatedly binding and unbinding devices could cause memory leaks and eventual denial of service.
In the Linux kernel, the following vulnerability has been resolved: tty: serial: samsung_tty: Fix a memory leak in s3c24xx_serial_getclk() when iterating clk When the best clk is searched, we iterate over all possible clk. If we find a better match, the previous one, if any, needs to be freed. If a better match has already been found, we still need to free the new one, otherwise it leaks.
In the Linux kernel, the following vulnerability has been resolved: nvdimm: Fix memleak of pmu attr_groups in unregister_nvdimm_pmu() Memory pointed by 'nd_pmu->pmu.attr_groups' is allocated in function 'register_nvdimm_pmu' and is lost after 'kfree(nd_pmu)' call in function 'unregister_nvdimm_pmu'.
In the Linux kernel, the following vulnerability has been resolved: s390/crypto: use vector instructions only if available for ChaCha20 Commit 349d03ffd5f6 ("crypto: s390 - add crypto library interface for ChaCha20") added a library interface to the s390 specific ChaCha20 implementation. However no check was added to verify if the required facilities are installed before branching into the assembler code. If compiled into the kernel, this will lead to the following crash, if vector instructions are not available: data exception: 0007 ilc:3 [#1] SMP Modules linked in: CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.3.0-rc7+ #11 Hardware name: IBM 3931 A01 704 (KVM/Linux) Krnl PSW : 0704e00180000000 000000001857277a (chacha20_vx+0x32/0x818) R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:2 PM:0 RI:0 EA:3 Krnl GPRS: 0000037f0000000a ffffffffffffff60 000000008184b000 0000000019f5c8e6 0000000000000109 0000037fffb13c58 0000037fffb13c78 0000000019bb1780 0000037fffb13c58 0000000019f5c8e6 000000008184b000 0000000000000109 00000000802d8000 0000000000000109 0000000018571ebc 0000037fffb13718 Krnl Code: 000000001857276a: c07000b1f80b larl %r7,0000000019bb1780 0000000018572770: a708000a lhi %r0,10 #0000000018572774: e78950000c36 vlm %v24,%v25,0(%r5),0 >000000001857277a: e7a060000806 vl %v26,0(%r6),0 0000000018572780: e7bf70004c36 vlm %v27,%v31,0(%r7),4 0000000018572786: e70b00000456 vlr %v0,%v27 000000001857278c: e71800000456 vlr %v1,%v24 0000000018572792: e74b00000456 vlr %v4,%v27 Call Trace: [<000000001857277a>] chacha20_vx+0x32/0x818 Last Breaking-Event-Address: [<0000000018571eb6>] chacha20_crypt_s390.constprop.0+0x6e/0xd8 ---[ end trace 0000000000000000 ]--- Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b Fix this by adding a missing MACHINE_HAS_VX check. [agordeev@linux.ibm.com: remove duplicates in commit message]
In the Linux kernel, the following vulnerability has been resolved: clk: imx: clk-imx8mp: improve error handling in imx8mp_clocks_probe() Replace of_iomap() and kzalloc() with devm_of_iomap() and devm_kzalloc() which can automatically release the related memory when the device or driver is removed or unloaded to avoid potential memory leak. In this case, iounmap(anatop_base) in line 427,433 are removed as manual release is not required. Besides, referring to clk-imx8mq.c, check the return code of of_clk_add_hw_provider, if it returns negtive, print error info and unregister hws, which makes the program more robust.
A memory leak was found in the Linux kernel's ACPI x86 suspend-to-idle implementation in the AMD Low Power S0 (LPS0) DSM evaluation code. A system with malformed ACPI firmware that returns multiple ACPI_TYPE_PACKAGE objects during _DSM evaluation can trigger repeated memory allocations that are never freed. This leads to gradual memory exhaustion and potential denial of service.
A flaw was found in the Linux kernel, specifically within the arc_uart serial driver. This vulnerability involves a resource leak where memory allocated for hardware interaction is not properly released under certain error conditions. A local attacker with low privileges could exploit this to exhaust system resources, potentially leading to a Denial of Service (DoS).
A flaw was found in the Linux kernel. A local attacker with low privileges could exploit a timing issue, specifically a potential deadlock in the Netlink communication subsystem. This could cause the system to become unresponsive, leading to a Denial of Service (DoS).
The TI AM33xx power management driver in the Linux kernel fails to release reference counts acquired via wkup_m3_ipc_get() when errors occur during probe. Since the corresponding wkup_m3_ipc_put() call is missing from error paths, repeated probe failures gradually exhaust kernel resources.
A flaw was found in the Linux kernel. A local user can exploit a use-after-free (UAF) vulnerability in the `vc_screen` component. This occurs because a pointer to the `vc_data` structure is not reloaded after a console unlock operation, leading to the use of freed memory. Successful exploitation of this flaw can result in a denial of service, making the system unavailable.
A flaw was found in the Linux kernel's networking subsystem. A local attacker can exploit an integer overflow vulnerability in the `kmalloc_reserve()` function by manipulating network interface settings. This can cause the kernel to attempt a memory allocation with an incorrect size, leading to memory corruption and ultimately a system crash, resulting in a Denial of Service (DoS).
An off-by-one style bug exists in regmap_add_irq_chip_fwnode() where the allocation loop uses num_config_regs instead of num_config_bases as its termination condition. When num_config_regs exceeds num_config_bases, memory beyond the allocated row pointer array gets overwritten. KASAN caught this corruption manifesting as crashes on Qualcomm db845c hardware.
A memory leak vulnerability was found in the Samsung serial TTY driver in the Linux kernel. In s3c24xx_serial_getclk(), when clk_get_rate() fails, the previously allocated clock resource is not freed, leading to a memory leak. Repeated failures can cause resource exhaustion.
A NULL pointer dereference vulnerability was found in the ext4 filesystem in the Linux kernel. In ext4_mb_good_group(), the group corruption check accesses the grp structure memory before verifying that grp is not NULL. If grp is NULL, this leads to a kernel crash. The fix adds a NULL check before performing the corruption check.
A flaw was found in the Linux kernel's thermal subsystem. A double-free vulnerability occurs during thermal zone device unregistration when using device tree (OF) bindings. The thermal_of_zone_register() function leaks the original tzp structure and double-frees the internal copy, which can lead to memory corruption or a kernel crash.
A flaw was found in the Linux kernel's Advanced Configuration and Power Interface (ACPI) component. This vulnerability occurs when a memory allocation function fails, leading to a null pointer dereference. A local attacker with low privileges could exploit this to cause the system to crash, resulting in a Denial of Service (DoS).
A use-after-free vulnerability was found in the Linux kernel's PSI (Pressure Stall Information) trigger handling for cgroups. When a cgroup is removed while a process is polling its PSI trigger file, the trigger's waitqueue is destroyed via psi_trigger_destroy() while the polling process still holds a reference. The subsequent poll_freewait() accesses the freed waitqueue head, causing a use-after-free crash.
A flaw was found in the Linux kernel's dvb-usb-v2 gl861 module. A local user could exploit this null-pointer dereference vulnerability by providing specially crafted input to the gl861_i2c_master_xfer function. This could lead to a system crash, resulting in a Denial of Service (DoS).
In the Linux kernel, the following vulnerability has been resolved: phy: tegra: xusb: Clear the driver reference in usb-phy dev For the dual-role port, it will assign the phy dev to usb-phy dev and use the port dev driver as the dev driver of usb-phy. When we try to destroy the port dev, it will destroy its dev driver as well. But we did not remove the reference from usb-phy dev. This might cause the use-after-free issue in KASAN.
CWE-825 - Expired Pointer DereferenceA flaw was found in the Linux kernel's anysee media driver. A local user can provide specially crafted input to the anysee_master_xfer function, leading to a null pointer dereference. This can cause a system crash, resulting in a Denial of Service (DoS).
A slab-out-of-bounds read vulnerability was found in the Linux kernel's PowerPC IOMMU code. The fail_iommu_setup() function registers the same notifier_block structure to both PCI and VIO buses. Since notifier_block is a linked list node, this causes notifiers registered to one bus type to also apply to the other. The VGA arbiter code then incorrectly processes VIO devices as PCI devices, causing an out-of-bounds memory access.
A flaw was found in the Read-Copy-Update (RCU) core of the Linux kernel related to how memory information for vmalloc-allocated objects is dumped. Under certain sequences, calling call_rcu() may lead to the invocation of vmalloc_dump_obj() while holding the vmap_area_lock spinlock in an interrupt context. Because the spinlock cannot be held safely in that context, this could result in a deadlock or kernel hang, particularly under Real-Time (Preempt-RT) workloads where RCU torture testing surfaced lock dependency warnings.
A flaw was found in the Linux kernel, specifically within its Network Service Header (NSH) module. A local attacker could exploit this vulnerability by sending specially crafted network packets, which would cause the system to crash. This issue, a type of Denial of Service (DoS), arises from an incorrect calculation during network packet processing, leading to a critical error in memory management.
In the Linux kernel, the following vulnerability has been resolved: serial: sc16is7xx: setup GPIO controller later in probe The GPIO controller component of the sc16is7xx driver is setup too early, which can result in a race condition where another device tries to utilise the GPIO lines before the sc16is7xx device has finished initialising. This issue manifests itself as an Oops when the GPIO lines are configured: Unable to handle kernel read from unreadable memory at virtual address ... pc : sc16is7xx_gpio_direction_output+0x68/0x108 [sc16is7xx] lr : sc16is7xx_gpio_direction_output+0x4c/0x108 [sc16is7xx] ... Call trace: sc16is7xx_gpio_direction_output+0x68/0x108 [sc16is7xx] gpiod_direction_output_raw_commit+0x64/0x318 gpiod_direction_output+0xb0/0x170 create_gpio_led+0xec/0x198 gpio_led_probe+0x16c/0x4f0 platform_drv_probe+0x5c/0xb0 really_probe+0xe8/0x448 driver_probe_device+0xe8/0x138 __device_attach_driver+0x94/0x118 bus_for_each_drv+0x8c/0xe0 __device_attach+0x100/0x1b8 device_initial_probe+0x28/0x38 bus_probe_device+0xa4/0xb0 deferred_probe_work_func+0x90/0xe0 process_one_work+0x1c4/0x480 worker_thread+0x54/0x430 kthread+0x138/0x150 ret_from_fork+0x10/0x1c This patch moves the setup of the GPIO controller functions to later in the probe function, ensuring the sc16is7xx device has already finished initialising by the time other devices try to make use of the GPIO lines. The error handling has also been reordered to reflect the new initialisation order.
A flaw was found in the serial: sprd driver in the Linux kernel where a DMA buffer allocated during driver probe was not released when _probe() returned failure. This results in a memory leak that, under repeated probe failure conditions, could cause elevated kernel memory usage and potential resource exhaustion
In the Linux kernel, the following vulnerability has been resolved: x86/kexec: Fix double-free of elf header buffer After b3e34a47f989 ("x86/kexec: fix memory leak of elf header buffer"), freeing image->elf_headers in the error path of crash_load_segments() is not needed because kimage_file_post_load_cleanup() will take care of that later. And not clearing it could result in a double-free. Drop the superfluous vfree() call at the error path of crash_load_segments().
In the Linux kernel, the following vulnerability has been resolved: ext4: turn quotas off if mount failed after enabling quotas Yi found during a review of the patch "ext4: don't BUG on inconsistent journal feature" that when ext4_mark_recovery_complete() returns an error value, the error handling path does not turn off the enabled quotas, which triggers the following kmemleak: ================================================================ unreferenced object 0xffff8cf68678e7c0 (size 64): comm "mount", pid 746, jiffies 4294871231 (age 11.540s) hex dump (first 32 bytes): 00 90 ef 82 f6 8c ff ff 00 00 00 00 41 01 00 00 ............A... c7 00 00 00 bd 00 00 00 0a 00 00 00 48 00 00 00 ............H... backtrace: [<00000000c561ef24>] __kmem_cache_alloc_node+0x4d4/0x880 [<00000000d4e621d7>] kmalloc_trace+0x39/0x140 [<00000000837eee74>] v2_read_file_info+0x18a/0x3a0 [<0000000088f6c877>] dquot_load_quota_sb+0x2ed/0x770 [<00000000340a4782>] dquot_load_quota_inode+0xc6/0x1c0 [<0000000089a18bd5>] ext4_enable_quotas+0x17e/0x3a0 [ext4] [<000000003a0268fa>] __ext4_fill_super+0x3448/0x3910 [ext4] [<00000000b0f2a8a8>] ext4_fill_super+0x13d/0x340 [ext4] [<000000004a9489c4>] get_tree_bdev+0x1dc/0x370 [<000000006e723bf1>] ext4_get_tree+0x1d/0x30 [ext4] [<00000000c7cb663d>] vfs_get_tree+0x31/0x160 [<00000000320e1bed>] do_new_mount+0x1d5/0x480 [<00000000c074654c>] path_mount+0x22e/0xbe0 [<0000000003e97a8e>] do_mount+0x95/0xc0 [<000000002f3d3736>] __x64_sys_mount+0xc4/0x160 [<0000000027d2140c>] do_syscall_64+0x3f/0x90 ================================================================ To solve this problem, we add a "failed_mount10" tag, and call ext4_quota_off_umount() in this tag to release the enabled qoutas.
CWE-772 - Missing Release of Resource after Effective LifetimeA flaw was found in the Linux kernel zsmalloc memory allocator. Under certain memory pressure and reclaim conditions, zsmalloc updated its LRU lists in an unsafe context, which could lead to list corruption due to a race between object mapping and allocation paths. A local user able to trigger specific memory allocation patterns could cause a kernel crash or denial of service.
A compatibility issue was found between Linux and Hyper-V when Indirect Branch Tracking (IBT) is enabled. The Hyper-V hypercall page lacks the required ENDBR64 instruction, causing all hypercalls to fail with an exception and panic the guest.
CWE-166 - Improper Handling of Missing Special ElementA memory allocation failure was found in the exFAT filesystem driver. When system memory is fragmented, kmalloc_array() can fail to allocate contiguous memory for the bitmap, preventing USB drives from being mounted.
CWE-770 - Allocation of Resources Without Limits or ThrottlingAn out-of-bounds access was found in the TTY subsystem. When an invalid console device is specified on the kernel command line (e.g., console=tty3270), the driver lookup returns a TTY struct with an invalid index, causing a crash during boot.
CWE-1285 - Improper Validation of Specified Index, Position, or Offset in InputA memory leak flaw was found in the Linux kernel's block multi-queue (blk-mq) subsystem. When the number of hardware queues is reduced via the submit_queues parameter, the tags associated with the removed queues are not freed, causing a memory leak. This occurs because shrinking nr_hw_queues does not deallocate the tags for queues that are no longer needed.
CWE-772 - Missing Release of Resource after Effective LifetimeA flaw was found in the Linux kernel's ACPI Embedded Controller (EC) subsystem. When removing custom query handlers, a kernel oops can occur if the handler is still being executed in the EC query workqueue while the module containing the callback function is being unloaded. The fix ensures the workqueue is flushed before handler removal.
A hung task warning issue was found in the RCU scaling test module. When the holdoff parameter exceeds hung_task_timeout_secs, the kernel logs a hung task warning for the rcu_scale_writer kthread.
CWE-628 - Function Call with Incorrectly Specified ArgumentsA debug warning issue was found in PowerPC pseries code. When DEBUG_PREEMPT is enabled, accessing lppaca_shared_proc() triggers spurious preemption warnings because it uses smp_processor_id() in preemptible context.
CWE-663 - Use of a Non-reentrant Function in a Concurrent ContextA locking issue was found in the Linux kernel's debugobjects subsystem. The fill_pool() function uses GFP_ATOMIC allocation flags, which attempt to wake up kswapd and acquire kswapd_wait::lock. Since fill_pool() may be called with arbitrary locks already held, this can trigger lockdep warnings about potential deadlocks.
CWE-833 - DeadlockA flaw was found in the Linux kernel's block cgroup (blk-cgroup) component. A local attacker could exploit a race condition in the `blkcg_activate_policy()` function, where block group policy data (`blkg_policy_data`) is installed before it is fully initialized. This allows another function, `ioc_weight_write()`, to access uninitialized data, leading to a NULL pointer dereference and causing a system crash, resulting in a Denial of Service (DoS).
A NULL pointer dereference vulnerability was found in the Linux kernel's VDUSE (vDPA Device in Userspace) subsystem. The vduse_vdpa_set_vq_affinity() callback can be invoked with a NULL cpu_mask value when deleting a vduse device. The code attempts to copy from this NULL pointer, causing a kernel crash during device removal.
An error pointer dereference was found in the Intel Quark thermal driver. When alloc_soc_dts() fails and returns an error pointer, attempting to free it causes a kernel crash.
CWE-763 - Release of Invalid Pointer or ReferenceA NULL pointer dereference flaw was found in the Linux kernel's USB Type-C subsystem. When certain USB hubs perform a data role swap after entering DisplayPort Alt Mode, all alternate modes are unregistered. If the hub continues sending Attention messages afterward, the typec_altmode_attention() function dereferences a NULL partner pointer, causing a kernel crash.
A resource leak flaw was found in the Broadcom BCM7271 serial driver. In the brcmuart_probe() function, the baud_mux_clk clock is prepared and enabled but not released in error paths, causing a clock resource leak when driver probe fails.
CWE-772 - Missing Release of Resource after Effective LifetimeA race condition was found in the CXL persistent memory driver. Rapid module load/unload cycles can cause async nvdimm device registration to run after the CXL context has been torn down, resulting in a NULL pointer dereference.
A vulnerability was found in vhost_new_msg in drivers/vhost/vhost.c in the Linux kernel, which does not properly initialize memory in messages passed between virtual guests and the host operating system in the vhost/vhost.c:vhost_new_msg() function. This issue can allow local privileged users to read some kernel memory contents when reading from the /dev/vhost-net device file.
A vulnerability was reported in the Open vSwitch sub-component in the Linux Kernel. The flaw occurs when a recursive operation of code push recursively calls into the code block. The OVS module does not validate the stack depth, pushing too many frames and causing a stack overflow. As a result, this can lead to a crash or other related issues.
A NULL pointer dereference vulnerability was found in the Linux kernel in rfcomm_check_security. This issue may lead to buffer overflows.
Integer Overflow or Wraparound vulnerability in Linux Linux kernel kernel on Linux, x86, ARM (md, raid, raid5 modules) allows Forced Integer Overflow.
A vulnerability was found in the Linux kernel. A use-after-free exists in cec_queue_msg_fh, related to drivers/media/cec/core/cec-adap.c and drivers/media/cec/core/cec-api.c.
A race condition was found in the Linux kernel's net/bluetooth device driver within the conn_info_{min,max}_age_set() function. This issue can lead to an integrity overflow issue, potentially disrupting Bluetooth connections or facilitating a denial of service attack.
A race condition flaw was found in the Linux kernel's net/bluetooth, specifically in the {conn,adv}_{min,max}_interval_set() function, which may disrupt I2cap connections, possibly causing a denial of service. This flaw allows an attacker to disrupt Bluetooth connections, leading to a potential denial of service.
A race condition vulnerability was found in the Linux kernel's net/bluetooth in sniff_{min,max}_interval_set() function. This issue can result in a Bluetooth sniffing exception issue, possibly leading to denial of service.
A flaw was found in the Linux kernel. The create_empty_lvol function in the drivers/mtd/ubi/vtbl.c file can attempt to allocate zero bytes of memory when the LEB size is smaller than a single volume table record. This issue can result in a denial of service.
A vulnerability has been identified in the Linux kernel's Berkeley Packet Filter (BPF) subsystem. The flaw resides within the handling of PTR_TO_FLOW_KEYS (pointer to flow keys) in the check_flow_keys_access() function. Specifically, while fixed offsets are validated for PTR_TO_FLOW_KEYS, the system currently fails to prohibit variable offset pointer arithmetic for this pointer type. This oversight allows a malicious or specially crafted BPF program to perform an unchecked variable offset addition to the flow keys pointer. This results in an out-of-bounds memory access, which can lead to a kernel crash. This issue directly impacts system availability by causing a denial of service.
bpf: Fix re-attachment branch in bpf_tracing_prog_attach The following case can cause a crash due to missing attach_btf: 1) load rawtp program 2) load fentry program with rawtp as target_fd 3) create tracing link for fentry program with target_fd = 0 4) repeat 3 In the end we have: - prog->aux->dst_trampoline == NULL - tgt_prog == NULL (because we did not provide target_fd to link_create) - prog->aux->attach_btf == NULL (the program was loaded with attach_prog_fd=X) - the program was loaded for tgt_prog but we have no way to find out which one BUG: kernel NULL pointer dereference, address: 0000000000000058 Call Trace: ? __die+0x20/0x70 ? page_fault_oops+0x15b/0x430 ? fixup_exception+0x22/0x330 ? exc_page_fault+0x6f/0x170 ? asm_exc_page_fault+0x22/0x30 ? bpf_tracing_prog_attach+0x279/0x560 ? btf_obj_id+0x5/0x10 bpf_tracing_prog_attach+0x439/0x560 __sys_bpf+0x1cf4/0x2de0 __x64_sys_bpf+0x1c/0x30 do_syscall_64+0x41/0xf0 entry_SYSCALL_64_after_hwframe+0x6e/0x76 Return -EINVAL in this situation.
A flaw was found in the Linux kernel's ext4 filesystem related to the fast commit replay process. During this process, blocks that are already marked as free can be incorrectly marked as free again, leading to the corruption of the buddy bitmap, which is used to track free and allocated blocks. This corruption can result in filesystem inconsistencies and potential data loss. The issue is resolved by reintroducing the mb_regenerate_buddy() function, which regenerates the buddy bitmap to ensure its integrity.
A flaw was found in the Linux kernel's x86/fpu module, which revolves around an issue with relying on user space for critical information regarding the xsave buffer. In the affected scenario, the expected size of the user space buffer is derived from user-controlled data, specifically, fx_sw->xstate_size. By manipulating this value, an attacker could construct a malicious sigreturn frame where the indicated size is smaller than required by valid bits in fx_sw->xfeatures. Furthermore, the attacker could unmap portions of the fpu buffer in the user space, rendering them inaccessible to xrstor. This manipulation leads to a situation where xrstor repeatedly attempts to restore and access an unmapped area, causing a fault. However, the fault_in_readable function erroneously succeeds because the accessed region, buf + fx_sw->xstate_size, remains within the mapped area. Consequently, the system enters a perpetual loop as xrstor continually retries the operation.
A flaw was found in the Linux kernel, where a deadlock scenario was triggered when enabling Active State Power Management (ASPM) during the probe of Qualcomm PCIe controllers. This deadlock was identified by lockdep and stemmed from a recursive locking scenario. This issue occurred when a task attempted to acquire a lock already held by another task, leading to a deadlock situation. The deadlock could be reproduced on certain machines, such as the Lenovo ThinkPad X13s, by intentionally delaying operations to increase the race window during asynchronous probes, allowing another thread to take a write lock.
In the Linux kernel, the following vulnerability has been resolved: xsk: fix usage of multi-buffer BPF helpers for ZC XDP Currently when packet is shrunk via bpf_xdp_adjust_tail() and memory type is set to MEM_TYPE_XSK_BUFF_POOL, null ptr dereference happens: [1136314.192256] BUG: kernel NULL pointer dereference, address: 0000000000000034 [1136314.203943] #PF: supervisor read access in kernel mode [1136314.213768] #PF: error_code(0x0000) - not-present page [1136314.223550] PGD 0 P4D 0 [1136314.230684] Oops: 0000 [#1] PREEMPT SMP NOPTI [1136314.239621] CPU: 8 PID: 54203 Comm: xdpsock Not tainted 6.6.0+ #257 [1136314.250469] Hardware name: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0008.031920191559 03/19/2019 [1136314.265615] RIP: 0010:__xdp_return+0x6c/0x210 [1136314.274653] Code: ad 00 48 8b 47 08 49 89 f8 a8 01 0f 85 9b 01 00 00 0f 1f 44 00 00 f0 41 ff 48 34 75 32 4c 89 c7 e9 79 cd 80 ff 83 fe 03 75 17 <f6> 41 34 01 0f 85 02 01 00 00 48 89 cf e9 22 cc 1e 00 e9 3d d2 86 [1136314.302907] RSP: 0018:ffffc900089f8db0 EFLAGS: 00010246 [1136314.312967] RAX: ffffc9003168aed0 RBX: ffff8881c3300000 RCX: 0000000000000000 [1136314.324953] RDX: 0000000000000000 RSI: 0000000000000003 RDI: ffffc9003168c000 [1136314.336929] RBP: 0000000000000ae0 R08: 0000000000000002 R09: 0000000000010000 [1136314.348844] R10: ffffc9000e495000 R11: 0000000000000040 R12: 0000000000000001 [1136314.360706] R13: 0000000000000524 R14: ffffc9003168aec0 R15: 0000000000000001 [1136314.373298] FS: 00007f8df8bbcb80(0000) GS:ffff8897e0e00000(0000) knlGS:0000000000000000 [1136314.386105] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [1136314.396532] CR2: 0000000000000034 CR3: 00000001aa912002 CR4: 00000000007706f0 [1136314.408377] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [1136314.420173] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [1136314.431890] PKRU: 55555554 [1136314.439143] Call Trace: [1136314.446058] <IRQ> [1136314.452465] ? __die+0x20/0x70 [1136314.459881] ? page_fault_oops+0x15b/0x440 [1136314.468305] ? exc_page_fault+0x6a/0x150 [1136314.476491] ? asm_exc_page_fault+0x22/0x30 [1136314.484927] ? __xdp_return+0x6c/0x210 [1136314.492863] bpf_xdp_adjust_tail+0x155/0x1d0 [1136314.501269] bpf_prog_ccc47ae29d3b6570_xdp_sock_prog+0x15/0x60 [1136314.511263] ice_clean_rx_irq_zc+0x206/0xc60 [ice] [1136314.520222] ? ice_xmit_zc+0x6e/0x150 [ice] [1136314.528506] ice_napi_poll+0x467/0x670 [ice] [1136314.536858] ? ttwu_do_activate.constprop.0+0x8f/0x1a0 [1136314.546010] __napi_poll+0x29/0x1b0 [1136314.553462] net_rx_action+0x133/0x270 [1136314.561619] __do_softirq+0xbe/0x28e [1136314.569303] do_softirq+0x3f/0x60 This comes from __xdp_return() call with xdp_buff argument passed as NULL which is supposed to be consumed by xsk_buff_free() call. To address this properly, in ZC case, a node that represents the frag being removed has to be pulled out of xskb_list. Introduce appropriate xsk helpers to do such node operation and use them accordingly within bpf_xdp_adjust_tail().
CWE-476 - NULL Pointer DereferenceIn the Linux kernel, the following vulnerability has been resolved: netfs, fscache: Prevent Oops in fscache_put_cache() This function dereferences "cache" and then checks if it's IS_ERR_OR_NULL(). Check first, then dereference.
CWE-20 - Improper Input ValidationIn the Linux kernel, the following vulnerability has been resolved: tcp: make sure init the accept_queue's spinlocks once When I run syz's reproduction C program locally, it causes the following issue: pvqspinlock: lock 0xffff9d181cd5c660 has corrupted value 0x0! WARNING: CPU: 19 PID: 21160 at __pv_queued_spin_unlock_slowpath (kernel/locking/qspinlock_paravirt.h:508) Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011 RIP: 0010:__pv_queued_spin_unlock_slowpath (kernel/locking/qspinlock_paravirt.h:508) Code: 73 56 3a ff 90 c3 cc cc cc cc 8b 05 bb 1f 48 01 85 c0 74 05 c3 cc cc cc cc 8b 17 48 89 fe 48 c7 c7 30 20 ce 8f e8 ad 56 42 ff <0f> 0b c3 cc cc cc cc 0f 0b 0f 1f 40 00 90 90 90 90 90 90 90 90 90 RSP: 0018:ffffa8d200604cb8 EFLAGS: 00010282 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffff9d1ef60e0908 RDX: 00000000ffffffd8 RSI: 0000000000000027 RDI: ffff9d1ef60e0900 RBP: ffff9d181cd5c280 R08: 0000000000000000 R09: 00000000ffff7fff R10: ffffa8d200604b68 R11: ffffffff907dcdc8 R12: 0000000000000000 R13: ffff9d181cd5c660 R14: ffff9d1813a3f330 R15: 0000000000001000 FS: 00007fa110184640(0000) GS:ffff9d1ef60c0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020000000 CR3: 000000011f65e000 CR4: 00000000000006f0 Call Trace: <IRQ> _raw_spin_unlock (kernel/locking/spinlock.c:186) inet_csk_reqsk_queue_add (net/ipv4/inet_connection_sock.c:1321) inet_csk_complete_hashdance (net/ipv4/inet_connection_sock.c:1358) tcp_check_req (net/ipv4/tcp_minisocks.c:868) tcp_v4_rcv (net/ipv4/tcp_ipv4.c:2260) ip_protocol_deliver_rcu (net/ipv4/ip_input.c:205) ip_local_deliver_finish (net/ipv4/ip_input.c:234) __netif_receive_skb_one_core (net/core/dev.c:5529) process_backlog (./include/linux/rcupdate.h:779) __napi_poll (net/core/dev.c:6533) net_rx_action (net/core/dev.c:6604) __do_softirq (./arch/x86/include/asm/jump_label.h:27) do_softirq (kernel/softirq.c:454 kernel/softirq.c:441) </IRQ> <TASK> __local_bh_enable_ip (kernel/softirq.c:381) __dev_queue_xmit (net/core/dev.c:4374) ip_finish_output2 (./include/net/neighbour.h:540 net/ipv4/ip_output.c:235) __ip_queue_xmit (net/ipv4/ip_output.c:535) __tcp_transmit_skb (net/ipv4/tcp_output.c:1462) tcp_rcv_synsent_state_process (net/ipv4/tcp_input.c:6469) tcp_rcv_state_process (net/ipv4/tcp_input.c:6657) tcp_v4_do_rcv (net/ipv4/tcp_ipv4.c:1929) __release_sock (./include/net/sock.h:1121 net/core/sock.c:2968) release_sock (net/core/sock.c:3536) inet_wait_for_connect (net/ipv4/af_inet.c:609) __inet_stream_connect (net/ipv4/af_inet.c:702) inet_stream_connect (net/ipv4/af_inet.c:748) __sys_connect (./include/linux/file.h:45 net/socket.c:2064) __x64_sys_connect (net/socket.c:2073 net/socket.c:2070 net/socket.c:2070) do_syscall_64 (arch/x86/entry/common.c:51 arch/x86/entry/common.c:82) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:129) RIP: 0033:0x7fa10ff05a3d Code: 5b 41 5c c3 66 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d ab a3 0e 00 f7 d8 64 89 01 48 RSP: 002b:00007fa110183de8 EFLAGS: 00000202 ORIG_RAX: 000000000000002a RAX: ffffffffffffffda RBX: 0000000020000054 RCX: 00007fa10ff05a3d RDX: 000000000000001c RSI: 0000000020000040 RDI: 0000000000000003 RBP: 00007fa110183e20 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000202 R12: 00007fa110184640 R13: 0000000000000000 R14: 00007fa10fe8b060 R15: 00007fff73e23b20 </TASK> The issue triggering process is analyzed as follows: Thread A Thread B tcp_v4_rcv //receive ack TCP packet inet_shutdown tcp_check_req tcp_disconnect //disconnect sock ... tcp_set_state(sk, TCP_CLOSE) inet_csk_complete_hashdance ... inet_csk_reqsk_queue_add ---truncated---
CWE-413 - Improper Resource LockingIn the Linux kernel, the following vulnerability has been resolved: arm64/sme: Always exit sme_alloc() early with existing storage When sme_alloc() is called with existing storage and we are not flushing we will always allocate new storage, both leaking the existing storage and corrupting the state. Fix this by separating the checks for flushing and for existing storage as we do for SVE. Callers that reallocate (eg, due to changing the vector length) should call sme_free() themselves.
In the Linux kernel, the following vulnerability has been resolved: ipv6: mcast: fix data-race in ipv6_mc_down / mld_ifc_work idev->mc_ifc_count can be written over without proper locking. Originally found by syzbot [1], fix this issue by encapsulating calls to mld_ifc_stop_work() (and mld_gq_stop_work() for good measure) with mutex_lock() and mutex_unlock() accordingly as these functions should only be called with mc_lock per their declarations. [1] BUG: KCSAN: data-race in ipv6_mc_down / mld_ifc_work write to 0xffff88813a80c832 of 1 bytes by task 3771 on cpu 0: mld_ifc_stop_work net/ipv6/mcast.c:1080 [inline] ipv6_mc_down+0x10a/0x280 net/ipv6/mcast.c:2725 addrconf_ifdown+0xe32/0xf10 net/ipv6/addrconf.c:3949 addrconf_notify+0x310/0x980 notifier_call_chain kernel/notifier.c:93 [inline] raw_notifier_call_chain+0x6b/0x1c0 kernel/notifier.c:461 __dev_notify_flags+0x205/0x3d0 dev_change_flags+0xab/0xd0 net/core/dev.c:8685 do_setlink+0x9f6/0x2430 net/core/rtnetlink.c:2916 rtnl_group_changelink net/core/rtnetlink.c:3458 [inline] __rtnl_newlink net/core/rtnetlink.c:3717 [inline] rtnl_newlink+0xbb3/0x1670 net/core/rtnetlink.c:3754 rtnetlink_rcv_msg+0x807/0x8c0 net/core/rtnetlink.c:6558 netlink_rcv_skb+0x126/0x220 net/netlink/af_netlink.c:2545 rtnetlink_rcv+0x1c/0x20 net/core/rtnetlink.c:6576 netlink_unicast_kernel net/netlink/af_netlink.c:1342 [inline] netlink_unicast+0x589/0x650 net/netlink/af_netlink.c:1368 netlink_sendmsg+0x66e/0x770 net/netlink/af_netlink.c:1910 ... write to 0xffff88813a80c832 of 1 bytes by task 22 on cpu 1: mld_ifc_work+0x54c/0x7b0 net/ipv6/mcast.c:2653 process_one_work kernel/workqueue.c:2627 [inline] process_scheduled_works+0x5b8/0xa30 kernel/workqueue.c:2700 worker_thread+0x525/0x730 kernel/workqueue.c:2781 ...
CWE-414 - Missing Lock CheckIn the Linux kernel, the following vulnerability has been resolved: nbd: always initialize struct msghdr completely syzbot complains that msg->msg_get_inq value can be uninitialized [1] struct msghdr got many new fields recently, we should always make sure their values is zero by default. [1] BUG: KMSAN: uninit-value in tcp_recvmsg+0x686/0xac0 net/ipv4/tcp.c:2571 tcp_recvmsg+0x686/0xac0 net/ipv4/tcp.c:2571 inet_recvmsg+0x131/0x580 net/ipv4/af_inet.c:879 sock_recvmsg_nosec net/socket.c:1044 [inline] sock_recvmsg+0x12b/0x1e0 net/socket.c:1066 __sock_xmit+0x236/0x5c0 drivers/block/nbd.c:538 nbd_read_reply drivers/block/nbd.c:732 [inline] recv_work+0x262/0x3100 drivers/block/nbd.c:863 process_one_work kernel/workqueue.c:2627 [inline] process_scheduled_works+0x104e/0x1e70 kernel/workqueue.c:2700 worker_thread+0xf45/0x1490 kernel/workqueue.c:2781 kthread+0x3ed/0x540 kernel/kthread.c:388 ret_from_fork+0x66/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:242 Local variable msg created at: __sock_xmit+0x4c/0x5c0 drivers/block/nbd.c:513 nbd_read_reply drivers/block/nbd.c:732 [inline] recv_work+0x262/0x3100 drivers/block/nbd.c:863 CPU: 1 PID: 7465 Comm: kworker/u5:1 Not tainted 6.7.0-rc7-syzkaller-00041-gf016f7547aee #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023 Workqueue: nbd5-recv recv_work
In the Linux kernel, the following vulnerability has been resolved: ip6_tunnel: make sure to pull inner header in __ip6_tnl_rcv() The Linux kernel CVE team has assigned CVE-2024-26641 to this issue. Upstream advisory: https://lore.kernel.org/linux-cve-announce/20240318102117.2839904-12-lee@kernel.org/T
In the Linux kernel, the following vulnerability has been resolved: tracing: Ensure visibility when inserting an element into tracing_map The Linux kernel CVE team has assigned CVE-2024-26645 to this issue. Upstream advisory: https://lore.kernel.org/linux-cve-announce/20240326151722.1258576-4-lee@kernel.org/T
In the Linux kernel, the following vulnerability has been resolved: thermal: intel: hfi: Add syscore callbacks for system-wide PM The kernel allocates a memory buffer and provides its location to the hardware, which uses it to update the HFI table. This allocation occurs during boot and remains constant throughout runtime. When resuming from hibernation, the restore kernel allocates a second memory buffer and reprograms the HFI hardware with the new location as part of a normal boot. The location of the second memory buffer may differ from the one allocated by the image kernel. When the restore kernel transfers control to the image kernel, its HFI buffer becomes invalid, potentially leading to memory corruption if the hardware writes to it (the hardware continues to use the buffer from the restore kernel). It is also possible that the hardware "forgets" the address of the memory buffer when resuming from "deep" suspend. Memory corruption may also occur in such a scenario. To prevent the described memory corruption, disable HFI when preparing to suspend or hibernate. Enable it when resuming. Add syscore callbacks to handle the package of the boot CPU (packages of non-boot CPUs are handled via CPU offline). Syscore ops always run on the boot CPU. Additionally, HFI only needs to be disabled during "deep" suspend and hibernation. Syscore ops only run in these cases. [ rjw: Comment adjustment, subject and changelog edits ]
No description is available for this CVE.
CWE-833 - DeadlockA 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.
A vulnerability was found in the DRM/AMD/Display module of the Linux Kernel. An out-of-bounds access exists in the 'stream_enc_regs' array within DCN301, while accessing the array with 'eng_id,’ could lead to an out-of-bounds access beyond its four-element size, which can cause a system crash.
A NULL pointer dereference flaw was found in the Linux kernel in dcn21_set_pipe(). This issue may lead to a crash.
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix 'panel_cntl' could be null in 'dcn21_set_backlight_level()' 'panel_cntl' structure used to control the display panel could be null, dereferencing it could lead to a null pointer access. Fixes the below: drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn21/dcn21_hwseq.c:269 dcn21_set_backlight_level() error: we previously assumed 'panel_cntl' could be null (see line 250)
In the Linux kernel, the following vulnerability has been resolved: tipc: Check the bearer type before calling tipc_udp_nl_bearer_add() syzbot reported the following general protection fault [1]: general protection fault, probably for non-canonical address 0xdffffc0000000010: 0000 [#1] PREEMPT SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000080-0x0000000000000087] ... RIP: 0010:tipc_udp_is_known_peer+0x9c/0x250 net/tipc/udp_media.c:291 ... Call Trace: <TASK> tipc_udp_nl_bearer_add+0x212/0x2f0 net/tipc/udp_media.c:646 tipc_nl_bearer_add+0x21e/0x360 net/tipc/bearer.c:1089 genl_family_rcv_msg_doit+0x1fc/0x2e0 net/netlink/genetlink.c:972 genl_family_rcv_msg net/netlink/genetlink.c:1052 [inline] genl_rcv_msg+0x561/0x800 net/netlink/genetlink.c:1067 netlink_rcv_skb+0x16b/0x440 net/netlink/af_netlink.c:2544 genl_rcv+0x28/0x40 net/netlink/genetlink.c:1076 netlink_unicast_kernel net/netlink/af_netlink.c:1341 [inline] netlink_unicast+0x53b/0x810 net/netlink/af_netlink.c:1367 netlink_sendmsg+0x8b7/0xd70 net/netlink/af_netlink.c:1909 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0xd5/0x180 net/socket.c:745 ____sys_sendmsg+0x6ac/0x940 net/socket.c:2584 ___sys_sendmsg+0x135/0x1d0 net/socket.c:2638 __sys_sendmsg+0x117/0x1e0 net/socket.c:2667 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x40/0x110 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b The cause of this issue is that when tipc_nl_bearer_add() is called with the TIPC_NLA_BEARER_UDP_OPTS attribute, tipc_udp_nl_bearer_add() is called even if the bearer is not UDP. tipc_udp_is_known_peer() called by tipc_udp_nl_bearer_add() assumes that the media_ptr field of the tipc_bearer has an udp_bearer type object, so the function goes crazy for non-UDP bearers. This patch fixes the issue by checking the bearer type before calling tipc_udp_nl_bearer_add() in tipc_nl_bearer_add().
In the Linux kernel, the following vulnerability has been resolved: hwmon: (coretemp) Fix out-of-bounds memory access Fix a bug that pdata->cpu_map[] is set before out-of-bounds check. The problem might be triggered on systems with more than 128 cores per package.
In the Linux kernel, the following vulnerability has been resolved: net/sched: flower: Fix chain template offload The Linux kernel CVE team has assigned CVE-2024-26669 to this issue. Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024040237-CVE-2024-26669-ca3c@gregkh/T
A vulnerability was found in the Linux kernel. This issue occurs due to the incorrect placement of the TLBI and DSB instructions, which are not placed after all explicit memory accesses, creating the potential for speculative unprivileged loads.
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Fix variable 'mca_funcs' dereferenced before NULL check in 'amdgpu_mca_smu_get_mca_entry()' Fixes the below: drivers/gpu/drm/amd/amdgpu/amdgpu_mca.c:377 amdgpu_mca_smu_get_mca_entry() warn: variable dereferenced before check 'mca_funcs' (see line 368) 357 int amdgpu_mca_smu_get_mca_entry(struct amdgpu_device *adev, enum amdgpu_mca_error_type type, 358 int idx, struct mca_bank_entry *entry) 359 { 360 const struct amdgpu_mca_smu_funcs *mca_funcs = adev->mca.mca_funcs; 361 int count; 362 363 switch (type) { 364 case AMDGPU_MCA_ERROR_TYPE_UE: 365 count = mca_funcs->max_ue_count; mca_funcs is dereferenced here. 366 break; 367 case AMDGPU_MCA_ERROR_TYPE_CE: 368 count = mca_funcs->max_ce_count; mca_funcs is dereferenced here. 369 break; 370 default: 371 return -EINVAL; 372 } 373 374 if (idx >= count) 375 return -EINVAL; 376 377 if (mca_funcs && mca_funcs->mca_get_mca_entry) ^^^^^^^^^ Checked too late!
In the Linux kernel, the following vulnerability has been resolved: x86/lib: Revert to _ASM_EXTABLE_UA() for {get,put}_user() fixups During memory error injection test on kernels >= v6.4, the kernel panics like below. However, this issue couldn't be reproduced on kernels <= v6.3. mce: [Hardware Error]: CPU 296: Machine Check Exception: f Bank 1: bd80000000100134 mce: [Hardware Error]: RIP 10:<ffffffff821b9776> {__get_user_nocheck_4+0x6/0x20} mce: [Hardware Error]: TSC 411a93533ed ADDR 346a8730040 MISC 86 mce: [Hardware Error]: PROCESSOR 0:a06d0 TIME 1706000767 SOCKET 1 APIC 211 microcode 80001490 mce: [Hardware Error]: Run the above through 'mcelog --ascii' mce: [Hardware Error]: Machine check: Data load in unrecoverable area of kernel Kernel panic - not syncing: Fatal local machine check The MCA code can recover from an in-kernel #MC if the fixup type is EX_TYPE_UACCESS, explicitly indicating that the kernel is attempting to access userspace memory. However, if the fixup type is EX_TYPE_DEFAULT the only thing that is raised for an in-kernel #MC is a panic. ex_handler_uaccess() would warn if users gave a non-canonical addresses (with bit 63 clear) to {get, put}_user(), which was unexpected. Therefore, commit b19b74bc99b1 ("x86/mm: Rework address range check in get_user() and put_user()") replaced _ASM_EXTABLE_UA() with _ASM_EXTABLE() for {get, put}_user() fixups. However, the new fixup type EX_TYPE_DEFAULT results in a panic. Commit 6014bc27561f ("x86-64: make access_ok() independent of LAM") added the check gp_fault_address_ok() right before the WARN_ONCE() in ex_handler_uaccess() to not warn about non-canonical user addresses due to LAM. With that in place, revert back to _ASM_EXTABLE_UA() for {get,put}_user() exception fixups in order to be able to handle in-kernel MCEs correctly again. [ bp: Massage commit message. ]
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
In the Linux kernel, the following vulnerability has been resolved: x86/efistub: Use 1:1 file:memory mapping for PE/COFF .compat section The .compat section is a dummy PE section that contains the address of the 32-bit entrypoint of the 64-bit kernel image if it is bootable from 32-bit firmware (i.e., CONFIG_EFI_MIXED=y) This section is only 8 bytes in size and is only referenced from the loader, and so it is placed at the end of the memory view of the image, to avoid the need for padding it to 4k, which is required for sections appearing in the middle of the image. Unfortunately, this violates the PE/COFF spec, and even if most EFI loaders will work correctly (including the Tianocore reference implementation), PE loaders do exist that reject such images, on the basis that both the file and memory views of the file contents should be described by the section headers in a monotonically increasing manner without leaving any gaps. So reorganize the sections to avoid this issue. This results in a slight padding overhead (< 4k) which can be avoided if desired by disabling CONFIG_EFI_MIXED (which is only needed in rare cases these days)
In the Linux kernel, the following vulnerability has been resolved: inet: read sk->sk_family once in inet_recv_error() inet_recv_error() is called without holding the socket lock. IPv6 socket could mutate to IPv4 with IPV6_ADDRFORM socket option and trigger a KCSAN warning.
In the Linux kernel, the following vulnerability has been resolved: net: atlantic: Fix DMA mapping for PTP hwts ring Function aq_ring_hwts_rx_alloc() maps extra AQ_CFG_RXDS_DEF bytes for PTP HWTS ring but then generic aq_ring_free() does not take this into account. Create and use a specific function to free HWTS ring to fix this issue. Trace: [ 215.351607] ------------[ cut here ]------------ [ 215.351612] DMA-API: atlantic 0000:4b:00.0: device driver frees DMA memory with different size [device address=0x00000000fbdd0000] [map size=34816 bytes] [unmap size=32768 bytes] [ 215.351635] WARNING: CPU: 33 PID: 10759 at kernel/dma/debug.c:988 check_unmap+0xa6f/0x2360 ... [ 215.581176] Call Trace: [ 215.583632] <TASK> [ 215.585745] ? show_trace_log_lvl+0x1c4/0x2df [ 215.590114] ? show_trace_log_lvl+0x1c4/0x2df [ 215.594497] ? debug_dma_free_coherent+0x196/0x210 [ 215.599305] ? check_unmap+0xa6f/0x2360 [ 215.603147] ? __warn+0xca/0x1d0 [ 215.606391] ? check_unmap+0xa6f/0x2360 [ 215.610237] ? report_bug+0x1ef/0x370 [ 215.613921] ? handle_bug+0x3c/0x70 [ 215.617423] ? exc_invalid_op+0x14/0x50 [ 215.621269] ? asm_exc_invalid_op+0x16/0x20 [ 215.625480] ? check_unmap+0xa6f/0x2360 [ 215.629331] ? mark_lock.part.0+0xca/0xa40 [ 215.633445] debug_dma_free_coherent+0x196/0x210 [ 215.638079] ? __pfx_debug_dma_free_coherent+0x10/0x10 [ 215.643242] ? slab_free_freelist_hook+0x11d/0x1d0 [ 215.648060] dma_free_attrs+0x6d/0x130 [ 215.651834] aq_ring_free+0x193/0x290 [atlantic] [ 215.656487] aq_ptp_ring_free+0x67/0x110 [atlantic] ... [ 216.127540] ---[ end trace 6467e5964dd2640b ]--- [ 216.132160] DMA-API: Mapped at: [ 216.132162] debug_dma_alloc_coherent+0x66/0x2f0 [ 216.132165] dma_alloc_attrs+0xf5/0x1b0 [ 216.132168] aq_ring_hwts_rx_alloc+0x150/0x1f0 [atlantic] [ 216.132193] aq_ptp_ring_alloc+0x1bb/0x540 [atlantic] [ 216.132213] aq_nic_init+0x4a1/0x760 [atlantic]
A vulnerability was found in the do_task_stat() function in the Linux kernel, where due to excessive lock contention, a potential hard lockup could be created. This can create a performance bottleneck and lead to kernel unresponsiveness.
In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: Fix circular locking dependency The rule inside kvm enforces that the vcpu->mutex is taken *inside* kvm->lock. The rule is violated by the pkvm_create_hyp_vm() which acquires the kvm->lock while already holding the vcpu->mutex lock from kvm_vcpu_ioctl(). Avoid the circular locking dependency altogether by protecting the hyp vm handle with the config_lock, much like we already do for other forms of VM-scoped data.
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix MST Null Ptr for RV The change try to fix below error specific to RV platform: BUG: kernel NULL pointer dereference, address: 0000000000000008 PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 4 PID: 917 Comm: sway Not tainted 6.3.9-arch1-1 #1 124dc55df4f5272ccb409f39ef4872fc2b3376a2 Hardware name: LENOVO 20NKS01Y00/20NKS01Y00, BIOS R12ET61W(1.31 ) 07/28/2022 RIP: 0010:drm_dp_atomic_find_time_slots+0x5e/0x260 [drm_display_helper] Code: 01 00 00 48 8b 85 60 05 00 00 48 63 80 88 00 00 00 3b 43 28 0f 8d 2e 01 00 00 48 8b 53 30 48 8d 04 80 48 8d 04 c2 48 8b 40 18 <48> 8> RSP: 0018:ffff960cc2df77d8 EFLAGS: 00010293 RAX: 0000000000000000 RBX: ffff8afb87e81280 RCX: 0000000000000224 RDX: ffff8afb9ee37c00 RSI: ffff8afb8da1a578 RDI: ffff8afb87e81280 RBP: ffff8afb83d67000 R08: 0000000000000001 R09: ffff8afb9652f850 R10: ffff960cc2df7908 R11: 0000000000000002 R12: 0000000000000000 R13: ffff8afb8d7688a0 R14: ffff8afb8da1a578 R15: 0000000000000224 FS: 00007f4dac35ce00(0000) GS:ffff8afe30b00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000008 CR3: 000000010ddc6000 CR4: 00000000003506e0 Call Trace: <TASK> ? __die+0x23/0x70 ? page_fault_oops+0x171/0x4e0 ? plist_add+0xbe/0x100 ? exc_page_fault+0x7c/0x180 ? asm_exc_page_fault+0x26/0x30 ? drm_dp_atomic_find_time_slots+0x5e/0x260 [drm_display_helper 0e67723696438d8e02b741593dd50d80b44c2026] ? drm_dp_atomic_find_time_slots+0x28/0x260 [drm_display_helper 0e67723696438d8e02b741593dd50d80b44c2026] compute_mst_dsc_configs_for_link+0x2ff/0xa40 [amdgpu 62e600d2a75e9158e1cd0a243bdc8e6da040c054] ? fill_plane_buffer_attributes+0x419/0x510 [amdgpu 62e600d2a75e9158e1cd0a243bdc8e6da040c054] compute_mst_dsc_configs_for_state+0x1e1/0x250 [amdgpu 62e600d2a75e9158e1cd0a243bdc8e6da040c054] amdgpu_dm_atomic_check+0xecd/0x1190 [amdgpu 62e600d2a75e9158e1cd0a243bdc8e6da040c054] drm_atomic_check_only+0x5c5/0xa40 drm_mode_atomic_ioctl+0x76e/0xbc0 ? _copy_to_user+0x25/0x30 ? drm_ioctl+0x296/0x4b0 ? __pfx_drm_mode_atomic_ioctl+0x10/0x10 drm_ioctl_kernel+0xcd/0x170 drm_ioctl+0x26d/0x4b0 ? __pfx_drm_mode_atomic_ioctl+0x10/0x10 amdgpu_drm_ioctl+0x4e/0x90 [amdgpu 62e600d2a75e9158e1cd0a243bdc8e6da040c054] __x64_sys_ioctl+0x94/0xd0 do_syscall_64+0x60/0x90 ? do_syscall_64+0x6c/0x90 entry_SYSCALL_64_after_hwframe+0x72/0xdc RIP: 0033:0x7f4dad17f76f Code: 00 48 89 44 24 18 31 c0 48 8d 44 24 60 c7 04 24 10 00 00 00 48 89 44 24 08 48 8d 44 24 20 48 89 44 24 10 b8 10 00 00 00 0f 05 <89> c> RSP: 002b:00007ffd9ae859f0 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 000055e255a55900 RCX: 00007f4dad17f76f RDX: 00007ffd9ae85a90 RSI: 00000000c03864bc RDI: 000000000000000b RBP: 00007ffd9ae85a90 R08: 0000000000000003 R09: 0000000000000003 R10: 0000000000000000 R11: 0000000000000246 R12: 00000000c03864bc R13: 000000000000000b R14: 000055e255a7fc60 R15: 000055e255a01eb0 </TASK> Modules linked in: rfcomm snd_seq_dummy snd_hrtimer snd_seq snd_seq_device ccm cmac algif_hash algif_skcipher af_alg joydev mousedev bnep > typec libphy k10temp ipmi_msghandler roles i2c_scmi acpi_cpufreq mac_hid nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_mas> CR2: 0000000000000008 ---[ end trace 0000000000000000 ]--- RIP: 0010:drm_dp_atomic_find_time_slots+0x5e/0x260 [drm_display_helper] Code: 01 00 00 48 8b 85 60 05 00 00 48 63 80 88 00 00 00 3b 43 28 0f 8d 2e 01 00 00 48 8b 53 30 48 8d 04 80 48 8d 04 c2 48 8b 40 18 <48> 8> RSP: 0018:ffff960cc2df77d8 EFLAGS: 00010293 RAX: 0000000000000000 RBX: ffff8afb87e81280 RCX: 0000000000000224 RDX: ffff8afb9ee37c00 RSI: ffff8afb8da1a578 RDI: ffff8afb87e81280 RBP: ffff8afb83d67000 R08: 0000000000000001 R09: ffff8afb9652f850 R10: ffff960cc2df7908 R11: 0000000000000002 R12: 0000000000000000 R13: ffff8afb8d7688a0 R14: ffff8afb8da1a578 R15: 0000000000000224 FS: 00007f4dac35ce00(0000) GS:ffff8afe30b00000(0000 ---truncated---
A vulnerability was found in the Linux kernel. This issue occurs in the ext4 function, in ext4_move_extents(), where an error in updating the moved_len variable can lead to double-free of blocks and corrupt block accounting. This could lead to crashes or undefined behavior.
A vulnerability in the Linux kernel affects the High-availability Seamless Redundancy (HSR) protocol. The issue was identified when a warning (WARN_ONCE()) was triggered due to failed resource allocation for skb in the hsr_init_skb() function. The WARN_ONCE() was initially used to log this failure, but it was not deemed helpful in resolving it. Instead, the kernel maintainers switched to using netdev_warn_once() to better handle the failure and avoid excessive warning reports.
A vulnerability was found in the subflow_simultaneous_connect() function in the mptcp component in the Linux kernel, where not all possible subflow states are evaluated, leading to a potential race condition. This issue could lead to undefined network behavior.
In the Linux kernel, the following vulnerability has been resolved: powerpc/kasan: Fix addr error caused by page alignment In kasan_init_region, when k_start is not page aligned, at the begin of for loop, k_cur = k_start & PAGE_MASK is less than k_start, and then `va = block + k_cur - k_start` is less than block, the addr va is invalid, because the memory address space from va to block is not alloced by memblock_alloc, which will not be reserved by memblock_reserve later, it will be used by other places. As a result, memory overwriting occurs. for example: int __init __weak kasan_init_region(void *start, size_t size) { [...] /* if say block(dcd97000) k_start(feef7400) k_end(feeff3fe) */ block = memblock_alloc(k_end - k_start, PAGE_SIZE); [...] for (k_cur = k_start & PAGE_MASK; k_cur < k_end; k_cur += PAGE_SIZE) { /* at the begin of for loop * block(dcd97000) va(dcd96c00) k_cur(feef7000) k_start(feef7400) * va(dcd96c00) is less than block(dcd97000), va is invalid */ void *va = block + k_cur - k_start; [...] } [...] } Therefore, page alignment is performed on k_start before memblock_alloc() to ensure the validity of the VA address.
In the Linux kernel, the following vulnerability has been resolved: HID: i2c-hid-of: fix NULL-deref on failed power up A while back the I2C HID implementation was split in an ACPI and OF part, but the new OF driver never initialises the client pointer which is dereferenced on power-up failures.
In the Linux kernel, the following vulnerability has been resolved: nouveau: offload fence uevents work to workqueue This should break the deadlock between the fctx lock and the irq lock. This offloads the processing off the work from the irq into a workqueue.
A vulnerability was found in the Linux kernel, where an ABBA deadlock condition may be created if multiple CPUs attempt a DPLL netlink dump operation simultaneously. This deadlock could lead to performance issues.
A vulnerability was found in the arp_req_get() function in the Linux kernel when handling the SIOCGARP ioctl (input/output control) request. This function copies data over into a fixed-length buffer which could result in a buffer overflow and cause memory corruption, undefined behavior, or crashes.
A vulnerability was found in the devlink_init() function in the Linux kernel. Use-after-free and memory leak issues can occur due to an incorrect order of initialization and cleanup in case of errors. This issue could lead to memory corruption or crashes.
A potential deadlock flaw was found in net/sched/act_mirred.c in the Linux kernel. This may lead to compromised Availability.
In the Linux kernel, the following vulnerability has been resolved: RDMA/qedr: Fix qedr_create_user_qp error flow The Linux kernel CVE team has assigned CVE-2024-26743 to this issue. Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024040301-CVE-2024-26743-6034@gregkh/T
A flaw was foundin the Linux Kernel when specifying the srpt_service_guid parameter, which may lead to kernel crash.
In the Linux kernel, the following vulnerability has been resolved: dmaengine: idxd: Ensure safe user copy of completion record If CONFIG_HARDENED_USERCOPY is enabled, copying completion record from event log cache to user triggers a kernel bug. [ 1987.159822] usercopy: Kernel memory exposure attempt detected from SLUB object 'dsa0' (offset 74, size 31)! [ 1987.170845] ------------[ cut here ]------------ [ 1987.176086] kernel BUG at mm/usercopy.c:102! [ 1987.180946] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI [ 1987.186866] CPU: 17 PID: 528 Comm: kworker/17:1 Not tainted 6.8.0-rc2+ #5 [ 1987.194537] Hardware name: Intel Corporation AvenueCity/AvenueCity, BIOS BHSDCRB1.86B.2492.D03.2307181620 07/18/2023 [ 1987.206405] Workqueue: wq0.0 idxd_evl_fault_work [idxd] [ 1987.212338] RIP: 0010:usercopy_abort+0x72/0x90 [ 1987.217381] Code: 58 65 9c 50 48 c7 c2 17 85 61 9c 57 48 c7 c7 98 fd 6b 9c 48 0f 44 d6 48 c7 c6 b3 08 62 9c 4c 89 d1 49 0f 44 f3 e8 1e 2e d5 ff <0f> 0b 49 c7 c1 9e 42 61 9c 4c 89 cf 4d 89 c8 eb a9 66 66 2e 0f 1f [ 1987.238505] RSP: 0018:ff62f5cf20607d60 EFLAGS: 00010246 [ 1987.244423] RAX: 000000000000005f RBX: 000000000000001f RCX: 0000000000000000 [ 1987.252480] RDX: 0000000000000000 RSI: ffffffff9c61429e RDI: 00000000ffffffff [ 1987.260538] RBP: ff62f5cf20607d78 R08: ff2a6a89ef3fffe8 R09: 00000000fffeffff [ 1987.268595] R10: ff2a6a89eed00000 R11: 0000000000000003 R12: ff2a66934849c89a [ 1987.276652] R13: 0000000000000001 R14: ff2a66934849c8b9 R15: ff2a66934849c899 [ 1987.284710] FS: 0000000000000000(0000) GS:ff2a66b22fe40000(0000) knlGS:0000000000000000 [ 1987.293850] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1987.300355] CR2: 00007fe291a37000 CR3: 000000010fbd4005 CR4: 0000000000f71ef0 [ 1987.308413] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 1987.316470] DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400 [ 1987.324527] PKRU: 55555554 [ 1987.327622] Call Trace: [ 1987.330424] <TASK> [ 1987.332826] ? show_regs+0x6e/0x80 [ 1987.336703] ? die+0x3c/0xa0 [ 1987.339988] ? do_trap+0xd4/0xf0 [ 1987.343662] ? do_error_trap+0x75/0xa0 [ 1987.347922] ? usercopy_abort+0x72/0x90 [ 1987.352277] ? exc_invalid_op+0x57/0x80 [ 1987.356634] ? usercopy_abort+0x72/0x90 [ 1987.360988] ? asm_exc_invalid_op+0x1f/0x30 [ 1987.365734] ? usercopy_abort+0x72/0x90 [ 1987.370088] __check_heap_object+0xb7/0xd0 [ 1987.374739] __check_object_size+0x175/0x2d0 [ 1987.379588] idxd_copy_cr+0xa9/0x130 [idxd] [ 1987.384341] idxd_evl_fault_work+0x127/0x390 [idxd] [ 1987.389878] process_one_work+0x13e/0x300 [ 1987.394435] ? __pfx_worker_thread+0x10/0x10 [ 1987.399284] worker_thread+0x2f7/0x420 [ 1987.403544] ? _raw_spin_unlock_irqrestore+0x2b/0x50 [ 1987.409171] ? __pfx_worker_thread+0x10/0x10 [ 1987.414019] kthread+0x107/0x140 [ 1987.417693] ? __pfx_kthread+0x10/0x10 [ 1987.421954] ret_from_fork+0x3d/0x60 [ 1987.426019] ? __pfx_kthread+0x10/0x10 [ 1987.430281] ret_from_fork_asm+0x1b/0x30 [ 1987.434744] </TASK> The issue arises because event log cache is created using kmem_cache_create() which is not suitable for user copy. Fix the issue by creating event log cache with kmem_cache_create_usercopy(), ensuring safe user copy.
In the Linux kernel, the following vulnerability has been resolved: md: Don't ignore read-only array in md_check_recovery() The Linux kernel CVE team has assigned CVE-2024-26757 to this issue. Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024040304-CVE-2024-26757-7f96@gregkh/T
In the Linux kernel, the following vulnerability has been resolved: md: Don't ignore suspended array in md_check_recovery() The Linux kernel CVE team has assigned CVE-2024-26758 to this issue. Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024040304-CVE-2024-26758-dcc3@gregkh/T
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
In the Linux kernel, the following vulnerability has been resolved: cxl/pci: Fix disabling memory if DVSEC CXL Range does not match a CFMWS window The Linux kernel CVE team has assigned CVE-2024-26761 to this issue. Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024040305-CVE-2024-26761-0646@gregkh/T
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: fixed integer types and null check locations [why]: issues fixed: - comparison with wider integer type in loop condition which can cause infinite loops - pointer dereference before null check
A vulnerability was found in the ext4_mb_find_by_goal() function in the Linux kernel. This issue could lead to memory corruption or crashes due to the allocation of blocks from a group with a corrupted block bitmap.
In the Linux kernel, the following vulnerability has been resolved: ext4: avoid dividing by 0 in mb_update_avg_fragment_size() when block bitmap corrupt The Linux kernel CVE team has assigned CVE-2024-26774 to this issue. Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024040308-CVE-2024-26774-52d9@gregkh/T
In the Linux kernel, the following vulnerability has been resolved: mptcp: fix double-free on socket dismantle when MPTCP server accepts an incoming connection, it clones its listener socket. However, the pointer to 'inet_opt' for the new socket has the same value as the original one: as a consequence, on program exit it's possible to observe the following splat: BUG: KASAN: double-free in inet_sock_destruct+0x54f/0x8b0 Free of addr ffff888485950880 by task swapper/25/0 CPU: 25 PID: 0 Comm: swapper/25 Kdump: loaded Not tainted 6.8.0-rc1+ #609 Hardware name: Supermicro SYS-6027R-72RF/X9DRH-7TF/7F/iTF/iF, BIOS 3.0 07/26/2013 Call Trace: <IRQ> dump_stack_lvl+0x32/0x50 print_report+0xca/0x620 kasan_report_invalid_free+0x64/0x90 __kasan_slab_free+0x1aa/0x1f0 kfree+0xed/0x2e0 inet_sock_destruct+0x54f/0x8b0 __sk_destruct+0x48/0x5b0 rcu_do_batch+0x34e/0xd90 rcu_core+0x559/0xac0 __do_softirq+0x183/0x5a4 irq_exit_rcu+0x12d/0x170 sysvec_apic_timer_interrupt+0x6b/0x80 </IRQ> <TASK> asm_sysvec_apic_timer_interrupt+0x16/0x20 RIP: 0010:cpuidle_enter_state+0x175/0x300 Code: 30 00 0f 84 1f 01 00 00 83 e8 01 83 f8 ff 75 e5 48 83 c4 18 44 89 e8 5b 5d 41 5c 41 5d 41 5e 41 5f c3 cc cc cc cc fb 45 85 ed <0f> 89 60 ff ff ff 48 c1 e5 06 48 c7 43 18 00 00 00 00 48 83 44 2b RSP: 0018:ffff888481cf7d90 EFLAGS: 00000202 RAX: 0000000000000000 RBX: ffff88887facddc8 RCX: 0000000000000000 RDX: 1ffff1110ff588b1 RSI: 0000000000000019 RDI: ffff88887fac4588 RBP: 0000000000000004 R08: 0000000000000002 R09: 0000000000043080 R10: 0009b02ea273363f R11: ffff88887fabf42b R12: ffffffff932592e0 R13: 0000000000000004 R14: 0000000000000000 R15: 00000022c880ec80 cpuidle_enter+0x4a/0xa0 do_idle+0x310/0x410 cpu_startup_entry+0x51/0x60 start_secondary+0x211/0x270 secondary_startup_64_no_verify+0x184/0x18b </TASK> Allocated by task 6853: kasan_save_stack+0x1c/0x40 kasan_save_track+0x10/0x30 __kasan_kmalloc+0xa6/0xb0 __kmalloc+0x1eb/0x450 cipso_v4_sock_setattr+0x96/0x360 netlbl_sock_setattr+0x132/0x1f0 selinux_netlbl_socket_post_create+0x6c/0x110 selinux_socket_post_create+0x37b/0x7f0 security_socket_post_create+0x63/0xb0 __sock_create+0x305/0x450 __sys_socket_create.part.23+0xbd/0x130 __sys_socket+0x37/0xb0 __x64_sys_socket+0x6f/0xb0 do_syscall_64+0x83/0x160 entry_SYSCALL_64_after_hwframe+0x6e/0x76 Freed by task 6858: kasan_save_stack+0x1c/0x40 kasan_save_track+0x10/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x12c/0x1f0 kfree+0xed/0x2e0 inet_sock_destruct+0x54f/0x8b0 __sk_destruct+0x48/0x5b0 subflow_ulp_release+0x1f0/0x250 tcp_cleanup_ulp+0x6e/0x110 tcp_v4_destroy_sock+0x5a/0x3a0 inet_csk_destroy_sock+0x135/0x390 tcp_fin+0x416/0x5c0 tcp_data_queue+0x1bc8/0x4310 tcp_rcv_state_process+0x15a3/0x47b0 tcp_v4_do_rcv+0x2c1/0x990 tcp_v4_rcv+0x41fb/0x5ed0 ip_protocol_deliver_rcu+0x6d/0x9f0 ip_local_deliver_finish+0x278/0x360 ip_local_deliver+0x182/0x2c0 ip_rcv+0xb5/0x1c0 __netif_receive_skb_one_core+0x16e/0x1b0 process_backlog+0x1e3/0x650 __napi_poll+0xa6/0x500 net_rx_action+0x740/0xbb0 __do_softirq+0x183/0x5a4 The buggy address belongs to the object at ffff888485950880 which belongs to the cache kmalloc-64 of size 64 The buggy address is located 0 bytes inside of 64-byte region [ffff888485950880, ffff8884859508c0) The buggy address belongs to the physical page: page:0000000056d1e95e refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff888485950700 pfn:0x485950 flags: 0x57ffffc0000800(slab|node=1|zone=2|lastcpupid=0x1fffff) page_type: 0xffffffff() raw: 0057ffffc0000800 ffff88810004c640 ffffea00121b8ac0 dead000000000006 raw: ffff888485950700 0000000000200019 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff888485950780: fa fb fb ---truncated---
A protection fault vulnerability was found in the iommufd subsystem of the Linux kernel. This flaw could lead to unexpected behavior or system instability.
In the Linux kernel, the following vulnerability has been resolved: iommufd: Fix iopt_access_list_id overwrite bug The Linux kernel CVE team has assigned CVE-2024-26786 to this issue. Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024040459-CVE-2024-26786-802f@gregkh/T
In the Linux kernel, the following vulnerability has been resolved: net: veth: clear GRO when clearing XDP even when down The Linux kernel CVE team has assigned CVE-2024-26803 to this issue. Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024040404-CVE-2024-26803-9985@gregkh/T
An interrupt handling flaw was found in the Linux kernel’s PCI core device driver. This flaw allows a local user to potentially crash the system.
In the Linux kernel, the following vulnerability has been resolved: net/sched: taprio: proper TCA_TAPRIO_TC_ENTRY_INDEX check The Linux kernel CVE team has assigned CVE-2024-26815 to this issue. Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024041006-CVE-2024-26815-7f4e@gregkh/T
In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: set dormant flag on hook register failure We need to set the dormant flag again if we fail to register the hooks. During memory pressure hook registration can fail and we end up with a table marked as active but no registered hooks. On table/base chain deletion, nf_tables will attempt to unregister the hook again which yields a warn splat from the nftables core.
A flaw was found in the Linux kernel. A race condition in network bridge management could lead to a denial of service.
In the Linux kernel, the following vulnerability has been resolved: RDMA/irdma: Fix KASAN issue with tasklet KASAN testing revealed the following issue assocated with freeing an IRQ. [50006.466686] Call Trace: [50006.466691] <IRQ> [50006.489538] dump_stack+0x5c/0x80 [50006.493475] print_address_description.constprop.6+0x1a/0x150 [50006.499872] ? irdma_sc_process_ceq+0x483/0x790 [irdma] [50006.505742] ? irdma_sc_process_ceq+0x483/0x790 [irdma] [50006.511644] kasan_report.cold.11+0x7f/0x118 [50006.516572] ? irdma_sc_process_ceq+0x483/0x790 [irdma] [50006.522473] irdma_sc_process_ceq+0x483/0x790 [irdma] [50006.528232] irdma_process_ceq+0xb2/0x400 [irdma] [50006.533601] ? irdma_hw_flush_wqes_callback+0x370/0x370 [irdma] [50006.540298] irdma_ceq_dpc+0x44/0x100 [irdma] [50006.545306] tasklet_action_common.isra.14+0x148/0x2c0 [50006.551096] __do_softirq+0x1d0/0xaf8 [50006.555396] irq_exit_rcu+0x219/0x260 [50006.559670] irq_exit+0xa/0x20 [50006.563320] smp_apic_timer_interrupt+0x1bf/0x690 [50006.568645] apic_timer_interrupt+0xf/0x20 [50006.573341] </IRQ> The issue is that a tasklet could be pending on another core racing the delete of the irq. Fix by insuring any scheduled tasklet is killed after deleting the irq.
In the Linux kernel, the following vulnerability has been resolved: cachefiles: fix memory leak in cachefiles_add_cache() The Linux kernel CVE team has assigned CVE-2024-26840 to this issue. Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024041715-CVE-2024-26840-057d@gregkh/T
A flaw was found in the Linux kernel. Due to an integer overflow, certain EFI-related memory reservations might receive a size other than expected, leading to a denial of service.
In the Linux kernel, the following vulnerability has been resolved: nvme-fc: do not wait in vain when unloading module The module exit path has race between deleting all controllers and freeing 'left over IDs'. To prevent double free a synchronization between nvme_delete_ctrl and ida_destroy has been added by the initial commit. There is some logic around trying to prevent from hanging forever in wait_for_completion, though it does not handling all cases. E.g. blktests is able to reproduce the situation where the module unload hangs forever. If we completely rely on the cleanup code executed from the nvme_delete_ctrl path, all IDs will be freed eventually. This makes calling ida_destroy unnecessary. We only have to ensure that all nvme_delete_ctrl code has been executed before we leave nvme_fc_exit_module. This is done by flushing the nvme_delete_wq workqueue. While at it, remove the unused nvme_fc_wq workqueue too.
In the Linux kernel, the following vulnerability has been resolved: geneve: make sure to pull inner header in geneve_rx() syzbot triggered a bug in geneve_rx() [1] Issue is similar to the one I fixed in commit 8d975c15c0cd ("ip6_tunnel: make sure to pull inner header in __ip6_tnl_rcv()") We have to save skb->network_header in a temporary variable in order to be able to recompute the network_header pointer after a pskb_inet_may_pull() call. pskb_inet_may_pull() makes sure the needed headers are in skb->head. [1] BUG: KMSAN: uninit-value in IP_ECN_decapsulate include/net/inet_ecn.h:302 [inline] BUG: KMSAN: uninit-value in geneve_rx drivers/net/geneve.c:279 [inline] BUG: KMSAN: uninit-value in geneve_udp_encap_recv+0x36f9/0x3c10 drivers/net/geneve.c:391 IP_ECN_decapsulate include/net/inet_ecn.h:302 [inline] geneve_rx drivers/net/geneve.c:279 [inline] geneve_udp_encap_recv+0x36f9/0x3c10 drivers/net/geneve.c:391 udp_queue_rcv_one_skb+0x1d39/0x1f20 net/ipv4/udp.c:2108 udp_queue_rcv_skb+0x6ae/0x6e0 net/ipv4/udp.c:2186 udp_unicast_rcv_skb+0x184/0x4b0 net/ipv4/udp.c:2346 __udp4_lib_rcv+0x1c6b/0x3010 net/ipv4/udp.c:2422 udp_rcv+0x7d/0xa0 net/ipv4/udp.c:2604 ip_protocol_deliver_rcu+0x264/0x1300 net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x2b8/0x440 net/ipv4/ip_input.c:233 NF_HOOK include/linux/netfilter.h:314 [inline] ip_local_deliver+0x21f/0x490 net/ipv4/ip_input.c:254 dst_input include/net/dst.h:461 [inline] ip_rcv_finish net/ipv4/ip_input.c:449 [inline] NF_HOOK include/linux/netfilter.h:314 [inline] ip_rcv+0x46f/0x760 net/ipv4/ip_input.c:569 __netif_receive_skb_one_core net/core/dev.c:5534 [inline] __netif_receive_skb+0x1a6/0x5a0 net/core/dev.c:5648 process_backlog+0x480/0x8b0 net/core/dev.c:5976 __napi_poll+0xe3/0x980 net/core/dev.c:6576 napi_poll net/core/dev.c:6645 [inline] net_rx_action+0x8b8/0x1870 net/core/dev.c:6778 __do_softirq+0x1b7/0x7c5 kernel/softirq.c:553 do_softirq+0x9a/0xf0 kernel/softirq.c:454 __local_bh_enable_ip+0x9b/0xa0 kernel/softirq.c:381 local_bh_enable include/linux/bottom_half.h:33 [inline] rcu_read_unlock_bh include/linux/rcupdate.h:820 [inline] __dev_queue_xmit+0x2768/0x51c0 net/core/dev.c:4378 dev_queue_xmit include/linux/netdevice.h:3171 [inline] packet_xmit+0x9c/0x6b0 net/packet/af_packet.c:276 packet_snd net/packet/af_packet.c:3081 [inline] packet_sendmsg+0x8aef/0x9f10 net/packet/af_packet.c:3113 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline] __sys_sendto+0x735/0xa10 net/socket.c:2191 __do_sys_sendto net/socket.c:2203 [inline] __se_sys_sendto net/socket.c:2199 [inline] __x64_sys_sendto+0x125/0x1c0 net/socket.c:2199 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b Uninit was created at: slab_post_alloc_hook mm/slub.c:3819 [inline] slab_alloc_node mm/slub.c:3860 [inline] kmem_cache_alloc_node+0x5cb/0xbc0 mm/slub.c:3903 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:560 __alloc_skb+0x352/0x790 net/core/skbuff.c:651 alloc_skb include/linux/skbuff.h:1296 [inline] alloc_skb_with_frags+0xc8/0xbd0 net/core/skbuff.c:6394 sock_alloc_send_pskb+0xa80/0xbf0 net/core/sock.c:2783 packet_alloc_skb net/packet/af_packet.c:2930 [inline] packet_snd net/packet/af_packet.c:3024 [inline] packet_sendmsg+0x70c2/0x9f10 net/packet/af_packet.c:3113 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline] __sys_sendto+0x735/0xa10 net/socket.c:2191 __do_sys_sendto net/socket.c:2203 [inline] __se_sys_sendto net/socket.c:2199 [inline] __x64_sys_sendto+0x125/0x1c0 net/socket.c:2199 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b
In the Linux kernel, the following vulnerability has been resolved: wireguard: receive: annotate data-race around receiving_counter.counter Syzkaller with KCSAN identified a data-race issue when accessing keypair->receiving_counter.counter. Use READ_ONCE() and WRITE_ONCE() annotations to mark the data race as intentional. BUG: KCSAN: data-race in wg_packet_decrypt_worker / wg_packet_rx_poll write to 0xffff888107765888 of 8 bytes by interrupt on cpu 0: counter_validate drivers/net/wireguard/receive.c:321 [inline] wg_packet_rx_poll+0x3ac/0xf00 drivers/net/wireguard/receive.c:461 __napi_poll+0x60/0x3b0 net/core/dev.c:6536 napi_poll net/core/dev.c:6605 [inline] net_rx_action+0x32b/0x750 net/core/dev.c:6738 __do_softirq+0xc4/0x279 kernel/softirq.c:553 do_softirq+0x5e/0x90 kernel/softirq.c:454 __local_bh_enable_ip+0x64/0x70 kernel/softirq.c:381 __raw_spin_unlock_bh include/linux/spinlock_api_smp.h:167 [inline] _raw_spin_unlock_bh+0x36/0x40 kernel/locking/spinlock.c:210 spin_unlock_bh include/linux/spinlock.h:396 [inline] ptr_ring_consume_bh include/linux/ptr_ring.h:367 [inline] wg_packet_decrypt_worker+0x6c5/0x700 drivers/net/wireguard/receive.c:499 process_one_work kernel/workqueue.c:2633 [inline] ... read to 0xffff888107765888 of 8 bytes by task 3196 on cpu 1: decrypt_packet drivers/net/wireguard/receive.c:252 [inline] wg_packet_decrypt_worker+0x220/0x700 drivers/net/wireguard/receive.c:501 process_one_work kernel/workqueue.c:2633 [inline] process_scheduled_works+0x5b8/0xa30 kernel/workqueue.c:2706 worker_thread+0x525/0x730 kernel/workqueue.c:2787 ...
In the Linux kernel, the following vulnerability has been resolved: packet: annotate data-races around ignore_outgoing ignore_outgoing is read locklessly from dev_queue_xmit_nit() and packet_getsockopt() Add appropriate READ_ONCE()/WRITE_ONCE() annotations. syzbot reported: BUG: KCSAN: data-race in dev_queue_xmit_nit / packet_setsockopt write to 0xffff888107804542 of 1 bytes by task 22618 on cpu 0: packet_setsockopt+0xd83/0xfd0 net/packet/af_packet.c:4003 do_sock_setsockopt net/socket.c:2311 [inline] __sys_setsockopt+0x1d8/0x250 net/socket.c:2334 __do_sys_setsockopt net/socket.c:2343 [inline] __se_sys_setsockopt net/socket.c:2340 [inline] __x64_sys_setsockopt+0x66/0x80 net/socket.c:2340 do_syscall_64+0xd3/0x1d0 entry_SYSCALL_64_after_hwframe+0x6d/0x75 read to 0xffff888107804542 of 1 bytes by task 27 on cpu 1: dev_queue_xmit_nit+0x82/0x620 net/core/dev.c:2248 xmit_one net/core/dev.c:3527 [inline] dev_hard_start_xmit+0xcc/0x3f0 net/core/dev.c:3547 __dev_queue_xmit+0xf24/0x1dd0 net/core/dev.c:4335 dev_queue_xmit include/linux/netdevice.h:3091 [inline] batadv_send_skb_packet+0x264/0x300 net/batman-adv/send.c:108 batadv_send_broadcast_skb+0x24/0x30 net/batman-adv/send.c:127 batadv_iv_ogm_send_to_if net/batman-adv/bat_iv_ogm.c:392 [inline] batadv_iv_ogm_emit net/batman-adv/bat_iv_ogm.c:420 [inline] batadv_iv_send_outstanding_bat_ogm_packet+0x3f0/0x4b0 net/batman-adv/bat_iv_ogm.c:1700 process_one_work kernel/workqueue.c:3254 [inline] process_scheduled_works+0x465/0x990 kernel/workqueue.c:3335 worker_thread+0x526/0x730 kernel/workqueue.c:3416 kthread+0x1d1/0x210 kernel/kthread.c:388 ret_from_fork+0x4b/0x60 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:243 value changed: 0x00 -> 0x01 Reported by Kernel Concurrency Sanitizer on: CPU: 1 PID: 27 Comm: kworker/u8:1 Tainted: G W 6.8.0-syzkaller-08073-g480e035fc4c7 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/29/2024 Workqueue: bat_events batadv_iv_send_outstanding_bat_ogm_packet
In the Linux kernel, the following vulnerability has been resolved: hsr: Fix uninit-value access in hsr_get_node() KMSAN reported the following uninit-value access issue [1]: ===================================================== BUG: KMSAN: uninit-value in hsr_get_node+0xa2e/0xa40 net/hsr/hsr_framereg.c:246 hsr_get_node+0xa2e/0xa40 net/hsr/hsr_framereg.c:246 fill_frame_info net/hsr/hsr_forward.c:577 [inline] hsr_forward_skb+0xe12/0x30e0 net/hsr/hsr_forward.c:615 hsr_dev_xmit+0x1a1/0x270 net/hsr/hsr_device.c:223 __netdev_start_xmit include/linux/netdevice.h:4940 [inline] netdev_start_xmit include/linux/netdevice.h:4954 [inline] xmit_one net/core/dev.c:3548 [inline] dev_hard_start_xmit+0x247/0xa10 net/core/dev.c:3564 __dev_queue_xmit+0x33b8/0x5130 net/core/dev.c:4349 dev_queue_xmit include/linux/netdevice.h:3134 [inline] packet_xmit+0x9c/0x6b0 net/packet/af_packet.c:276 packet_snd net/packet/af_packet.c:3087 [inline] packet_sendmsg+0x8b1d/0x9f30 net/packet/af_packet.c:3119 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline] __sys_sendto+0x735/0xa10 net/socket.c:2191 __do_sys_sendto net/socket.c:2203 [inline] __se_sys_sendto net/socket.c:2199 [inline] __x64_sys_sendto+0x125/0x1c0 net/socket.c:2199 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x6d/0x140 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b Uninit was created at: slab_post_alloc_hook+0x129/0xa70 mm/slab.h:768 slab_alloc_node mm/slub.c:3478 [inline] kmem_cache_alloc_node+0x5e9/0xb10 mm/slub.c:3523 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:560 __alloc_skb+0x318/0x740 net/core/skbuff.c:651 alloc_skb include/linux/skbuff.h:1286 [inline] alloc_skb_with_frags+0xc8/0xbd0 net/core/skbuff.c:6334 sock_alloc_send_pskb+0xa80/0xbf0 net/core/sock.c:2787 packet_alloc_skb net/packet/af_packet.c:2936 [inline] packet_snd net/packet/af_packet.c:3030 [inline] packet_sendmsg+0x70e8/0x9f30 net/packet/af_packet.c:3119 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline] __sys_sendto+0x735/0xa10 net/socket.c:2191 __do_sys_sendto net/socket.c:2203 [inline] __se_sys_sendto net/socket.c:2199 [inline] __x64_sys_sendto+0x125/0x1c0 net/socket.c:2199 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x6d/0x140 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b CPU: 1 PID: 5033 Comm: syz-executor334 Not tainted 6.7.0-syzkaller-00562-g9f8413c4a66f #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023 ===================================================== If the packet type ID field in the Ethernet header is either ETH_P_PRP or ETH_P_HSR, but it is not followed by an HSR tag, hsr_get_skb_sequence_nr() reads an invalid value as a sequence number. This causes the above issue. This patch fixes the issue by returning NULL if the Ethernet header is not followed by an HSR tag.
A flaw was found in the Linux kernel. A system error can be reliably replicated with specific filesystem settings, allowing an attacker to cause a denial of service.
In the Linux kernel, the following vulnerability has been resolved: RDMA/srpt: Do not register event handler until srpt device is fully setup Upon rare occasions, KASAN reports a use-after-free Write in srpt_refresh_port(). This seems to be because an event handler is registered before the srpt device is fully setup and a race condition upon error may leave a partially setup event handler in place. Instead, only register the event handler after srpt device initialization is complete.
In the Linux kernel, the following vulnerability has been resolved: quota: Fix potential NULL pointer dereference Below race may cause NULL pointer dereference P1 P2 dquot_free_inode quota_off drop_dquot_ref remove_dquot_ref dquots = i_dquot(inode) dquots = i_dquot(inode) srcu_read_lock dquots[cnt]) != NULL (1) dquots[type] = NULL (2) spin_lock(&dquots[cnt]->dq_dqb_lock) (3) .... If dquot_free_inode(or other routines) checks inode's quota pointers (1) before quota_off sets it to NULL(2) and use it (3) after that, NULL pointer dereference will be triggered. So let's fix it by using a temporary pointer to avoid this issue.
A flaw was found in the ip_tunnel implementation in the Linux kernel. This flaw occurs because the ip_tunnel_rcv() function does not properly pull the inner IP header before processing. A remote attacker could exploit this by sending crafted tunneled packets, potentially leading to a denial of service or incorrect packet handling. This impacts the integrity and availability of systems using IP tunneling.
A buffer overflow flaw was found in struct hci_dev_info in the variable name[8] in the Linkkux Kernel. If an attacker crafts an exploit copying more than the size of the name[8], it results in a buffer overflow and a denial of service.
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btrtl: fix out of bounds memory access The problem is detected by KASAN. btrtl driver uses private hci data to store 'struct btrealtek_data'. If btrtl driver is used with btusb, then memory for private hci data is allocated in btusb. But no private data is allocated after hci_dev, when btrtl is used with hci_h5. This commit adds memory allocation for hci_h5 case. ================================================================== BUG: KASAN: slab-out-of-bounds in btrtl_initialize+0x6cc/0x958 [btrtl] Write of size 8 at addr ffff00000f5a5748 by task kworker/u9:0/76 Hardware name: Pine64 PinePhone (1.2) (DT) Workqueue: hci0 hci_power_on [bluetooth] Call trace: dump_backtrace+0x9c/0x128 show_stack+0x20/0x38 dump_stack_lvl+0x48/0x60 print_report+0xf8/0x5d8 kasan_report+0x90/0xd0 __asan_store8+0x9c/0xc0 [btrtl] h5_btrtl_setup+0xd0/0x2f8 [hci_uart] h5_setup+0x50/0x80 [hci_uart] hci_uart_setup+0xd4/0x260 [hci_uart] hci_dev_open_sync+0x1cc/0xf68 [bluetooth] hci_dev_do_open+0x34/0x90 [bluetooth] hci_power_on+0xc4/0x3c8 [bluetooth] process_one_work+0x328/0x6f0 worker_thread+0x410/0x778 kthread+0x168/0x178 ret_from_fork+0x10/0x20 Allocated by task 53: kasan_save_stack+0x3c/0x68 kasan_save_track+0x20/0x40 kasan_save_alloc_info+0x68/0x78 __kasan_kmalloc+0xd4/0xd8 __kmalloc+0x1b4/0x3b0 hci_alloc_dev_priv+0x28/0xa58 [bluetooth] hci_uart_register_device+0x118/0x4f8 [hci_uart] h5_serdev_probe+0xf4/0x178 [hci_uart] serdev_drv_probe+0x54/0xa0 really_probe+0x254/0x588 __driver_probe_device+0xc4/0x210 driver_probe_device+0x64/0x160 __driver_attach_async_helper+0x88/0x158 async_run_entry_fn+0xd0/0x388 process_one_work+0x328/0x6f0 worker_thread+0x410/0x778 kthread+0x168/0x178 ret_from_fork+0x10/0x20 Last potentially related work creation: kasan_save_stack+0x3c/0x68 __kasan_record_aux_stack+0xb0/0x150 kasan_record_aux_stack_noalloc+0x14/0x20 __queue_work+0x33c/0x960 queue_work_on+0x98/0xc0 hci_recv_frame+0xc8/0x1e8 [bluetooth] h5_complete_rx_pkt+0x2c8/0x800 [hci_uart] h5_rx_payload+0x98/0xb8 [hci_uart] h5_recv+0x158/0x3d8 [hci_uart] hci_uart_receive_buf+0xa0/0xe8 [hci_uart] ttyport_receive_buf+0xac/0x178 flush_to_ldisc+0x130/0x2c8 process_one_work+0x328/0x6f0 worker_thread+0x410/0x778 kthread+0x168/0x178 ret_from_fork+0x10/0x20 Second to last potentially related work creation: kasan_save_stack+0x3c/0x68 __kasan_record_aux_stack+0xb0/0x150 kasan_record_aux_stack_noalloc+0x14/0x20 __queue_work+0x788/0x960 queue_work_on+0x98/0xc0 __hci_cmd_sync_sk+0x23c/0x7a0 [bluetooth] __hci_cmd_sync+0x24/0x38 [bluetooth] btrtl_initialize+0x760/0x958 [btrtl] h5_btrtl_setup+0xd0/0x2f8 [hci_uart] h5_setup+0x50/0x80 [hci_uart] hci_uart_setup+0xd4/0x260 [hci_uart] hci_dev_open_sync+0x1cc/0xf68 [bluetooth] hci_dev_do_open+0x34/0x90 [bluetooth] hci_power_on+0xc4/0x3c8 [bluetooth] process_one_work+0x328/0x6f0 worker_thread+0x410/0x778 kthread+0x168/0x178 ret_from_fork+0x10/0x20 ==================================================================
In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7921e: fix use-after-free in free_irq() From commit a304e1b82808 ("[PATCH] Debug shared irqs"), there is a test to make sure the shared irq handler should be able to handle the unexpected event after deregistration. For this case, let's apply MT76_REMOVED flag to indicate the device was removed and do not run into the resource access anymore. BUG: KASAN: use-after-free in mt7921_irq_handler+0xd8/0x100 [mt7921e] Read of size 8 at addr ffff88824a7d3b78 by task rmmod/11115 CPU: 28 PID: 11115 Comm: rmmod Tainted: G W L 5.17.0 #10 Hardware name: Micro-Star International Co., Ltd. MS-7D73/MPG B650I EDGE WIFI (MS-7D73), BIOS 1.81 01/05/2024 Call Trace: <TASK> dump_stack_lvl+0x6f/0xa0 print_address_description.constprop.0+0x1f/0x190 ? mt7921_irq_handler+0xd8/0x100 [mt7921e] ? mt7921_irq_handler+0xd8/0x100 [mt7921e] kasan_report.cold+0x7f/0x11b ? mt7921_irq_handler+0xd8/0x100 [mt7921e] mt7921_irq_handler+0xd8/0x100 [mt7921e] free_irq+0x627/0xaa0 devm_free_irq+0x94/0xd0 ? devm_request_any_context_irq+0x160/0x160 ? kobject_put+0x18d/0x4a0 mt7921_pci_remove+0x153/0x190 [mt7921e] pci_device_remove+0xa2/0x1d0 __device_release_driver+0x346/0x6e0 driver_detach+0x1ef/0x2c0 bus_remove_driver+0xe7/0x2d0 ? __check_object_size+0x57/0x310 pci_unregister_driver+0x26/0x250 __do_sys_delete_module+0x307/0x510 ? free_module+0x6a0/0x6a0 ? fpregs_assert_state_consistent+0x4b/0xb0 ? rcu_read_lock_sched_held+0x10/0x70 ? syscall_enter_from_user_mode+0x20/0x70 ? trace_hardirqs_on+0x1c/0x130 do_syscall_64+0x5c/0x80 ? trace_hardirqs_on_prepare+0x72/0x160 ? do_syscall_64+0x68/0x80 ? trace_hardirqs_on_prepare+0x72/0x160 entry_SYSCALL_64_after_hwframe+0x44/0xae
In the Linux kernel, the following vulnerability has been resolved: ACPI: processor_idle: Fix memory leak in acpi_processor_power_exit() After unregistering the CPU idle device, the memory associated with it is not freed, leading to a memory leak: unreferenced object 0xffff896282f6c000 (size 1024): comm "swapper/0", pid 1, jiffies 4294893170 hex dump (first 32 bytes): 00 00 00 00 0b 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace (crc 8836a742): [<ffffffff993495ed>] kmalloc_trace+0x29d/0x340 [<ffffffff9972f3b3>] acpi_processor_power_init+0xf3/0x1c0 [<ffffffff9972d263>] __acpi_processor_start+0xd3/0xf0 [<ffffffff9972d2bc>] acpi_processor_start+0x2c/0x50 [<ffffffff99805872>] really_probe+0xe2/0x480 [<ffffffff99805c98>] __driver_probe_device+0x78/0x160 [<ffffffff99805daf>] driver_probe_device+0x1f/0x90 [<ffffffff9980601e>] __driver_attach+0xce/0x1c0 [<ffffffff99803170>] bus_for_each_dev+0x70/0xc0 [<ffffffff99804822>] bus_add_driver+0x112/0x210 [<ffffffff99807245>] driver_register+0x55/0x100 [<ffffffff9aee4acb>] acpi_processor_driver_init+0x3b/0xc0 [<ffffffff990012d1>] do_one_initcall+0x41/0x300 [<ffffffff9ae7c4b0>] kernel_init_freeable+0x320/0x470 [<ffffffff99b231f6>] kernel_init+0x16/0x1b0 [<ffffffff99042e6d>] ret_from_fork+0x2d/0x50 Fix this by freeing the CPU idle device after unregistering it.
A flaw was found in the Linux kernel, where a deadlock can occur between bd_link_disk_holder and partition scan.
A memory leak flaw was found in rdev->serial in the Linux kernel. This issue may lead to a crash.
In the Linux kernel, the following vulnerability has been resolved: do_sys_name_to_handle(): use kzalloc() to fix kernel-infoleak syzbot identified a kernel information leak vulnerability in do_sys_name_to_handle() and issued the following report [1]. [1] "BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:114 [inline] BUG: KMSAN: kernel-infoleak in _copy_to_user+0xbc/0x100 lib/usercopy.c:40 instrument_copy_to_user include/linux/instrumented.h:114 [inline] _copy_to_user+0xbc/0x100 lib/usercopy.c:40 copy_to_user include/linux/uaccess.h:191 [inline] do_sys_name_to_handle fs/fhandle.c:73 [inline] __do_sys_name_to_handle_at fs/fhandle.c:112 [inline] __se_sys_name_to_handle_at+0x949/0xb10 fs/fhandle.c:94 __x64_sys_name_to_handle_at+0xe4/0x140 fs/fhandle.c:94 ... Uninit was created at: slab_post_alloc_hook+0x129/0xa70 mm/slab.h:768 slab_alloc_node mm/slub.c:3478 [inline] __kmem_cache_alloc_node+0x5c9/0x970 mm/slub.c:3517 __do_kmalloc_node mm/slab_common.c:1006 [inline] __kmalloc+0x121/0x3c0 mm/slab_common.c:1020 kmalloc include/linux/slab.h:604 [inline] do_sys_name_to_handle fs/fhandle.c:39 [inline] __do_sys_name_to_handle_at fs/fhandle.c:112 [inline] __se_sys_name_to_handle_at+0x441/0xb10 fs/fhandle.c:94 __x64_sys_name_to_handle_at+0xe4/0x140 fs/fhandle.c:94 ... Bytes 18-19 of 20 are uninitialized Memory access of size 20 starts at ffff888128a46380 Data copied to user address 0000000020000240" Per Chuck Lever's suggestion, use kzalloc() instead of kmalloc() to solve the problem.
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: rfcomm: Fix null-ptr-deref in rfcomm_check_security The Linux kernel CVE team has assigned CVE-2024-26903 to this issue. Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024041745-CVE-2024-26903-de5c@gregkh/T
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 flaw was found in the Linux kernel. The IH OVERFLOW_CLEAR bit was not reset.
In the Linux kernel, the following vulnerability has been resolved: tracing/trigger: Fix to return error if failed to alloc snapshot Fix register_snapshot_trigger() to return error code if it failed to allocate a snapshot instead of 0 (success). Unless that, it will register snapshot trigger without an error.
In the Linux kernel, the following vulnerability has been resolved: inet: inet_defrag: prevent sk release while still in use ip_local_out() and other functions can pass skb->sk as function argument. If the skb is a fragment and reassembly happens before such function call returns, the sk must not be released. This affects skb fragments reassembled via netfilter or similar modules, e.g. openvswitch or ct_act.c, when run as part of tx pipeline. Eric Dumazet made an initial analysis of this bug. Quoting Eric: Calling ip_defrag() in output path is also implying skb_orphan(), which is buggy because output path relies on sk not disappearing. A relevant old patch about the issue was : 8282f27449bf ("inet: frag: Always orphan skbs inside ip_defrag()") [..] net/ipv4/ip_output.c depends on skb->sk being set, and probably to an inet socket, not an arbitrary one. If we orphan the packet in ipvlan, then downstream things like FQ packet scheduler will not work properly. We need to change ip_defrag() to only use skb_orphan() when really needed, ie whenever frag_list is going to be used. Eric suggested to stash sk in fragment queue and made an initial patch. However there is a problem with this: If skb is refragmented again right after, ip_do_fragment() will copy head->sk to the new fragments, and sets up destructor to sock_wfree. IOW, we have no choice but to fix up sk_wmem accouting to reflect the fully reassembled skb, else wmem will underflow. This change moves the orphan down into the core, to last possible moment. As ip_defrag_offset is aliased with sk_buff->sk member, we must move the offset into the FRAG_CB, else skb->sk gets clobbered. This allows to delay the orphaning long enough to learn if the skb has to be queued or if the skb is completing the reasm queue. In the former case, things work as before, skb is orphaned. This is safe because skb gets queued/stolen and won't continue past reasm engine. In the latter case, we will steal the skb->sk reference, reattach it to the head skb, and fix up wmem accouting when inet_frag inflates truesize.
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: validate the parameters of bo mapping operations more clearly Verify the parameters of amdgpu_vm_bo_(map/replace_map/clearing_mappings) in one common place.
In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_set_pipapo: do not free live element The Linux kernel CVE team has assigned CVE-2024-26924 to this issue. Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024042420-CVE-2024-26924-4d1e@gregkh/T
A flaw was found in the Linux kernel. The following vulnerability has been resolved: ASoC: SOF: Add some bounds checking to firmware data.
A flaw was found in the Linux kernel. The following vulnerability has been resolved: smb: client: fix potential UAF in cifs_debug_files_proc_show().
In the Linux kernel, the following vulnerability has been resolved: USB: core: Fix deadlock in port "disable" sysfs attribute The Linux kernel CVE team has assigned CVE-2024-26933 to this issue. Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024050123-CVE-2024-26933-c18d@gregkh/T
In the Linux kernel, the following vulnerability has been resolved: USB: core: Fix deadlock in usb_deauthorize_interface() The Linux kernel CVE team has assigned CVE-2024-26934 to this issue. Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024050123-CVE-2024-26934-e2fc@gregkh/T
A flaw was found in the i915 module in the Linux kernel. Under some conditions, an assertion failure can be triggered and cause a denial of service.
In the Linux kernel, the following vulnerability has been resolved: drm/i915/bios: Tolerate devdata==NULL in intel_bios_encoder_supports_dp_dual_mode() The Linux kernel CVE team has assigned CVE-2024-26938 to this issue. Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024050124-CVE-2024-26938-b3f9@gregkh/T
A use-after-free flaw was found in drivers/gpu/drm/i915/i915_vma.c in the Linux kernel that may lead to a crash.
A flaw was found in the vmwgfx module in the Linux kernel. Trying to read the /sys/kernel/debug/dri/0/mob_ttm file when the ttm_resource_manager is not allocated will cause a crash, resulting in a denial of service.
In the Linux kernel, the following vulnerability has been resolved: wireguard: netlink: access device through ctx instead of peer The previous commit fixed a bug that led to a NULL peer->device being dereferenced. It's actually easier and faster performance-wise to instead get the device from ctx->wg. This semantically makes more sense too, since ctx->wg->peer_allowedips.seq is compared with ctx->allowedips_seq, basing them both in ctx. This also acts as a defence in depth provision against freed peers.
In the Linux kernel, the following vulnerability has been resolved: wireguard: netlink: check for dangling peer via is_dead instead of empty list If all peers are removed via wg_peer_remove_all(), rather than setting peer_list to empty, the peer is added to a temporary list with a head on the stack of wg_peer_remove_all(). If a netlink dump is resumed and the cursored peer is one that has been removed via wg_peer_remove_all(), it will iterate from that peer and then attempt to dump freed peers. Fix this by instead checking peer->is_dead, which was explictly created for this purpose. Also move up the device_update_lock lockdep assertion, since reading is_dead relies on that. It can be reproduced by a small script like: echo "Setting config..." ip link add dev wg0 type wireguard wg setconf wg0 /big-config ( while true; do echo "Showing config..." wg showconf wg0 > /dev/null done ) & sleep 4 wg setconf wg0 <(printf "[Peer]\nPublicKey=$(wg genkey)\n") Resulting in: BUG: KASAN: slab-use-after-free in __lock_acquire+0x182a/0x1b20 Read of size 8 at addr ffff88811956ec70 by task wg/59 CPU: 2 PID: 59 Comm: wg Not tainted 6.8.0-rc2-debug+ #5 Call Trace: <TASK> dump_stack_lvl+0x47/0x70 print_address_description.constprop.0+0x2c/0x380 print_report+0xab/0x250 kasan_report+0xba/0xf0 __lock_acquire+0x182a/0x1b20 lock_acquire+0x191/0x4b0 down_read+0x80/0x440 get_peer+0x140/0xcb0 wg_get_device_dump+0x471/0x1130
In the Linux kernel, the following vulnerability has been resolved: net: esp: fix bad handling of pages from page_pool When the skb is reorganized during esp_output (!esp->inline), the pages coming from the original skb fragments are supposed to be released back to the system through put_page. But if the skb fragment pages are originating from a page_pool, calling put_page on them will trigger a page_pool leak which will eventually result in a crash. This leak can be easily observed when using CONFIG_DEBUG_VM and doing ipsec + gre (non offloaded) forwarding: BUG: Bad page state in process ksoftirqd/16 pfn:1451b6 page:00000000de2b8d32 refcount:0 mapcount:0 mapping:0000000000000000 index:0x1451b6000 pfn:0x1451b6 flags: 0x200000000000000(node=0|zone=2) page_type: 0xffffffff() raw: 0200000000000000 dead000000000040 ffff88810d23c000 0000000000000000 raw: 00000001451b6000 0000000000000001 00000000ffffffff 0000000000000000 page dumped because: page_pool leak Modules linked in: ip_gre gre mlx5_ib mlx5_core xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink iptable_nat nf_nat xt_addrtype br_netfilter rpcrdma rdma_ucm ib_iser libiscsi scsi_transport_iscsi ib_umad rdma_cm ib_ipoib iw_cm ib_cm ib_uverbs ib_core overlay zram zsmalloc fuse [last unloaded: mlx5_core] CPU: 16 PID: 96 Comm: ksoftirqd/16 Not tainted 6.8.0-rc4+ #22 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x36/0x50 bad_page+0x70/0xf0 free_unref_page_prepare+0x27a/0x460 free_unref_page+0x38/0x120 esp_ssg_unref.isra.0+0x15f/0x200 esp_output_tail+0x66d/0x780 esp_xmit+0x2c5/0x360 validate_xmit_xfrm+0x313/0x370 ? validate_xmit_skb+0x1d/0x330 validate_xmit_skb_list+0x4c/0x70 sch_direct_xmit+0x23e/0x350 __dev_queue_xmit+0x337/0xba0 ? nf_hook_slow+0x3f/0xd0 ip_finish_output2+0x25e/0x580 iptunnel_xmit+0x19b/0x240 ip_tunnel_xmit+0x5fb/0xb60 ipgre_xmit+0x14d/0x280 [ip_gre] dev_hard_start_xmit+0xc3/0x1c0 __dev_queue_xmit+0x208/0xba0 ? nf_hook_slow+0x3f/0xd0 ip_finish_output2+0x1ca/0x580 ip_sublist_rcv_finish+0x32/0x40 ip_sublist_rcv+0x1b2/0x1f0 ? ip_rcv_finish_core.constprop.0+0x460/0x460 ip_list_rcv+0x103/0x130 __netif_receive_skb_list_core+0x181/0x1e0 netif_receive_skb_list_internal+0x1b3/0x2c0 napi_gro_receive+0xc8/0x200 gro_cell_poll+0x52/0x90 __napi_poll+0x25/0x1a0 net_rx_action+0x28e/0x300 __do_softirq+0xc3/0x276 ? sort_range+0x20/0x20 run_ksoftirqd+0x1e/0x30 smpboot_thread_fn+0xa6/0x130 kthread+0xcd/0x100 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x31/0x50 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork_asm+0x11/0x20 </TASK> The suggested fix is to introduce a new wrapper (skb_page_unref) that covers page refcounting for page_pool pages as well.
A use-after-free flaw was found in fs/nfs/direct.c in the Linux kernel. This may lead to a crash.
In the Linux kernel, the following vulnerability has been resolved: mm: swap: fix race between free_swap_and_cache() and swapoff() The Linux kernel CVE team has assigned CVE-2024-26960 to this issue. Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024050129-CVE-2024-26960-ad6b@gregkh/T
In the Linux kernel, the following vulnerability has been resolved: dm-raid456, md/raid456: fix a deadlock for dm-raid456 while io concurrent with reshape For raid456, if reshape is still in progress, then IO across reshape position will wait for reshape to make progress. However, for dm-raid, in following cases reshape will never make progress hence IO will hang: 1) the array is read-only; 2) MD_RECOVERY_WAIT is set; 3) MD_RECOVERY_FROZEN is set; After commit c467e97f079f ("md/raid6: use valid sector values to determine if an I/O should wait on the reshape") fix the problem that IO across reshape position doesn't wait for reshape, the dm-raid test shell/lvconvert-raid-reshape.sh start to hang: [root@fedora ~]# cat /proc/979/stack [<0>] wait_woken+0x7d/0x90 [<0>] raid5_make_request+0x929/0x1d70 [raid456] [<0>] md_handle_request+0xc2/0x3b0 [md_mod] [<0>] raid_map+0x2c/0x50 [dm_raid] [<0>] __map_bio+0x251/0x380 [dm_mod] [<0>] dm_submit_bio+0x1f0/0x760 [dm_mod] [<0>] __submit_bio+0xc2/0x1c0 [<0>] submit_bio_noacct_nocheck+0x17f/0x450 [<0>] submit_bio_noacct+0x2bc/0x780 [<0>] submit_bio+0x70/0xc0 [<0>] mpage_readahead+0x169/0x1f0 [<0>] blkdev_readahead+0x18/0x30 [<0>] read_pages+0x7c/0x3b0 [<0>] page_cache_ra_unbounded+0x1ab/0x280 [<0>] force_page_cache_ra+0x9e/0x130 [<0>] page_cache_sync_ra+0x3b/0x110 [<0>] filemap_get_pages+0x143/0xa30 [<0>] filemap_read+0xdc/0x4b0 [<0>] blkdev_read_iter+0x75/0x200 [<0>] vfs_read+0x272/0x460 [<0>] ksys_read+0x7a/0x170 [<0>] __x64_sys_read+0x1c/0x30 [<0>] do_syscall_64+0xc6/0x230 [<0>] entry_SYSCALL_64_after_hwframe+0x6c/0x74 This is because reshape can't make progress. For md/raid, the problem doesn't exist because register new sync_thread doesn't rely on the IO to be done any more: 1) If array is read-only, it can switch to read-write by ioctl/sysfs; 2) md/raid never set MD_RECOVERY_WAIT; 3) If MD_RECOVERY_FROZEN is set, mddev_suspend() doesn't hold 'reconfig_mutex', hence it can be cleared and reshape can continue by sysfs api 'sync_action'. However, I'm not sure yet how to avoid the problem in dm-raid yet. This patch on the one hand make sure raid_message() can't change sync_thread() through raid_message() after presuspend(), on the other hand detect the above 3 cases before wait for IO do be done in dm_suspend(), and let dm-raid requeue those IO.
In the Linux kernel, the following vulnerability has been resolved: usb: xhci: Add error handling in xhci_map_urb_for_dma The Linux kernel CVE team has assigned CVE-2024-26964 to this issue. Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024050130-CVE-2024-26964-54c8@gregkh/T
In the Linux kernel, the following vulnerability has been resolved: fat: fix uninitialized field in nostale filehandles The Linux kernel CVE team has assigned CVE-2024-26973 to this issue. Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024050132-CVE-2024-26973-54a3@gregkh/T
In the Linux kernel, the following vulnerability has been resolved: powercap: intel_rapl: Fix a NULL pointer dereference The Linux kernel CVE team has assigned CVE-2024-26975 to this issue. Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024050133-CVE-2024-26975-d184@gregkh/T
In the Linux kernel, the following vulnerability has been resolved: KVM: Always flush async #PF workqueue when vCPU is being destroyed Always flush the per-vCPU async #PF workqueue when a vCPU is clearing its completion queue, e.g. when a VM and all its vCPUs is being destroyed. KVM must ensure that none of its workqueue callbacks is running when the last reference to the KVM _module_ is put. Gifting a reference to the associated VM prevents the workqueue callback from dereferencing freed vCPU/VM memory, but does not prevent the KVM module from being unloaded before the callback completes. Drop the misguided VM refcount gifting, as calling kvm_put_kvm() from async_pf_execute() if kvm_put_kvm() flushes the async #PF workqueue will result in deadlock. async_pf_execute() can't return until kvm_put_kvm() finishes, and kvm_put_kvm() can't return until async_pf_execute() finishes: WARNING: CPU: 8 PID: 251 at virt/kvm/kvm_main.c:1435 kvm_put_kvm+0x2d/0x320 [kvm] Modules linked in: vhost_net vhost vhost_iotlb tap kvm_intel kvm irqbypass CPU: 8 PID: 251 Comm: kworker/8:1 Tainted: G W 6.6.0-rc1-e7af8d17224a-x86/gmem-vm #119 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 Workqueue: events async_pf_execute [kvm] RIP: 0010:kvm_put_kvm+0x2d/0x320 [kvm] Call Trace: <TASK> async_pf_execute+0x198/0x260 [kvm] process_one_work+0x145/0x2d0 worker_thread+0x27e/0x3a0 kthread+0xba/0xe0 ret_from_fork+0x2d/0x50 ret_from_fork_asm+0x11/0x20 </TASK> ---[ end trace 0000000000000000 ]--- INFO: task kworker/8:1:251 blocked for more than 120 seconds. Tainted: G W 6.6.0-rc1-e7af8d17224a-x86/gmem-vm #119 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:kworker/8:1 state:D stack:0 pid:251 ppid:2 flags:0x00004000 Workqueue: events async_pf_execute [kvm] Call Trace: <TASK> __schedule+0x33f/0xa40 schedule+0x53/0xc0 schedule_timeout+0x12a/0x140 __wait_for_common+0x8d/0x1d0 __flush_work.isra.0+0x19f/0x2c0 kvm_clear_async_pf_completion_queue+0x129/0x190 [kvm] kvm_arch_destroy_vm+0x78/0x1b0 [kvm] kvm_put_kvm+0x1c1/0x320 [kvm] async_pf_execute+0x198/0x260 [kvm] process_one_work+0x145/0x2d0 worker_thread+0x27e/0x3a0 kthread+0xba/0xe0 ret_from_fork+0x2d/0x50 ret_from_fork_asm+0x11/0x20 </TASK> If kvm_clear_async_pf_completion_queue() actually flushes the workqueue, then there's no need to gift async_pf_execute() a reference because all invocations of async_pf_execute() will be forced to complete before the vCPU and its VM are destroyed/freed. And that in turn fixes the module unloading bug as __fput() won't do module_put() on the last vCPU reference until the vCPU has been freed, e.g. if closing the vCPU file also puts the last reference to the KVM module. Note that kvm_check_async_pf_completion() may also take the work item off the completion queue and so also needs to flush the work queue, as the work will not be seen by kvm_clear_async_pf_completion_queue(). Waiting on the workqueue could theoretically delay a vCPU due to waiting for the work to complete, but that's a very, very small chance, and likely a very small delay. kvm_arch_async_page_present_queued() unconditionally makes a new request, i.e. will effectively delay entering the guest, so the remaining work is really just: trace_kvm_async_pf_completed(addr, cr2_or_gpa); __kvm_vcpu_wake_up(vcpu); mmput(mm); and mmput() can't drop the last reference to the page tables if the vCPU is still alive, i.e. the vCPU won't get stuck tearing down page tables. Add a helper to do the flushing, specifically to deal with "wakeup all" work items, as they aren't actually work items, i.e. are never placed in a workqueue. Trying to flush a bogus workqueue entry rightly makes __flush_work() complain (kudos to whoever added that sanity check). Note, commit 5f6de5cbebee ("KVM: Prevent module exit until al ---truncated---
A flaw was found in the nouveau module in the Linux kernel. In some conditions, a race condition can cause a NULL pointer dereference, resulting in a denial of service.
In the Linux kernel, the following vulnerability has been resolved: mm/memory-failure: fix deadlock when hugetlb_optimize_vmemmap is enabled The Linux kernel CVE team has assigned CVE-2024-26987 to this issue. Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024050143-CVE-2024-26987-507c@gregkh/T
A static_command_line memory overflow was found in the Linux kernel. This issue may cause a crash.
In the Linux kernel, the following vulnerability has been resolved: arm64: hibernate: Fix level3 translation fault in swsusp_save() The Linux kernel CVE team has assigned CVE-2024-26989 to this issue. Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024050143-CVE-2024-26989-851d@gregkh/T
In the Linux kernel, the following vulnerability has been resolved: KVM: x86/mmu: Write-protect L2 SPTEs in TDP MMU when clearing dirty status The Linux kernel CVE team has assigned CVE-2024-26990 to this issue. Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024050143-CVE-2024-26990-0a1f@gregkh/T
In the Linux kernel, the following vulnerability has been resolved: KVM: x86/pmu: Disable support for adaptive PEBS The Linux kernel CVE team has assigned CVE-2024-26992 to this issue. Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024050144-CVE-2024-26992-4f0e@gregkh/T
In the Linux kernel, the following vulnerability has been resolved: clk: Get runtime PM before walking tree for clk_summary The Linux kernel CVE team has assigned CVE-2024-27003 to this issue. Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024050146-CVE-2024-27003-c862@gregkh/T
In the Linux kernel, the following vulnerability has been resolved: clk: Get runtime PM before walking tree during disable_unused Doug reported [1] the following hung task: INFO: task swapper/0:1 blocked for more than 122 seconds. Not tainted 5.15.149-21875-gf795ebc40eb8 #1 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:swapper/0 state:D stack: 0 pid: 1 ppid: 0 flags:0x00000008 Call trace: __switch_to+0xf4/0x1f4 __schedule+0x418/0xb80 schedule+0x5c/0x10c rpm_resume+0xe0/0x52c rpm_resume+0x178/0x52c __pm_runtime_resume+0x58/0x98 clk_pm_runtime_get+0x30/0xb0 clk_disable_unused_subtree+0x58/0x208 clk_disable_unused_subtree+0x38/0x208 clk_disable_unused_subtree+0x38/0x208 clk_disable_unused_subtree+0x38/0x208 clk_disable_unused_subtree+0x38/0x208 clk_disable_unused+0x4c/0xe4 do_one_initcall+0xcc/0x2d8 do_initcall_level+0xa4/0x148 do_initcalls+0x5c/0x9c do_basic_setup+0x24/0x30 kernel_init_freeable+0xec/0x164 kernel_init+0x28/0x120 ret_from_fork+0x10/0x20 INFO: task kworker/u16:0:9 blocked for more than 122 seconds. Not tainted 5.15.149-21875-gf795ebc40eb8 #1 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:kworker/u16:0 state:D stack: 0 pid: 9 ppid: 2 flags:0x00000008 Workqueue: events_unbound deferred_probe_work_func Call trace: __switch_to+0xf4/0x1f4 __schedule+0x418/0xb80 schedule+0x5c/0x10c schedule_preempt_disabled+0x2c/0x48 __mutex_lock+0x238/0x488 __mutex_lock_slowpath+0x1c/0x28 mutex_lock+0x50/0x74 clk_prepare_lock+0x7c/0x9c clk_core_prepare_lock+0x20/0x44 clk_prepare+0x24/0x30 clk_bulk_prepare+0x40/0xb0 mdss_runtime_resume+0x54/0x1c8 pm_generic_runtime_resume+0x30/0x44 __genpd_runtime_resume+0x68/0x7c genpd_runtime_resume+0x108/0x1f4 __rpm_callback+0x84/0x144 rpm_callback+0x30/0x88 rpm_resume+0x1f4/0x52c rpm_resume+0x178/0x52c __pm_runtime_resume+0x58/0x98 __device_attach+0xe0/0x170 device_initial_probe+0x1c/0x28 bus_probe_device+0x3c/0x9c device_add+0x644/0x814 mipi_dsi_device_register_full+0xe4/0x170 devm_mipi_dsi_device_register_full+0x28/0x70 ti_sn_bridge_probe+0x1dc/0x2c0 auxiliary_bus_probe+0x4c/0x94 really_probe+0xcc/0x2c8 __driver_probe_device+0xa8/0x130 driver_probe_device+0x48/0x110 __device_attach_driver+0xa4/0xcc bus_for_each_drv+0x8c/0xd8 __device_attach+0xf8/0x170 device_initial_probe+0x1c/0x28 bus_probe_device+0x3c/0x9c deferred_probe_work_func+0x9c/0xd8 process_one_work+0x148/0x518 worker_thread+0x138/0x350 kthread+0x138/0x1e0 ret_from_fork+0x10/0x20 The first thread is walking the clk tree and calling clk_pm_runtime_get() to power on devices required to read the clk hardware via struct clk_ops::is_enabled(). This thread holds the clk prepare_lock, and is trying to runtime PM resume a device, when it finds that the device is in the process of resuming so the thread schedule()s away waiting for the device to finish resuming before continuing. The second thread is runtime PM resuming the same device, but the runtime resume callback is calling clk_prepare(), trying to grab the prepare_lock waiting on the first thread. This is a classic ABBA deadlock. To properly fix the deadlock, we must never runtime PM resume or suspend a device with the clk prepare_lock held. Actually doing that is near impossible today because the global prepare_lock would have to be dropped in the middle of the tree, the device runtime PM resumed/suspended, and then the prepare_lock grabbed again to ensure consistency of the clk tree topology. If anything changes with the clk tree in the meantime, we've lost and will need to start the operation all over again. Luckily, most of the time we're simply incrementing or decrementing the runtime PM count on an active device, so we don't have the chance to schedule away with the prepare_lock held. Let's fix this immediate problem that can be ---truncated---
In the Linux kernel, the following vulnerability has been resolved: net/sched: Fix mirred deadlock on device recursion The Linux kernel CVE team has assigned CVE-2024-27010 to this issue. Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024050148-CVE-2024-27010-5a68@gregkh/T
In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: fix memleak in map from abort path The Linux kernel CVE team has assigned CVE-2024-27011 to this issue. Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024050148-CVE-2024-27011-2c70@gregkh/T
In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: restore set elements when delete set fails The Linux kernel CVE team has assigned CVE-2024-27012 to this issue. Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024050148-CVE-2024-27012-5564@gregkh/T
In the Linux kernel, the following vulnerability has been resolved: tun: limit printing rate when illegal packet received by tun dev The Linux kernel CVE team has assigned CVE-2024-27013 to this issue. Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024050149-CVE-2024-27013-2c26@gregkh/T
A flaw was found in the Linus Kernel. A potential deadlock can occur while disabling aRFS in drivers/net/ethernet/mellanox/mlx5/core/en_arfs.c.
In the Linux kernel, the following vulnerability has been resolved: netfilter: flowtable: incorrect pppoe tuple pppoe traffic reaching ingress path does not match the flowtable entry because the pppoe header is expected to be at the network header offset. This bug causes a mismatch in the flow table lookup, so pppoe packets enter the classical forwarding path.
In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_set_pipapo: walk over current view on netlink dump The Linux kernel CVE team has assigned CVE-2024-27017 to this issue. Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024050150-CVE-2024-27017-d867@gregkh/T
In the Linux kernel, the following vulnerability has been resolved: md: Fix missing release of 'active_io' for flush The Linux kernel CVE team has assigned CVE-2024-27023 to this issue. Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024050105-CVE-2024-27023-4810@gregkh/T
In the Linux kernel, the following vulnerability has been resolved: nbd: null check for nla_nest_start The Linux kernel CVE team has assigned CVE-2024-27025 to this issue. Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024050107-CVE-2024-27025-babd@gregkh/T
In the Linux kernel, the following vulnerability has been resolved: clk: Fix clk_core_get NULL dereference It is possible for clk_core_get to dereference a NULL in the following sequence: clk_core_get() of_clk_get_hw_from_clkspec() __of_clk_get_hw_from_provider() __clk_get_hw() __clk_get_hw() can return NULL which is dereferenced by clk_core_get() at hw->core. Prior to commit dde4eff47c82 ("clk: Look for parents with clkdev based clk_lookups") the check IS_ERR_OR_NULL() was performed which would have caught the NULL. Reading the description of this function it talks about returning NULL but that cannot be so at the moment. Update the function to check for hw before dereferencing it and return NULL if hw is NULL.
An out-of-bounds access flaw was found in drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c in the Linux kernel. This issue may lead to a crash.
A vulnerability was found in the Linux kernel's Wi-Fi cfg80211.c driver, where a lack of proper checks can result in a NULL pointer dereference. This issue occurs when the brcmf_pmksa_v3_op() function attempts to call malloc (), but the physical memory has run out. In this situation, kzalloc() will return NULL, which the function does not check before using it in the corresponding value pmk_op., possibly leading to system instability.
In the Linux kernel, the following vulnerability has been resolved: ASoC: SOF: ipc4-pcm: Workaround for crashed firmware on system suspend The Linux kernel CVE team has assigned CVE-2024-27057 to this issue. Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024050116-CVE-2024-27057-c0fb@gregkh/T
A flaw was found in the nouveau module in the Linux kernel. A missing resource lock can cause a race condition and trigger a general protection fault, resulting in a denial of service.
In the Linux kernel, the following vulnerability has been resolved: iommu/vt-d: Fix NULL domain on device release The Linux kernel CVE team has assigned CVE-2024-27079 to this issue. Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024050134-CVE-2024-27079-f478@gregkh/T
In the Linux kernel, the following vulnerability has been resolved: pstore: inode: Only d_invalidate() is needed The Linux kernel CVE team has assigned CVE-2024-27389 to this issue. Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024050135-CVE-2024-27389-fb3a@gregkh/T
In the Linux kernel, the following vulnerability has been resolved: net: openvswitch: Fix Use-After-Free in ovs_ct_exit The Linux kernel CVE team has assigned CVE-2024-27395 to this issue. Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024050836-CVE-2024-27395-573e@gregkh/T
A race condition vulnerability was found in the Linux kernel remote_id function. Successful exploitation of the flaw can result in loss of system availability.
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.
In the Linux kernel, the following vulnerability has been resolved: rtnetlink: fix error logic of IFLA_BRIDGE_FLAGS writing back The Linux kernel CVE team has assigned CVE-2024-27414 to this issue. Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024051702-CVE-2024-27414-5c5d@gregkh/T
In the Linux kernel, the following vulnerability has been resolved: cpumap: Zero-initialise xdp_rxq_info struct before running XDP program The Linux kernel CVE team has assigned CVE-2024-27431 to this issue. Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024051723-CVE-2024-27431-30ae@gregkh/T
In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: Stop parsing channels bits when all channels are found. The Linux kernel CVE team has assigned CVE-2024-27436 to this issue. Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024051711-CVE-2024-27436-2227@gregkh/T
An incorrect handling flaw was found in the Linux kernel framework for secure userspace device drivers functionality that may interrupt some of the devices. This issue could allow a local user to crash the system.
In the Linux kernel, the following vulnerability has been resolved: genirq/cpuhotplug, x86/vector: Prevent vector leak during CPU offline The absence of IRQD_MOVE_PCNTXT prevents immediate effectiveness of interrupt affinity reconfiguration via procfs. Instead, the change is deferred until the next instance of the interrupt being triggered on the original CPU. When the interrupt next triggers on the original CPU, the new affinity is enforced within __irq_move_irq(). A vector is allocated from the new CPU, but the old vector on the original CPU remains and is not immediately reclaimed. Instead, apicd->move_in_progress is flagged, and the reclaiming process is delayed until the next trigger of the interrupt on the new CPU. Upon the subsequent triggering of the interrupt on the new CPU, irq_complete_move() adds a task to the old CPU's vector_cleanup list if it remains online. Subsequently, the timer on the old CPU iterates over its vector_cleanup list, reclaiming old vectors. However, a rare scenario arises if the old CPU is outgoing before the interrupt triggers again on the new CPU. In that case irq_force_complete_move() is not invoked on the outgoing CPU to reclaim the old apicd->prev_vector because the interrupt isn't currently affine to the outgoing CPU, and irq_needs_fixup() returns false. Even though __vector_schedule_cleanup() is later called on the new CPU, it doesn't reclaim apicd->prev_vector; instead, it simply resets both apicd->move_in_progress and apicd->prev_vector to 0. As a result, the vector remains unreclaimed in vector_matrix, leading to a CPU vector leak. To address this issue, move the invocation of irq_force_complete_move() before the irq_needs_fixup() call to reclaim apicd->prev_vector, if the interrupt is currently or used to be affine to the outgoing CPU. Additionally, reclaim the vector in __vector_schedule_cleanup() as well, following a warning message, although theoretically it should never see apicd->move_in_progress with apicd->prev_cpu pointing to an offline CPU.
A security vulnerability was identified in the Linux kernel's MD (Multiple Device) subsystem, specifically within the bitmap handling code for clustered environments. The issue arises from incorrect usage of the sb_index field, leading to potential system crashes in clustered configurations.
A hang flaw was found in the Linux kernel’s Raid (MD) subsystem. This flaw allows a local user to crash the system.
A flaw was found in the `drm/amdgpu` subsystem in the Linux kernel, involving a deadlock occurring when reading the Memory Queue Descriptor (MQD) from `debugfs`. This issue could cause the system to hang during debug operations.
In the Linux kernel, the following vulnerability has been resolved: x86/fpu: Keep xfd_state in sync with MSR_IA32_XFD The Linux kernel CVE team has assigned CVE-2024-35801 to this issue. Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024051738-CVE-2024-35801-8038@gregkh/T
In the Linux kernel, the following vulnerability has been resolved: dm snapshot: fix lockup in dm_exception_table_exit The Linux kernel CVE team has assigned CVE-2024-35805 to this issue. Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024051739-CVE-2024-35805-179f@gregkh/T
A vulnerability was found in the ext4 filesystem in the Linux kernel during on-line resizing operations. When an ext4 filesystem is resized while mounted, it could lead to data corruption.
A flaw was found in the `md/dm-raid` subsystem in the Linux kernel. If `md_reap_sync_thread()` is called directly, it could lead to potential misuse or system instability.
A vulnerability was found in the PCI subsystem in the Linux kernel, where runtime-idle callbacks are not always drained before a PCI driver is removed. If these callbacks are still active when the driver is removed, it could result in system instability or crashes.
A vulnerability was found in the drm/vmwgfx driver in the Linux kernel, concerning the lifetime management of the buffer object (BO) cursor memory. This issue occurs due to improper handling of the cursor memory's lifecycle, which could lead to use-after-free errors or crashes.
No description is available for this CVE.
In the Linux kernel, the following vulnerability has been resolved: swiotlb: Fix double-allocation of slots due to broken alignment handling The Linux kernel CVE team has assigned CVE-2024-35814 to this issue. Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024051742-CVE-2024-35814-98c7@gregkh/T
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: amdgpu_ttm_gart_bind set gtt bound flag The Linux kernel CVE team has assigned CVE-2024-35817 to this issue. Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024051743-CVE-2024-35817-d29b@gregkh/T
In the Linux kernel, the following vulnerability has been resolved: usb: udc: remove warning when queue disabled ep The Linux kernel CVE team has assigned CVE-2024-35822 to this issue. Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024051744-CVE-2024-35822-410b@gregkh/T
A vulnerability was found in the `lis3lv02d_i2c` driver in the Linux kernel. This issue involves regulators being enabled and disabled twice during the suspend and resume process, which could lead to unintended behavior or system instability.
In the Linux kernel, the following vulnerability has been resolved: io_uring/net: fix overflow check in io_recvmsg_mshot_prep() The Linux kernel CVE team has assigned CVE-2024-35827 to this issue. Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024051741-CVE-2024-35827-822c@gregkh/T
A flaw was found in the `io_uring` subsystem in the Linux kernel, where pinned pages are not properly released if the `__io_uaddr_map` function fails. This could lead to resource leaks or other unintended behaviors.
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.
CVE-2024-35840 is a vulnerability in the Linux kernel’s Multipath TCP (MPTCP) implementation. It occurs because the subflow_finish_connect() function may handle uninitialized data in certain fields if a specific MPTCP option (OPTION_MPTCP_MPJ_SYNACK) is not correctly set during option parsing. This could lead to unpredictable behavior in MPTCP connections. The issue has been resolved by ensuring proper initialization and handling of these fields.
In the Linux kernel, the following vulnerability has been resolved: iommu/vt-d: Use device rbtree in iopf reporting path The Linux kernel CVE team has assigned CVE-2024-35843 to this issue. Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024051717-CVE-2024-35843-516e@gregkh/T
In the Linux kernel, the following vulnerability has been resolved: irqchip/gic-v3-its: Prevent double free on error The Linux kernel CVE team has assigned CVE-2024-35847 to this issue. Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024051738-CVE-2024-35847-7e4b@gregkh/T
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: block: fix module reference leakage from bdev_open_by_dev error path The Linux kernel CVE team has assigned CVE-2024-35859 to this issue. Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024051742-CVE-2024-35859-23c9@gregkh/T
In the Linux kernel, the following vulnerability has been resolved: smb: client: fix potential UAF in cifs_signal_cifsd_for_reconnect() Skip sessions that are being teared down (status == SES_EXITING) to avoid UAF.
A use-after-free flaw was found in the Linux kernel in smb smb2_is_network_name_deleted() when exiting a session. This flaw allows a local attacker to crash the system.
A use-after-free flaw was found in the Linux kernel in smb is_valid_oplock_break() when exiting a session. This flaw allows a local attacker to crash the system.
A use-after-free flaw was found in the Linux kernel in smb smb2_is_valid_lease_break() when exiting a session. This flaw allows a local attacker to crash the system.
In the Linux kernel, the following vulnerability has been resolved: smb: client: fix potential UAF in smb2_is_valid_oplock_break() Skip sessions that are being teared down (status == SES_EXITING) to avoid UAF.
A use-after-free flaw was found in the Linux kernel in the smb client cifs_dump_full_key() when exiting a session. This flaw allows a local attacker to crash the system.
In the Linux kernel, the following vulnerability has been resolved: smb: client: fix potential UAF in cifs_stats_proc_show() The Linux kernel CVE team has assigned CVE-2024-35867 to this issue. Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024051939-CVE-2024-35867-15e3@gregkh/T
The following vulnerability has been resolved in the Linux kernel: smb: client: Fix - Guarantee refcounted children from the parent session.
In the Linux kernel, the following vulnerability has been resolved: mm/secretmem: fix GUP-fast succeeding on secretmem folios The Linux kernel CVE team has assigned CVE-2024-35872 to this issue. Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024051941-CVE-2024-35872-4632@gregkh/T
No description is available for this CVE.
CVE-2024-35877 pertains to a flaw in the Linux kernel's handling of Page Attribute Table (PAT) settings during Copy-On-Write (COW) operations. When a write operation triggers a COW event, the kernel may replace the original page table entries (PTEs) with anonymous folios. This replacement disrupts the kernel's ability to accurately retrieve the correct page frame number (PFN) and cache mode using the follow_phys() function. Consequently, this mismanagement can lead to memory leaks or system instability. During COW operations, the kernel's PAT handling may incorrectly replace PTEs, leading to failures in functions like untrack_pfn() and track_pfn_copy(). This mismanagement can result in improper memory tracking and potential leaks. Systems may experience memory leaks or instability due to the kernel's inability to correctly manage memory attributes during COW events.
A null pointer dereference vulnerability was found in vsnprintf when str and len parameters are passed to vsnprintf(), which only allows passing a NULL ptr when the length is 0. This issue can result in a crash and damage to availability.
CVE-2024-35880 is a vulnerability in the Linux kernel's io_uring subsystem, specifically related to how kernel buffers (kbuf) are handled during memory mapping (mmap) operations. The flaw stems from a situation where a buffer can be unregistered prematurely while it is still being used, leading to a potential use-after-free issue. The io_uring mechanism uses the Read-Copy-Update (RCU) method to manage buffers during mmap. However, the absence of a strong reference to the buffer during operations allows it to be unregistered while still in use. This can result in memory dereferencing errors, leading to crashes or unpredictable behavior.
In the Linux kernel, the following vulnerability has been resolved: ipv6: Fix infinite recursion in fib6_dump_done(). The Linux kernel CVE team has assigned CVE-2024-35886 to this issue. Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024051946-CVE-2024-35886-19d4@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
CVE-2024-35892 is a vulnerability in the Linux kernel’s network scheduler caused by improper use of the qdisc_lookup() function. This function assumes the global RTNL lock is held, but in the qdisc_tree_reduce_backlog() function, only a local queue lock is used. This mismatch creates a race condition that could lead to system instability or crashes. The issue has been fixed by replacing qdisc_lookup() with an RCU-safe version that works correctly in this context.
In the Linux kernel, the following vulnerability has been resolved: mptcp: prevent BPF accessing lowat from a subflow socket. Alexei reported the following splat: WARNING: CPU: 32 PID: 3276 at net/mptcp/subflow.c:1430 subflow_data_ready+0x147/0x1c0 Modules linked in: dummy bpf_testmod(O) [last unloaded: bpf_test_no_cfi(O)] CPU: 32 PID: 3276 Comm: test_progs Tainted: GO 6.8.0-12873-g2c43c33bfd23 Call Trace: <TASK> mptcp_set_rcvlowat+0x79/0x1d0 sk_setsockopt+0x6c0/0x1540 __bpf_setsockopt+0x6f/0x90 bpf_sock_ops_setsockopt+0x3c/0x90 bpf_prog_509ce5db2c7f9981_bpf_test_sockopt_int+0xb4/0x11b bpf_prog_dce07e362d941d2b_bpf_test_socket_sockopt+0x12b/0x132 bpf_prog_348c9b5faaf10092_skops_sockopt+0x954/0xe86 __cgroup_bpf_run_filter_sock_ops+0xbc/0x250 tcp_connect+0x879/0x1160 tcp_v6_connect+0x50c/0x870 mptcp_connect+0x129/0x280 __inet_stream_connect+0xce/0x370 inet_stream_connect+0x36/0x50 bpf_trampoline_6442491565+0x49/0xef inet_stream_connect+0x5/0x50 __sys_connect+0x63/0x90 __x64_sys_connect+0x14/0x20 The root cause of the issue is that bpf allows accessing mptcp-level proto_ops from a tcp subflow scope. Fix the issue detecting the problematic call and preventing any action.
In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: reject new basechain after table flag update The Linux kernel CVE team has assigned CVE-2024-35900 to this issue. Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024051952-CVE-2024-35900-c2c9@gregkh/T
In the Linux kernel, the following vulnerability has been resolved: selinux: avoid dereference of garbage after mount failure The Linux kernel CVE team has assigned CVE-2024-35904 to this issue. Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024051953-CVE-2024-35904-7f85@gregkh/T
A flaw was found in the Linux kernel. An integer overflow vulnerability exists in the access size of a stack, such that the size of the access stack can appear negative as a result of overflowing its signed int representation. This issue can result in denial of service.
In the Linux kernel, the following vulnerability has been resolved: tls: get psock ref after taking rxlock to avoid leak At the start of tls_sw_recvmsg, we take a reference on the psock, and then call tls_rx_reader_lock. If that fails, we return directly without releasing the reference. Instead of adding a new label, just take the reference after locking has succeeded, since we don't need it before.
In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: rfi: fix potential response leaks The Linux kernel CVE team has assigned CVE-2024-35912 to this issue. Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024051956-CVE-2024-35912-b093@gregkh/T
In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: pick the version of SESSION_PROTECTION_NOTIF The Linux kernel CVE team has assigned CVE-2024-35913 to this issue. Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024051956-CVE-2024-35913-72a4@gregkh/T
This CVE has been marked as Rejected by the assigning CNA.
No description is available for this CVE.
In the Linux kernel, the following vulnerability has been resolved: usb: typec: ucsi: Limit read size on v1.2 The Linux kernel CVE team has assigned CVE-2024-35924 to this issue. Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024051914-CVE-2024-35924-90f6@gregkh/T
In the Linux kernel, the following vulnerability has been resolved: block: prevent division by zero in blk_rq_stat_sum() The Linux kernel CVE team has assigned CVE-2024-35925 to this issue. Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024051914-CVE-2024-35925-fa17@gregkh/T
In the Linux kernel, the following vulnerability has been resolved: drm: Check output polling initialized before disabling The Linux kernel CVE team has assigned CVE-2024-35927 to this issue. Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024051915-CVE-2024-35927-2100@gregkh/T
No description is available for this CVE.
In the Linux kernel, the following vulnerability has been resolved: scsi: lpfc: Fix possible memory leak in lpfc_rcv_padisc() The Linux kernel CVE team has assigned CVE-2024-35930 to this issue. Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024051916-CVE-2024-35930-5571@gregkh/T
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Skip do PCI error slot reset during RAS recovery The Linux kernel CVE team has assigned CVE-2024-35931 to this issue. Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024051916-CVE-2024-35931-430d@gregkh/T
In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: decrease MHI channel buffer length to 8KB The Linux kernel CVE team has assigned CVE-2024-35938 to this issue. Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024051918-CVE-2024-35938-0100@gregkh/T
In the Linux kernel, the following vulnerability has been resolved: dma-direct: Leak pages on dma_set_decrypted() failure The Linux kernel CVE team has assigned CVE-2024-35939 to this issue. Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024051919-CVE-2024-35939-f877@gregkh/T
In the Linux kernel, the following vulnerability has been resolved: pmdomain: imx8mp-blk-ctrl: imx8mp_blk: Add fdcc clock to hdmimix domain The Linux kernel CVE team has assigned CVE-2024-35942 to this issue. Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024051919-CVE-2024-35942-af72@gregkh/T
In the Linux kernel, the following vulnerability has been resolved: VMCI: Fix memcpy() run-time warning in dg_dispatch_as_host() The Linux kernel CVE team has assigned CVE-2024-35944 to this issue. Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024051920-CVE-2024-35944-a860@gregkh/T
In the Linux kernel, the following vulnerability has been resolved: wifi: rtw89: fix null pointer access when abort scan The Linux kernel CVE team has assigned CVE-2024-35946 to this issue. Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024051921-CVE-2024-35946-c2c2@gregkh/T
In the Linux kernel, the following vulnerability has been resolved: dyndbg: fix old BUG_ON in >control parser The Linux kernel CVE team has assigned CVE-2024-35947 to this issue. Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024051952-CVE-2024-35947-09bb@gregkh/T
A flaw in the Linux kernel's Direct Rendering Manager (DRM) client could cause system instability. The problem occurs because the modes[] array, used to store display mode pointers, wasn’t adequately protected by a mutex lock. This allows the array to reference memory that has already been freed or reused, leading to potential crashes or unpredictable behavior.
CVE-2024-35952 describes an issue in the Linux kernel's AST graphics driver. The problem occurs in the ast_dp_set_on_off() function, where a lack of proper synchronization with the DisplayPort Microcontroller Unit (DPMCU) can result in an infinite loop. This can cause a "soft lockup" in the host system, impacting its availability.
The bug is about a race condition in the Linux kernel's SCSI generic (sg) driver. The problem occurs during the removal of devices when the driver accesses a resource (request_queue) that may have already been freed, leading to a NULL pointer dereference. This issue can result in system crashes, impacting availability.
CVE-2024-35957 is a vulnerability in the Linux kernel's Intel Virtualization Technology for Directed I/O (VT-d) subsystem. The issue stems from an incorrect assumption that each device has a unique source ID, leading to potential conflicts and system warnings during the IOMMU probe process. This flaw has been addressed by modifying the tracking mechanism to include only devices with PCI Address Translation Services (ATS) capabilities, thereby preventing unnecessary warnings and ensuring system stability. Users are advised to 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: 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
In the Linux kernel, the following vulnerability has been resolved: geneve: fix header validation in geneve[6]_xmit_skb The Linux kernel CVE team has assigned CVE-2024-35973 to this issue. Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024052024-CVE-2024-35973-1b5b@gregkh/T
In the Linux kernel, the following vulnerability has been resolved: xsk: validate user input for XDP_{UMEM|COMPLETION}_FILL_RING The Linux kernel CVE team has assigned CVE-2024-35976 to this issue. Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024052024-CVE-2024-35976-339b@gregkh/T
In the Linux kernel, the following vulnerability has been resolved: raid1: fix use-after-free for original bio in raid1_write_request() The Linux kernel CVE team has assigned CVE-2024-35979 to this issue. Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024052025-CVE-2024-35979-2618@gregkh/T
A vulnerability was found in the Linux kernel related to the improper handling of power-of-two values for `CONFIG_NR_CPUS`. The `bits_per()` function incorrectly rounds up to the next power of two when given a power of two, causing crashes on certain systems.
In the Linux kernel, the following vulnerability has been resolved: dmaengine: idxd: Convert spinlock to mutex to lock evl workqueue The Linux kernel CVE team has assigned CVE-2024-35991 to this issue. Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024052020-CVE-2024-35991-5f06@gregkh/T
A vulnerability was found in the ACPI subsystem's CPPC driver in the Linux kernel. This issue occurs due to the mishandling of memory access bit width during performance capability calculations, which can lead to misaligned memory accesses and cause kernel panics on affected platforms.
In the Linux kernel, the following vulnerability has been resolved: dpll: fix dpll_pin_on_pin_register() for multiple parent pins In scenario where pin is registered with multiple parent pins via dpll_pin_on_pin_register(..), all belonging to the same dpll device. A second call to dpll_pin_on_pin_unregister(..) would cause a call trace, as it tries to use already released registration resources (due to fix introduced in b446631f355e). In this scenario pin was registered twice, so resources are not yet expected to be release until each registered pin/pin pair is unregistered. Currently, the following crash/call trace is produced when ice driver is removed on the system with installed E810T NIC which includes dpll device: WARNING: CPU: 51 PID: 9155 at drivers/dpll/dpll_core.c:809 dpll_pin_ops+0x20/0x30 RIP: 0010:dpll_pin_ops+0x20/0x30 Call Trace: ? __warn+0x7f/0x130 ? dpll_pin_ops+0x20/0x30 dpll_msg_add_pin_freq+0x37/0x1d0 dpll_cmd_pin_get_one+0x1c0/0x400 ? __nlmsg_put+0x63/0x80 dpll_pin_event_send+0x93/0x140 dpll_pin_on_pin_unregister+0x3f/0x100 ice_dpll_deinit_pins+0xa1/0x230 [ice] ice_remove+0xf1/0x210 [ice] Fix by adding a parent pointer as a cookie when creating a registration, also when searching for it. For the regular pins pass NULL, this allows to create separated registration for each parent the pin is registered with.
In the Linux kernel, the following vulnerability has been resolved: mlxsw: spectrum_acl_tcam: Fix incorrect list API usage The Linux kernel CVE team has assigned CVE-2024-36006 to this issue. Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024052025-CVE-2024-36006-c032@gregkh/T
In the Linux kernel, the following vulnerability has been resolved: igb: Fix string truncation warnings in igb_set_fw_version Commit 1978d3ead82c ("intel: fix string truncation warnings") fixes '-Wformat-truncation=' warnings in igb_main.c by using kasprintf. drivers/net/ethernet/intel/igb/igb_main.c:3092:53: warning:‘%d’ directive output may be truncated writing between 1 and 5 bytes into a region of size between 1 and 13 [-Wformat-truncation=] 3092 | "%d.%d, 0x%08x, %d.%d.%d", | ^~ drivers/net/ethernet/intel/igb/igb_main.c:3092:34: note:directive argument in the range [0, 65535] 3092 | "%d.%d, 0x%08x, %d.%d.%d", | ^~~~~~~~~~~~~~~~~~~~~~~~~ drivers/net/ethernet/intel/igb/igb_main.c:3092:34: note:directive argument in the range [0, 65535] drivers/net/ethernet/intel/igb/igb_main.c:3090:25: note:‘snprintf’ output between 23 and 43 bytes into a destination of size 32 kasprintf() returns a pointer to dynamically allocated memory which can be NULL upon failure. Fix this warning by using a larger space for adapter->fw_version, and then fall back and continue to use snprintf.
In the Linux kernel, the following vulnerability has been resolved: ppdev: Add an error check in register_device In register_device, the return value of ida_simple_get is unchecked, in witch ida_simple_get will use an invalid index value. To address this issue, index should be checked after ida_simple_get. When the index value is abnormal, a warning message should be printed, the port should be dropped, and the value should be recorded.
No description is available for this CVE.
CWE-908 - Use of Uninitialized ResourceIn the Linux kernel, the following vulnerability has been resolved: mm/hugetlb: fix DEBUG_LOCKS_WARN_ON(1) when dissolve_free_hugetlb_folio() When I did memory failure tests recently, below warning occurs: DEBUG_LOCKS_WARN_ON(1) WARNING: CPU: 8 PID: 1011 at kernel/locking/lockdep.c:232 __lock_acquire+0xccb/0x1ca0 Modules linked in: mce_inject hwpoison_inject CPU: 8 PID: 1011 Comm: bash Kdump: loaded Not tainted 6.9.0-rc3-next-20240410-00012-gdb69f219f4be #3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 RIP: 0010:__lock_acquire+0xccb/0x1ca0 RSP: 0018:ffffa7a1c7fe3bd0 EFLAGS: 00000082 RAX: 0000000000000000 RBX: eb851eb853975fcf RCX: ffffa1ce5fc1c9c8 RDX: 00000000ffffffd8 RSI: 0000000000000027 RDI: ffffa1ce5fc1c9c0 RBP: ffffa1c6865d3280 R08: ffffffffb0f570a8 R09: 0000000000009ffb R10: 0000000000000286 R11: ffffffffb0f2ad50 R12: ffffa1c6865d3d10 R13: ffffa1c6865d3c70 R14: 0000000000000000 R15: 0000000000000004 FS: 00007ff9f32aa740(0000) GS:ffffa1ce5fc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ff9f3134ba0 CR3: 00000008484e4000 CR4: 00000000000006f0 Call Trace: <TASK> lock_acquire+0xbe/0x2d0 _raw_spin_lock_irqsave+0x3a/0x60 hugepage_subpool_put_pages.part.0+0xe/0xc0 free_huge_folio+0x253/0x3f0 dissolve_free_huge_page+0x147/0x210 __page_handle_poison+0x9/0x70 memory_failure+0x4e6/0x8c0 hard_offline_page_store+0x55/0xa0 kernfs_fop_write_iter+0x12c/0x1d0 vfs_write+0x380/0x540 ksys_write+0x64/0xe0 do_syscall_64+0xbc/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7ff9f3114887 RSP: 002b:00007ffecbacb458 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 000000000000000c RCX: 00007ff9f3114887 RDX: 000000000000000c RSI: 0000564494164e10 RDI: 0000000000000001 RBP: 0000564494164e10 R08: 00007ff9f31d1460 R09: 000000007fffffff R10: 0000000000000000 R11: 0000000000000246 R12: 000000000000000c R13: 00007ff9f321b780 R14: 00007ff9f3217600 R15: 00007ff9f3216a00 </TASK> Kernel panic - not syncing: kernel: panic_on_warn set ... CPU: 8 PID: 1011 Comm: bash Kdump: loaded Not tainted 6.9.0-rc3-next-20240410-00012-gdb69f219f4be #3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 Call Trace: <TASK> panic+0x326/0x350 check_panic_on_warn+0x4f/0x50 __warn+0x98/0x190 report_bug+0x18e/0x1a0 handle_bug+0x3d/0x70 exc_invalid_op+0x18/0x70 asm_exc_invalid_op+0x1a/0x20 RIP: 0010:__lock_acquire+0xccb/0x1ca0 RSP: 0018:ffffa7a1c7fe3bd0 EFLAGS: 00000082 RAX: 0000000000000000 RBX: eb851eb853975fcf RCX: ffffa1ce5fc1c9c8 RDX: 00000000ffffffd8 RSI: 0000000000000027 RDI: ffffa1ce5fc1c9c0 RBP: ffffa1c6865d3280 R08: ffffffffb0f570a8 R09: 0000000000009ffb R10: 0000000000000286 R11: ffffffffb0f2ad50 R12: ffffa1c6865d3d10 R13: ffffa1c6865d3c70 R14: 0000000000000000 R15: 0000000000000004 lock_acquire+0xbe/0x2d0 _raw_spin_lock_irqsave+0x3a/0x60 hugepage_subpool_put_pages.part.0+0xe/0xc0 free_huge_folio+0x253/0x3f0 dissolve_free_huge_page+0x147/0x210 __page_handle_poison+0x9/0x70 memory_failure+0x4e6/0x8c0 hard_offline_page_store+0x55/0xa0 kernfs_fop_write_iter+0x12c/0x1d0 vfs_write+0x380/0x540 ksys_write+0x64/0xe0 do_syscall_64+0xbc/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7ff9f3114887 RSP: 002b:00007ffecbacb458 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 000000000000000c RCX: 00007ff9f3114887 RDX: 000000000000000c RSI: 0000564494164e10 RDI: 0000000000000001 RBP: 0000564494164e10 R08: 00007ff9f31d1460 R09: 000000007fffffff R10: 0000000000000000 R11: 0000000000000246 R12: 000000000000000c R13: 00007ff9f321b780 R14: 00007ff9f3217600 R15: 00007ff9f3216a00 </TASK> After git bisecting and digging into the code, I believe the root cause is that _deferred_list field of folio is unioned with _hugetlb_subpool field. In __update_and_free_hugetlb_folio(), folio->_deferred_ ---truncated---
In the Linux kernel, the following vulnerability has been resolved: octeontx2-af: fix the double free in rvu_npc_freemem() Clang static checker(scan-build) warning: drivers/net/ethernet/marvell/octeontx2/af/rvu_npc.c:line 2184, column 2 Attempt to free released memory. npc_mcam_rsrcs_deinit() has released 'mcam->counters.bmap'. Deleted this redundant kfree() to fix this double free problem.
In the Linux kernel, the following vulnerability has been resolved: keys: Fix overwrite of key expiration on instantiation The expiry time of a key is unconditionally overwritten during instantiation, defaulting to turn it permanent. This causes a problem for DNS resolution as the expiration set by user-space is overwritten to TIME64_MAX, disabling further DNS updates. Fix this by restoring the condition that key_set_expiry is only called when the pre-parser sets a specific expiry.
In the Linux kernel, the following vulnerability has been resolved: tpm_tis_spi: Account for SPI header when allocating TPM SPI xfer buffer The TPM SPI transfer mechanism uses MAX_SPI_FRAMESIZE for computing the maximum transfer length and the size of the transfer buffer. As such, it does not account for the 4 bytes of header that prepends the SPI data frame. This can result in out-of-bounds accesses and was confirmed with KASAN. Introduce SPI_HDRSIZE to account for the header and use to allocate the transfer buffer.
In the Linux kernel, the following vulnerability has been resolved: mm/userfaultfd: reset ptes when close() for wr-protected ones Userfaultfd unregister includes a step to remove wr-protect bits from all the relevant pgtable entries, but that only covered an explicit UFFDIO_UNREGISTER ioctl, not a close() on the userfaultfd itself. Cover that too. This fixes a WARN trace. The only user visible side effect is the user can observe leftover wr-protect bits even if the user close()ed on an userfaultfd when releasing the last reference of it. However hopefully that should be harmless, and nothing bad should happen even if so. This change is now more important after the recent page-table-check patch we merged in mm-unstable (446dd9ad37d0 ("mm/page_table_check: support userfault wr-protect entries")), as we'll do sanity check on uffd-wp bits without vma context. So it's better if we can 100% guarantee no uffd-wp bit leftovers, to make sure each report will be valid.
In the Linux kernel, the following vulnerability has been resolved: mm: use memalloc_nofs_save() in page_cache_ra_order() See commit f2c817bed58d ("mm: use memalloc_nofs_save in readahead path"), ensure that page_cache_ra_order() do not attempt to reclaim file-backed pages too, or it leads to a deadlock, found issue when test ext4 large folio. INFO: task DataXceiver for:7494 blocked for more than 120 seconds. "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:DataXceiver for state:D stack:0 pid:7494 ppid:1 flags:0x00000200 Call trace: __switch_to+0x14c/0x240 __schedule+0x82c/0xdd0 schedule+0x58/0xf0 io_schedule+0x24/0xa0 __folio_lock+0x130/0x300 migrate_pages_batch+0x378/0x918 migrate_pages+0x350/0x700 compact_zone+0x63c/0xb38 compact_zone_order+0xc0/0x118 try_to_compact_pages+0xb0/0x280 __alloc_pages_direct_compact+0x98/0x248 __alloc_pages+0x510/0x1110 alloc_pages+0x9c/0x130 folio_alloc+0x20/0x78 filemap_alloc_folio+0x8c/0x1b0 page_cache_ra_order+0x174/0x308 ondemand_readahead+0x1c8/0x2b8 page_cache_async_ra+0x68/0xb8 filemap_readahead.isra.0+0x64/0xa8 filemap_get_pages+0x3fc/0x5b0 filemap_splice_read+0xf4/0x280 ext4_file_splice_read+0x2c/0x48 [ext4] vfs_splice_read.part.0+0xa8/0x118 splice_direct_to_actor+0xbc/0x288 do_splice_direct+0x9c/0x108 do_sendfile+0x328/0x468 __arm64_sys_sendfile64+0x8c/0x148 invoke_syscall+0x4c/0x118 el0_svc_common.constprop.0+0xc8/0xf0 do_el0_svc+0x24/0x38 el0_svc+0x4c/0x1f8 el0t_64_sync_handler+0xc0/0xc8 el0t_64_sync+0x188/0x190
In the Linux kernel, the following vulnerability has been resolved: iommu/arm-smmu: Use the correct type in nvidia_smmu_context_fault() This was missed because of the function pointer indirection. nvidia_smmu_context_fault() is also installed as a irq function, and the 'void *' was changed to a struct arm_smmu_domain. Since the iommu_domain is embedded at a non-zero offset this causes nvidia_smmu_context_fault() to miscompute the offset. Fixup the types. Unable to handle kernel NULL pointer dereference at virtual address 0000000000000120 Mem abort info: ESR = 0x0000000096000004 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: level 0 translation fault Data abort info: ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 user pgtable: 4k pages, 48-bit VAs, pgdp=0000000107c9f000 [0000000000000120] pgd=0000000000000000, p4d=0000000000000000 Internal error: Oops: 0000000096000004 [#1] SMP Modules linked in: CPU: 1 PID: 47 Comm: kworker/u25:0 Not tainted 6.9.0-0.rc7.58.eln136.aarch64 #1 Hardware name: Unknown NVIDIA Jetson Orin NX/NVIDIA Jetson Orin NX, BIOS 3.1-32827747 03/19/2023 Workqueue: events_unbound deferred_probe_work_func pstate: 604000c9 (nZCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : nvidia_smmu_context_fault+0x1c/0x158 lr : __free_irq+0x1d4/0x2e8 sp : ffff80008044b6f0 x29: ffff80008044b6f0 x28: ffff000080a60b18 x27: ffffd32b5172e970 x26: 0000000000000000 x25: ffff0000802f5aac x24: ffff0000802f5a30 x23: ffff0000802f5b60 x22: 0000000000000057 x21: 0000000000000000 x20: ffff0000802f5a00 x19: ffff000087d4cd80 x18: ffffffffffffffff x17: 6234362066666666 x16: 6630303078302d30 x15: ffff00008156d888 x14: 0000000000000000 x13: ffff0000801db910 x12: ffff00008156d6d0 x11: 0000000000000003 x10: ffff0000801db918 x9 : ffffd32b50f94d9c x8 : 1fffe0001032fda1 x7 : ffff00008197ed00 x6 : 000000000000000f x5 : 000000000000010e x4 : 000000000000010e x3 : 0000000000000000 x2 : ffffd32b51720cd8 x1 : ffff000087e6f700 x0 : 0000000000000057 Call trace: nvidia_smmu_context_fault+0x1c/0x158 __free_irq+0x1d4/0x2e8 free_irq+0x3c/0x80 devm_free_irq+0x64/0xa8 arm_smmu_domain_free+0xc4/0x158 iommu_domain_free+0x44/0xa0 iommu_deinit_device+0xd0/0xf8 __iommu_group_remove_device+0xcc/0xe0 iommu_bus_notifier+0x64/0xa8 notifier_call_chain+0x78/0x148 blocking_notifier_call_chain+0x4c/0x90 bus_notify+0x44/0x70 device_del+0x264/0x3e8 pci_remove_bus_device+0x84/0x120 pci_remove_root_bus+0x5c/0xc0 dw_pcie_host_deinit+0x38/0xe0 tegra_pcie_config_rp+0xc0/0x1f0 tegra_pcie_dw_probe+0x34c/0x700 platform_probe+0x70/0xe8 really_probe+0xc8/0x3a0 __driver_probe_device+0x84/0x160 driver_probe_device+0x44/0x130 __device_attach_driver+0xc4/0x170 bus_for_each_drv+0x90/0x100 __device_attach+0xa8/0x1c8 device_initial_probe+0x1c/0x30 bus_probe_device+0xb0/0xc0 deferred_probe_work_func+0xbc/0x120 process_one_work+0x194/0x490 worker_thread+0x284/0x3b0 kthread+0xf4/0x108 ret_from_fork+0x10/0x20 Code: a9b97bfd 910003fd a9025bf5 f85a0035 (b94122a1)
No description is available for this CVE.
CWE-489 - Active Debug CodeIn the Linux kernel, the following vulnerability has been resolved: maple_tree: fix mas_empty_area_rev() null pointer dereference Currently the code calls mas_start() followed by mas_data_end() if the maple state is MA_START, but mas_start() may return with the maple state node == NULL. This will lead to a null pointer dereference when checking information in the NULL node, which is done in mas_data_end(). Avoid setting the offset if there is no node by waiting until after the maple state is checked for an empty or single entry state. A user could trigger the events to cause a kernel oops by unmapping all vmas to produce an empty maple tree, then mapping a vma that would cause the scenario described above.
In the Linux kernel, the following vulnerability has been resolved: USB: core: Fix access violation during port device removal Testing with KASAN and syzkaller revealed a bug in port.c:disable_store(): usb_hub_to_struct_hub() can return NULL if the hub that the port belongs to is concurrently removed, but the function does not check for this possibility before dereferencing the returned value. It turns out that the first dereference is unnecessary, since hub->intfdev is the parent of the port device, so it can be changed easily. Adding a check for hub == NULL prevents further problems. The same bug exists in the disable_show() routine, and it can be fixed the same way.
In the Linux kernel, the following vulnerability has been resolved: ipv6: prevent NULL dereference in ip6_output() According to syzbot, there is a chance that ip6_dst_idev() returns NULL in ip6_output(). Most places in IPv6 stack deal with a NULL idev just fine, but not here. syzbot reported: general protection fault, probably for non-canonical address 0xdffffc00000000bc: 0000 [#1] PREEMPT SMP KASAN PTI KASAN: null-ptr-deref in range [0x00000000000005e0-0x00000000000005e7] CPU: 0 PID: 9775 Comm: syz-executor.4 Not tainted 6.9.0-rc5-syzkaller-00157-g6a30653b604a #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024 RIP: 0010:ip6_output+0x231/0x3f0 net/ipv6/ip6_output.c:237 Code: 3c 1e 00 49 89 df 74 08 4c 89 ef e8 19 58 db f7 48 8b 44 24 20 49 89 45 00 49 89 c5 48 8d 9d e0 05 00 00 48 89 d8 48 c1 e8 03 <42> 0f b6 04 38 84 c0 4c 8b 74 24 28 0f 85 61 01 00 00 8b 1b 31 ff RSP: 0018:ffffc9000927f0d8 EFLAGS: 00010202 RAX: 00000000000000bc RBX: 00000000000005e0 RCX: 0000000000040000 RDX: ffffc900131f9000 RSI: 0000000000004f47 RDI: 0000000000004f48 RBP: 0000000000000000 R08: ffffffff8a1f0b9a R09: 1ffffffff1f51fad R10: dffffc0000000000 R11: fffffbfff1f51fae R12: ffff8880293ec8c0 R13: ffff88805d7fc000 R14: 1ffff1100527d91a R15: dffffc0000000000 FS: 00007f135c6856c0(0000) GS:ffff8880b9400000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020000080 CR3: 0000000064096000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> NF_HOOK include/linux/netfilter.h:314 [inline] ip6_xmit+0xefe/0x17f0 net/ipv6/ip6_output.c:358 sctp_v6_xmit+0x9f2/0x13f0 net/sctp/ipv6.c:248 sctp_packet_transmit+0x26ad/0x2ca0 net/sctp/output.c:653 sctp_packet_singleton+0x22c/0x320 net/sctp/outqueue.c:783 sctp_outq_flush_ctrl net/sctp/outqueue.c:914 [inline] sctp_outq_flush+0x6d5/0x3e20 net/sctp/outqueue.c:1212 sctp_side_effects net/sctp/sm_sideeffect.c:1198 [inline] sctp_do_sm+0x59cc/0x60c0 net/sctp/sm_sideeffect.c:1169 sctp_primitive_ASSOCIATE+0x95/0xc0 net/sctp/primitive.c:73 __sctp_connect+0x9cd/0xe30 net/sctp/socket.c:1234 sctp_connect net/sctp/socket.c:4819 [inline] sctp_inet_connect+0x149/0x1f0 net/sctp/socket.c:4834 __sys_connect_file net/socket.c:2048 [inline] __sys_connect+0x2df/0x310 net/socket.c:2065 __do_sys_connect net/socket.c:2075 [inline] __se_sys_connect net/socket.c:2072 [inline] __x64_sys_connect+0x7a/0x90 net/socket.c:2072 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f
In the Linux kernel, the following vulnerability has been resolved: ipv6: fib6_rules: avoid possible NULL dereference in fib6_rule_action() syzbot is able to trigger the following crash [1], caused by unsafe ip6_dst_idev() use. Indeed ip6_dst_idev() can return NULL, and must always be checked. [1] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] CPU: 0 PID: 31648 Comm: syz-executor.0 Not tainted 6.9.0-rc4-next-20240417-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024 RIP: 0010:__fib6_rule_action net/ipv6/fib6_rules.c:237 [inline] RIP: 0010:fib6_rule_action+0x241/0x7b0 net/ipv6/fib6_rules.c:267 Code: 02 00 00 49 8d 9f d8 00 00 00 48 89 d8 48 c1 e8 03 42 80 3c 20 00 74 08 48 89 df e8 f9 32 bf f7 48 8b 1b 48 89 d8 48 c1 e8 03 <42> 80 3c 20 00 74 08 48 89 df e8 e0 32 bf f7 4c 8b 03 48 89 ef 4c RSP: 0018:ffffc9000fc1f2f0 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 1a772f98c8186700 RDX: 0000000000000003 RSI: ffffffff8bcac4e0 RDI: ffffffff8c1f9760 RBP: ffff8880673fb980 R08: ffffffff8fac15ef R09: 1ffffffff1f582bd R10: dffffc0000000000 R11: fffffbfff1f582be R12: dffffc0000000000 R13: 0000000000000080 R14: ffff888076509000 R15: ffff88807a029a00 FS: 00007f55e82ca6c0(0000) GS:ffff8880b9400000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000001b31d23000 CR3: 0000000022b66000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> fib_rules_lookup+0x62c/0xdb0 net/core/fib_rules.c:317 fib6_rule_lookup+0x1fd/0x790 net/ipv6/fib6_rules.c:108 ip6_route_output_flags_noref net/ipv6/route.c:2637 [inline] ip6_route_output_flags+0x38e/0x610 net/ipv6/route.c:2649 ip6_route_output include/net/ip6_route.h:93 [inline] ip6_dst_lookup_tail+0x189/0x11a0 net/ipv6/ip6_output.c:1120 ip6_dst_lookup_flow+0xb9/0x180 net/ipv6/ip6_output.c:1250 sctp_v6_get_dst+0x792/0x1e20 net/sctp/ipv6.c:326 sctp_transport_route+0x12c/0x2e0 net/sctp/transport.c:455 sctp_assoc_add_peer+0x614/0x15c0 net/sctp/associola.c:662 sctp_connect_new_asoc+0x31d/0x6c0 net/sctp/socket.c:1099 __sctp_connect+0x66d/0xe30 net/sctp/socket.c:1197 sctp_connect net/sctp/socket.c:4819 [inline] sctp_inet_connect+0x149/0x1f0 net/sctp/socket.c:4834 __sys_connect_file net/socket.c:2048 [inline] __sys_connect+0x2df/0x310 net/socket.c:2065 __do_sys_connect net/socket.c:2075 [inline] __se_sys_connect net/socket.c:2072 [inline] __x64_sys_connect+0x7a/0x90 net/socket.c:2072 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f
In the Linux kernel, the following vulnerability has been resolved: tcp: defer shutdown(SEND_SHUTDOWN) for TCP_SYN_RECV sockets TCP_SYN_RECV state is really special, it is only used by cross-syn connections, mostly used by fuzzers. In the following crash [1], syzbot managed to trigger a divide by zero in tcp_rcv_space_adjust() A socket makes the following state transitions, without ever calling tcp_init_transfer(), meaning tcp_init_buffer_space() is also not called. TCP_CLOSE connect() TCP_SYN_SENT TCP_SYN_RECV shutdown() -> tcp_shutdown(sk, SEND_SHUTDOWN) TCP_FIN_WAIT1 To fix this issue, change tcp_shutdown() to not perform a TCP_SYN_RECV -> TCP_FIN_WAIT1 transition, which makes no sense anyway. When tcp_rcv_state_process() later changes socket state from TCP_SYN_RECV to TCP_ESTABLISH, then look at sk->sk_shutdown to finally enter TCP_FIN_WAIT1 state, and send a FIN packet from a sane socket state. This means tcp_send_fin() can now be called from BH context, and must use GFP_ATOMIC allocations. [1] divide error: 0000 [#1] PREEMPT SMP KASAN NOPTI CPU: 1 PID: 5084 Comm: syz-executor358 Not tainted 6.9.0-rc6-syzkaller-00022-g98369dccd2f8 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024 RIP: 0010:tcp_rcv_space_adjust+0x2df/0x890 net/ipv4/tcp_input.c:767 Code: e3 04 4c 01 eb 48 8b 44 24 38 0f b6 04 10 84 c0 49 89 d5 0f 85 a5 03 00 00 41 8b 8e c8 09 00 00 89 e8 29 c8 48 0f af c3 31 d2 <48> f7 f1 48 8d 1c 43 49 8d 96 76 08 00 00 48 89 d0 48 c1 e8 03 48 RSP: 0018:ffffc900031ef3f0 EFLAGS: 00010246 RAX: 0c677a10441f8f42 RBX: 000000004fb95e7e RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: 0000000027d4b11f R08: ffffffff89e535a4 R09: 1ffffffff25e6ab7 R10: dffffc0000000000 R11: ffffffff8135e920 R12: ffff88802a9f8d30 R13: dffffc0000000000 R14: ffff88802a9f8d00 R15: 1ffff1100553f2da FS: 00005555775c0380(0000) GS:ffff8880b9500000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f1155bf2304 CR3: 000000002b9f2000 CR4: 0000000000350ef0 Call Trace: <TASK> tcp_recvmsg_locked+0x106d/0x25a0 net/ipv4/tcp.c:2513 tcp_recvmsg+0x25d/0x920 net/ipv4/tcp.c:2578 inet6_recvmsg+0x16a/0x730 net/ipv6/af_inet6.c:680 sock_recvmsg_nosec net/socket.c:1046 [inline] sock_recvmsg+0x109/0x280 net/socket.c:1068 ____sys_recvmsg+0x1db/0x470 net/socket.c:2803 ___sys_recvmsg net/socket.c:2845 [inline] do_recvmmsg+0x474/0xae0 net/socket.c:2939 __sys_recvmmsg net/socket.c:3018 [inline] __do_sys_recvmmsg net/socket.c:3041 [inline] __se_sys_recvmmsg net/socket.c:3034 [inline] __x64_sys_recvmmsg+0x199/0x250 net/socket.c:3034 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7faeb6363db9 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 c1 17 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007ffcc1997168 EFLAGS: 00000246 ORIG_RAX: 000000000000012b RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007faeb6363db9 RDX: 0000000000000001 RSI: 0000000020000bc0 RDI: 0000000000000005 RBP: 0000000000000000 R08: 0000000000000000 R09: 000000000000001c R10: 0000000000000122 R11: 0000000000000246 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000001 R15: 0000000000000001
In the Linux kernel, the following vulnerability has been resolved: block: fix overflow in blk_ioctl_discard() There is no check for overflow of 'start + len' in blk_ioctl_discard(). Hung task occurs if submit an discard ioctl with the following param: start = 0x80000000000ff000, len = 0x8000000000fff000; Add the overflow validation now.
In the Linux kernel, the following vulnerability has been resolved: scsi: mpi3mr: Avoid memcpy field-spanning write WARNING When the "storcli2 show" command is executed for eHBA-9600, mpi3mr driver prints this WARNING message: memcpy: detected field-spanning write (size 128) of single field "bsg_reply_buf->reply_buf" at drivers/scsi/mpi3mr/mpi3mr_app.c:1658 (size 1) WARNING: CPU: 0 PID: 12760 at drivers/scsi/mpi3mr/mpi3mr_app.c:1658 mpi3mr_bsg_request+0x6b12/0x7f10 [mpi3mr] The cause of the WARN is 128 bytes memcpy to the 1 byte size array "__u8 replay_buf[1]" in the struct mpi3mr_bsg_in_reply_buf. The array is intended to be a flexible length array, so the WARN is a false positive. To suppress the WARN, remove the constant number '1' from the array declaration and clarify that it has flexible length. Also, adjust the memory allocation size to match the change.
In the Linux kernel, the following vulnerability has been resolved: powerpc/pseries/iommu: LPAR panics during boot up with a frozen PE At the time of LPAR boot up, partition firmware provides Open Firmware property ibm,dma-window for the PE. This property is provided on the PCI bus the PE is attached to. There are execptions where the partition firmware might not provide this property for the PE at the time of LPAR boot up. One of the scenario is where the firmware has frozen the PE due to some error condition. This PE is frozen for 24 hours or unless the whole system is reinitialized. Within this time frame, if the LPAR is booted, the frozen PE will be presented to the LPAR but ibm,dma-window property could be missing. Today, under these circumstances, the LPAR oopses with NULL pointer dereference, when configuring the PCI bus the PE is attached to. BUG: Kernel NULL pointer dereference on read at 0x000000c8 Faulting instruction address: 0xc0000000001024c0 Oops: Kernel access of bad area, sig: 7 [#1] LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA pSeries Modules linked in: Supported: Yes CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.4.0-150600.9-default #1 Hardware name: IBM,9043-MRX POWER10 (raw) 0x800200 0xf000006 of:IBM,FW1060.00 (NM1060_023) hv:phyp pSeries NIP: c0000000001024c0 LR: c0000000001024b0 CTR: c000000000102450 REGS: c0000000037db5c0 TRAP: 0300 Not tainted (6.4.0-150600.9-default) MSR: 8000000002009033 <SF,VEC,EE,ME,IR,DR,RI,LE> CR: 28000822 XER: 00000000 CFAR: c00000000010254c DAR: 00000000000000c8 DSISR: 00080000 IRQMASK: 0 ... NIP [c0000000001024c0] pci_dma_bus_setup_pSeriesLP+0x70/0x2a0 LR [c0000000001024b0] pci_dma_bus_setup_pSeriesLP+0x60/0x2a0 Call Trace: pci_dma_bus_setup_pSeriesLP+0x60/0x2a0 (unreliable) pcibios_setup_bus_self+0x1c0/0x370 __of_scan_bus+0x2f8/0x330 pcibios_scan_phb+0x280/0x3d0 pcibios_init+0x88/0x12c do_one_initcall+0x60/0x320 kernel_init_freeable+0x344/0x3e4 kernel_init+0x34/0x1d0 ret_from_kernel_user_thread+0x14/0x1c
In the Linux kernel, the following vulnerability has been resolved: ipv4: Fix uninit-value access in __ip_make_skb() KMSAN reported uninit-value access in __ip_make_skb() [1]. __ip_make_skb() tests HDRINCL to know if the skb has icmphdr. However, HDRINCL can cause a race condition. If calling setsockopt(2) with IP_HDRINCL changes HDRINCL while __ip_make_skb() is running, the function will access icmphdr in the skb even if it is not included. This causes the issue reported by KMSAN. Check FLOWI_FLAG_KNOWN_NH on fl4->flowi4_flags instead of testing HDRINCL on the socket. Also, fl4->fl4_icmp_type and fl4->fl4_icmp_code are not initialized. These are union in struct flowi4 and are implicitly initialized by flowi4_init_output(), but we should not rely on specific union layout. Initialize these explicitly in raw_sendmsg(). [1] BUG: KMSAN: uninit-value in __ip_make_skb+0x2b74/0x2d20 net/ipv4/ip_output.c:1481 __ip_make_skb+0x2b74/0x2d20 net/ipv4/ip_output.c:1481 ip_finish_skb include/net/ip.h:243 [inline] ip_push_pending_frames+0x4c/0x5c0 net/ipv4/ip_output.c:1508 raw_sendmsg+0x2381/0x2690 net/ipv4/raw.c:654 inet_sendmsg+0x27b/0x2a0 net/ipv4/af_inet.c:851 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x274/0x3c0 net/socket.c:745 __sys_sendto+0x62c/0x7b0 net/socket.c:2191 __do_sys_sendto net/socket.c:2203 [inline] __se_sys_sendto net/socket.c:2199 [inline] __x64_sys_sendto+0x130/0x200 net/socket.c:2199 do_syscall_64+0xd8/0x1f0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x6d/0x75 Uninit was created at: slab_post_alloc_hook mm/slub.c:3804 [inline] slab_alloc_node mm/slub.c:3845 [inline] kmem_cache_alloc_node+0x5f6/0xc50 mm/slub.c:3888 kmalloc_reserve+0x13c/0x4a0 net/core/skbuff.c:577 __alloc_skb+0x35a/0x7c0 net/core/skbuff.c:668 alloc_skb include/linux/skbuff.h:1318 [inline] __ip_append_data+0x49ab/0x68c0 net/ipv4/ip_output.c:1128 ip_append_data+0x1e7/0x260 net/ipv4/ip_output.c:1365 raw_sendmsg+0x22b1/0x2690 net/ipv4/raw.c:648 inet_sendmsg+0x27b/0x2a0 net/ipv4/af_inet.c:851 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x274/0x3c0 net/socket.c:745 __sys_sendto+0x62c/0x7b0 net/socket.c:2191 __do_sys_sendto net/socket.c:2203 [inline] __se_sys_sendto net/socket.c:2199 [inline] __x64_sys_sendto+0x130/0x200 net/socket.c:2199 do_syscall_64+0xd8/0x1f0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x6d/0x75 CPU: 1 PID: 15709 Comm: syz-executor.7 Not tainted 6.8.0-11567-gb3603fcb79b1 #25 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-1.fc39 04/01/2014
A flaw was found in the Linux kernel's s390/qeth component. A local attacker with privileges to manage network devices could trigger a kernel panic by setting the hsuid attribute on an IQD Layer3 device while its network interface is active. This occurs because the kernel attempts to execute a null function pointer. Successful exploitation leads to a Denial of Service (DoS) for the system.
In the Linux kernel, the following vulnerability has been resolved: spi: fix null pointer dereference within spi_sync If spi_sync() is called with the non-empty queue and the same spi_message is then reused, the complete callback for the message remains set while the context is cleared, leading to a null pointer dereference when the callback is invoked from spi_finalize_current_message(). With function inlining disabled, the call stack might look like this: _raw_spin_lock_irqsave from complete_with_flags+0x18/0x58 complete_with_flags from spi_complete+0x8/0xc spi_complete from spi_finalize_current_message+0xec/0x184 spi_finalize_current_message from spi_transfer_one_message+0x2a8/0x474 spi_transfer_one_message from __spi_pump_transfer_message+0x104/0x230 __spi_pump_transfer_message from __spi_transfer_message_noqueue+0x30/0xc4 __spi_transfer_message_noqueue from __spi_sync+0x204/0x248 __spi_sync from spi_sync+0x24/0x3c spi_sync from mcp251xfd_regmap_crc_read+0x124/0x28c [mcp251xfd] mcp251xfd_regmap_crc_read [mcp251xfd] from _regmap_raw_read+0xf8/0x154 _regmap_raw_read from _regmap_bus_read+0x44/0x70 _regmap_bus_read from _regmap_read+0x60/0xd8 _regmap_read from regmap_read+0x3c/0x5c regmap_read from mcp251xfd_alloc_can_err_skb+0x1c/0x54 [mcp251xfd] mcp251xfd_alloc_can_err_skb [mcp251xfd] from mcp251xfd_irq+0x194/0xe70 [mcp251xfd] mcp251xfd_irq [mcp251xfd] from irq_thread_fn+0x1c/0x78 irq_thread_fn from irq_thread+0x118/0x1f4 irq_thread from kthread+0xd8/0xf4 kthread from ret_from_fork+0x14/0x28 Fix this by also setting message->complete to NULL when the transfer is complete.
In the Linux kernel, the following vulnerability has been resolved: thermal/debugfs: Prevent use-after-free from occurring after cdev removal Since thermal_debug_cdev_remove() does not run under cdev->lock, it can run in parallel with thermal_debug_cdev_state_update() and it may free the struct thermal_debugfs object used by the latter after it has been checked against NULL. If that happens, thermal_debug_cdev_state_update() will access memory that has been freed already causing the kernel to crash. Address this by using cdev->lock in thermal_debug_cdev_remove() around the cdev->debugfs value check (in case the same cdev is removed at the same time in two different threads) and its reset to NULL. Cc :6.8+ <stable@vger.kernel.org> # 6.8+
In the Linux kernel, the following vulnerability has been resolved: nsh: Restore skb->{protocol,data,mac_header} for outer header in nsh_gso_segment(). syzbot triggered various splats (see [0] and links) by a crafted GSO packet of VIRTIO_NET_HDR_GSO_UDP layering the following protocols: ETH_P_8021AD + ETH_P_NSH + ETH_P_IPV6 + IPPROTO_UDP NSH can encapsulate IPv4, IPv6, Ethernet, NSH, and MPLS. As the inner protocol can be Ethernet, NSH GSO handler, nsh_gso_segment(), calls skb_mac_gso_segment() to invoke inner protocol GSO handlers. nsh_gso_segment() does the following for the original skb before calling skb_mac_gso_segment() 1. reset skb->network_header 2. save the original skb->{mac_heaeder,mac_len} in a local variable 3. pull the NSH header 4. resets skb->mac_header 5. set up skb->mac_len and skb->protocol for the inner protocol. and does the following for the segmented skb 6. set ntohs(ETH_P_NSH) to skb->protocol 7. push the NSH header 8. restore skb->mac_header 9. set skb->mac_header + mac_len to skb->network_header 10. restore skb->mac_len There are two problems in 6-7 and 8-9. (a) After 6 & 7, skb->data points to the NSH header, so the outer header (ETH_P_8021AD in this case) is stripped when skb is sent out of netdev. Also, if NSH is encapsulated by NSH + Ethernet (so NSH-Ethernet-NSH), skb_pull() in the first nsh_gso_segment() will make skb->data point to the middle of the outer NSH or Ethernet header because the Ethernet header is not pulled by the second nsh_gso_segment(). (b) While restoring skb->{mac_header,network_header} in 8 & 9, nsh_gso_segment() does not assume that the data in the linear buffer is shifted. However, udp6_ufo_fragment() could shift the data and change skb->mac_header accordingly as demonstrated by syzbot. If this happens, even the restored skb->mac_header points to the middle of the outer header. It seems nsh_gso_segment() has never worked with outer headers so far. At the end of nsh_gso_segment(), the outer header must be restored for the segmented skb, instead of the NSH header. To do that, let's calculate the outer header position relatively from the inner header and set skb->{data,mac_header,protocol} properly. [0]: BUG: KMSAN: uninit-value in ipvlan_process_outbound drivers/net/ipvlan/ipvlan_core.c:524 [inline] BUG: KMSAN: uninit-value in ipvlan_xmit_mode_l3 drivers/net/ipvlan/ipvlan_core.c:602 [inline] BUG: KMSAN: uninit-value in ipvlan_queue_xmit+0xf44/0x16b0 drivers/net/ipvlan/ipvlan_core.c:668 ipvlan_process_outbound drivers/net/ipvlan/ipvlan_core.c:524 [inline] ipvlan_xmit_mode_l3 drivers/net/ipvlan/ipvlan_core.c:602 [inline] ipvlan_queue_xmit+0xf44/0x16b0 drivers/net/ipvlan/ipvlan_core.c:668 ipvlan_start_xmit+0x5c/0x1a0 drivers/net/ipvlan/ipvlan_main.c:222 __netdev_start_xmit include/linux/netdevice.h:4989 [inline] netdev_start_xmit include/linux/netdevice.h:5003 [inline] xmit_one net/core/dev.c:3547 [inline] dev_hard_start_xmit+0x244/0xa10 net/core/dev.c:3563 __dev_queue_xmit+0x33ed/0x51c0 net/core/dev.c:4351 dev_queue_xmit include/linux/netdevice.h:3171 [inline] packet_xmit+0x9c/0x6b0 net/packet/af_packet.c:276 packet_snd net/packet/af_packet.c:3081 [inline] packet_sendmsg+0x8aef/0x9f10 net/packet/af_packet.c:3113 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline] __sys_sendto+0x735/0xa10 net/socket.c:2191 __do_sys_sendto net/socket.c:2203 [inline] __se_sys_sendto net/socket.c:2199 [inline] __x64_sys_sendto+0x125/0x1c0 net/socket.c:2199 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b Uninit was created at: slab_post_alloc_hook mm/slub.c:3819 [inline] slab_alloc_node mm/slub.c:3860 [inline] __do_kmalloc_node mm/slub.c:3980 [inline] __kmalloc_node_track_caller+0x705/0x1000 mm/slub.c:4001 kmalloc_reserve+0x249/0x4a0 net/core/skbuff.c:582 __ ---truncated---
In the Linux kernel, the following vulnerability has been resolved: efi/unaccepted: touch soft lockup during memory accept Commit 50e782a86c98 ("efi/unaccepted: Fix soft lockups caused by parallel memory acceptance") has released the spinlock so other CPUs can do memory acceptance in parallel and not triggers softlockup on other CPUs. However the softlock up was intermittent shown up if the memory of the TD guest is large, and the timeout of softlockup is set to 1 second: RIP: 0010:_raw_spin_unlock_irqrestore Call Trace: ? __hrtimer_run_queues <IRQ> ? hrtimer_interrupt ? watchdog_timer_fn ? __sysvec_apic_timer_interrupt ? __pfx_watchdog_timer_fn ? sysvec_apic_timer_interrupt </IRQ> ? __hrtimer_run_queues <TASK> ? hrtimer_interrupt ? asm_sysvec_apic_timer_interrupt ? _raw_spin_unlock_irqrestore ? __sysvec_apic_timer_interrupt ? sysvec_apic_timer_interrupt accept_memory try_to_accept_memory do_huge_pmd_anonymous_page get_page_from_freelist __handle_mm_fault __alloc_pages __folio_alloc ? __tdx_hypercall handle_mm_fault vma_alloc_folio do_user_addr_fault do_huge_pmd_anonymous_page exc_page_fault ? __do_huge_pmd_anonymous_page asm_exc_page_fault __handle_mm_fault When the local irq is enabled at the end of accept_memory(), the softlockup detects that the watchdog on single CPU has not been fed for a while. That is to say, even other CPUs will not be blocked by spinlock, the current CPU might be stunk with local irq disabled for a while, which hurts not only nmi watchdog but also softlockup. Chao Gao pointed out that the memory accept could be time costly and there was similar report before. Thus to avoid any softlocup detection during this stage, give the softlockup a flag to skip the timeout check at the end of accept_memory(), by invoking touch_softlockup_watchdog().
In the Linux kernel, the following vulnerability has been resolved: nfs: Handle error of rpc_proc_register() in nfs_net_init(). syzkaller reported a warning [0] triggered while destroying immature netns. rpc_proc_register() was called in init_nfs_fs(), but its error has been ignored since at least the initial commit 1da177e4c3f4 ("Linux-2.6.12-rc2"). Recently, commit d47151b79e32 ("nfs: expose /proc/net/sunrpc/nfs in net namespaces") converted the procfs to per-netns and made the problem more visible. Even when rpc_proc_register() fails, nfs_net_init() could succeed, and thus nfs_net_exit() will be called while destroying the netns. Then, remove_proc_entry() will be called for non-existing proc directory and trigger the warning below. Let's handle the error of rpc_proc_register() properly in nfs_net_init(). [0]: name 'nfs' WARNING: CPU: 1 PID: 1710 at fs/proc/generic.c:711 remove_proc_entry+0x1bb/0x2d0 fs/proc/generic.c:711 Modules linked in: CPU: 1 PID: 1710 Comm: syz-executor.2 Not tainted 6.8.0-12822-gcd51db110a7e #12 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:remove_proc_entry+0x1bb/0x2d0 fs/proc/generic.c:711 Code: 41 5d 41 5e c3 e8 85 09 b5 ff 48 c7 c7 88 58 64 86 e8 09 0e 71 02 e8 74 09 b5 ff 4c 89 e6 48 c7 c7 de 1b 80 84 e8 c5 ad 97 ff <0f> 0b eb b1 e8 5c 09 b5 ff 48 c7 c7 88 58 64 86 e8 e0 0d 71 02 eb RSP: 0018:ffffc9000c6d7ce0 EFLAGS: 00010286 RAX: 0000000000000000 RBX: ffff8880422b8b00 RCX: ffffffff8110503c RDX: ffff888030652f00 RSI: ffffffff81105045 RDI: 0000000000000001 RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000001 R11: ffffffff81bb62cb R12: ffffffff84807ffc R13: ffff88804ad6fcc0 R14: ffffffff84807ffc R15: ffffffff85741ff8 FS: 00007f30cfba8640(0000) GS:ffff88807dd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ff51afe8000 CR3: 000000005a60a005 CR4: 0000000000770ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <TASK> rpc_proc_unregister+0x64/0x70 net/sunrpc/stats.c:310 nfs_net_exit+0x1c/0x30 fs/nfs/inode.c:2438 ops_exit_list+0x62/0xb0 net/core/net_namespace.c:170 setup_net+0x46c/0x660 net/core/net_namespace.c:372 copy_net_ns+0x244/0x590 net/core/net_namespace.c:505 create_new_namespaces+0x2ed/0x770 kernel/nsproxy.c:110 unshare_nsproxy_namespaces+0xae/0x160 kernel/nsproxy.c:228 ksys_unshare+0x342/0x760 kernel/fork.c:3322 __do_sys_unshare kernel/fork.c:3393 [inline] __se_sys_unshare kernel/fork.c:3391 [inline] __x64_sys_unshare+0x1f/0x30 kernel/fork.c:3391 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x4f/0x110 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x46/0x4e RIP: 0033:0x7f30d0febe5d Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 73 9f 1b 00 f7 d8 64 89 01 48 RSP: 002b:00007f30cfba7cc8 EFLAGS: 00000246 ORIG_RAX: 0000000000000110 RAX: ffffffffffffffda RBX: 00000000004bbf80 RCX: 00007f30d0febe5d RDX: 0000000000000000 RSI: 0000000000000000 RDI: 000000006c020600 RBP: 00000000004bbf80 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000002 R13: 000000000000000b R14: 00007f30d104c530 R15: 0000000000000000 </TASK>
In the Linux kernel, the following vulnerability has been resolved: pinctrl: core: delete incorrect free in pinctrl_enable() The "pctldev" struct is allocated in devm_pinctrl_register_and_init(). It's a devm_ managed pointer that is freed by devm_pinctrl_dev_release(), so freeing it in pinctrl_enable() will lead to a double free. The devm_pinctrl_dev_release() function frees the pindescs and destroys the mutex as well.
CWE-415 - Double FreeIn the Linux kernel, the following vulnerability has been resolved: Reapply "drm/qxl: simplify qxl_fence_wait" This reverts commit 07ed11afb68d94eadd4ffc082b97c2331307c5ea. Stephen Rostedt reports: "I went to run my tests on my VMs and the tests hung on boot up. Unfortunately, the most I ever got out was: [ 93.607888] Testing event system initcall: OK [ 93.667730] Running tests on all trace events: [ 93.669757] Testing all events: OK [ 95.631064] ------------[ cut here ]------------ Timed out after 60 seconds" and further debugging points to a possible circular locking dependency between the console_owner locking and the worker pool locking. Reverting the commit allows Steve's VM to boot to completion again. [ This may obviously result in the "[TTM] Buffer eviction failed" messages again, which was the reason for that original revert. But at this point this seems preferable to a non-booting system... ]
In the Linux kernel, the following vulnerability has been resolved: net/smc: fix neighbour and rtable leak in smc_ib_find_route() In smc_ib_find_route(), the neighbour found by neigh_lookup() and rtable resolved by ip_route_output_flow() are not released or put before return. It may cause the refcount leak, so fix it.
CWE-401 - Missing Release of Memory after Effective LifetimeIn the Linux kernel, the following vulnerability has been resolved: ALSA: hda: intel-sdw-acpi: fix usage of device_get_named_child_node() The documentation for device_get_named_child_node() mentions this important point: " The caller is responsible for calling fwnode_handle_put() on the returned fwnode pointer. " Add fwnode_handle_put() to avoid a leaked reference.
In the Linux kernel, the following vulnerability has been resolved: thermal/debugfs: Free all thermal zone debug memory on zone removal Because thermal_debug_tz_remove() does not free all memory allocated for thermal zone diagnostics, some of that memory becomes unreachable after freeing the thermal zone's struct thermal_debugfs object. Address this by making thermal_debug_tz_remove() free all of the memory in question. Cc :6.8+ <stable@vger.kernel.org> # 6.8+
In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: Fix invalid reads in fence signaled events Correctly set the length of the drm_event to the size of the structure that's actually used. The length of the drm_event was set to the parent structure instead of to the drm_vmw_event_fence which is supposed to be read. drm_read uses the length parameter to copy the event to the user space thus resuling in oob reads.
In the Linux kernel, the following vulnerability has been resolved: thermal/debugfs: Fix two locking issues with thermal zone debug With the current thermal zone locking arrangement in the debugfs code, user space can open the "mitigations" file for a thermal zone before the zone's debugfs pointer is set which will result in a NULL pointer dereference in tze_seq_start(). Moreover, thermal_debug_tz_remove() is not called under the thermal zone lock, so it can run in parallel with the other functions accessing the thermal zone's struct thermal_debugfs object. Then, it may clear tz->debugfs after one of those functions has checked it and the struct thermal_debugfs object may be freed prematurely. To address the first problem, pass a pointer to the thermal zone's struct thermal_debugfs object to debugfs_create_file() in thermal_debug_tz_add() and make tze_seq_start(), tze_seq_next(), tze_seq_stop(), and tze_seq_show() retrieve it from s->private instead of a pointer to the thermal zone object. This will ensure that tz_debugfs will be valid across the "mitigations" file accesses until thermal_debugfs_remove_id() called by thermal_debug_tz_remove() removes that file. To address the second problem, use tz->lock in thermal_debug_tz_remove() around the tz->debugfs value check (in case the same thermal zone is removed at the same time in two different threads) and its reset to NULL. Cc :6.8+ <stable@vger.kernel.org> # 6.8+
in linux kernel, tpm2_key_encode() has a memory leak due to 'scratch' never being freed. This can lead to denial of service.
in linux kernel net/sched taprio, TCA_TAPRIO_ATTR_PRIOMAP is not correctly validated if multiple calls to taprio_change() occur. This can allow arbitrary data to be injected to the kernel.
In the Linux kernel, the following vulnerability has been resolved: usb: dwc3: Wait unconditionally after issuing EndXfer command Currently all controller IP/revisions except DWC3_usb3 >= 310a wait 1ms unconditionally for ENDXFER completion when IOC is not set. This is because DWC_usb3 controller revisions >= 3.10a supports GUCTL2[14: Rst_actbitlater] bit which allows polling CMDACT bit to know whether ENDXFER command is completed. Consider a case where an IN request was queued, and parallelly soft_disconnect was called (due to ffs_epfile_release). This eventually calls stop_active_transfer with IOC cleared, hence send_gadget_ep_cmd() skips waiting for CMDACT cleared during EndXfer. For DWC3 controllers with revisions >= 310a, we don't forcefully wait for 1ms either, and we proceed by unmapping the requests. If ENDXFER didn't complete by this time, it leads to SMMU faults since the controller would still be accessing those requests. Fix this by ensuring ENDXFER completion by adding 1ms delay in __dwc3_stop_active_transfer() unconditionally.
In the Linux kernel, the following vulnerability has been resolved: ALSA: hda/cs_dsp_ctl: Use private_free for control cleanup Use the control private_free callback to free the associated data block. This ensures that the memory won't leak, whatever way the control gets destroyed. The original implementation didn't actually remove the ALSA controls in hda_cs_dsp_control_remove(). It only freed the internal tracking structure. This meant it was possible to remove/unload the amp driver while leaving its ALSA controls still present in the soundcard. Obviously attempting to access them could cause segfaults or at least dereferencing stale pointers.
A use-after-free vulnerability has been discovered in the Linux kernel within the drivers/net/ethernet/mellanox/mlx5/core/cmd.c component, specifically related to the Mellanox network driver. This flaw can lead to compromised system availability. Successful exploitation could result in unpredictable behavior and denial-of-service conditions.
A flaw was found in the Linux kernel. This issue is due to a possible use-after-free in drivers/gpu/drm/amd/amdgpu/amdgpu_mes.c.
In the Linux kernel, the following vulnerability has been resolved: af_unix: Fix data races in unix_release_sock/unix_stream_sendmsg A data-race condition has been identified in af_unix. In one data path, the write function unix_release_sock() atomically writes to sk->sk_shutdown using WRITE_ONCE. However, on the reader side, unix_stream_sendmsg() does not read it atomically. Consequently, this issue is causing the following KCSAN splat to occur: BUG: KCSAN: data-race in unix_release_sock / unix_stream_sendmsg write (marked) to 0xffff88867256ddbb of 1 bytes by task 7270 on cpu 28: unix_release_sock (net/unix/af_unix.c:640) unix_release (net/unix/af_unix.c:1050) sock_close (net/socket.c:659 net/socket.c:1421) __fput (fs/file_table.c:422) __fput_sync (fs/file_table.c:508) __se_sys_close (fs/open.c:1559 fs/open.c:1541) __x64_sys_close (fs/open.c:1541) x64_sys_call (arch/x86/entry/syscall_64.c:33) do_syscall_64 (arch/x86/entry/common.c:?) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) read to 0xffff88867256ddbb of 1 bytes by task 989 on cpu 14: unix_stream_sendmsg (net/unix/af_unix.c:2273) __sock_sendmsg (net/socket.c:730 net/socket.c:745) ____sys_sendmsg (net/socket.c:2584) __sys_sendmmsg (net/socket.c:2638 net/socket.c:2724) __x64_sys_sendmmsg (net/socket.c:2753 net/socket.c:2750 net/socket.c:2750) x64_sys_call (arch/x86/entry/syscall_64.c:33) do_syscall_64 (arch/x86/entry/common.c:?) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) value changed: 0x01 -> 0x03 The line numbers are related to commit dd5a440a31fa ("Linux 6.9-rc7"). Commit e1d09c2c2f57 ("af_unix: Fix data races around sk->sk_shutdown.") addressed a comparable issue in the past regarding sk->sk_shutdown. However, it overlooked resolving this particular data path. This patch only offending unix_stream_sendmsg() function, since the other reads seem to be protected by unix_state_lock() as discussed in
In the Linux kernel, the following vulnerability has been resolved: md: fix resync softlockup when bitmap size is less than array size Is is reported that for dm-raid10, lvextend + lvchange --syncaction will trigger following softlockup: kernel:watchdog: BUG: soft lockup - CPU#3 stuck for 26s! [mdX_resync:6976] CPU: 7 PID: 3588 Comm: mdX_resync Kdump: loaded Not tainted 6.9.0-rc4-next-20240419 #1 RIP: 0010:_raw_spin_unlock_irq+0x13/0x30 Call Trace: <TASK> md_bitmap_start_sync+0x6b/0xf0 raid10_sync_request+0x25c/0x1b40 [raid10] md_do_sync+0x64b/0x1020 md_thread+0xa7/0x170 kthread+0xcf/0x100 ret_from_fork+0x30/0x50 ret_from_fork_asm+0x1a/0x30 And the detailed process is as follows: md_do_sync j = mddev->resync_min while (j < max_sectors) sectors = raid10_sync_request(mddev, j, &skipped) if (!md_bitmap_start_sync(..., &sync_blocks)) // md_bitmap_start_sync set sync_blocks to 0 return sync_blocks + sectors_skippe; // sectors = 0; j += sectors; // j never change Root cause is that commit 301867b1c168 ("md/raid10: check slab-out-of-bounds in md_bitmap_get_counter") return early from md_bitmap_get_counter(), without setting returned blocks. Fix this problem by always set returned blocks from md_bitmap_get_counter"(), as it used to be. Noted that this patch just fix the softlockup problem in kernel, the case that bitmap size doesn't match array size still need to be fixed.
In the Linux kernel, the following vulnerability has been resolved: ALSA: Fix deadlocks with kctl removals at disconnection In snd_card_disconnect(), we set card->shutdown flag at the beginning, call callbacks and do sync for card->power_ref_sleep waiters at the end. The callback may delete a kctl element, and this can lead to a deadlock when the device was in the suspended state. Namely: * A process waits for the power up at snd_power_ref_and_wait() in snd_ctl_info() or read/write() inside card->controls_rwsem. * The system gets disconnected meanwhile, and the driver tries to delete a kctl via snd_ctl_remove*(); it tries to take card->controls_rwsem again, but this is already locked by the above. Since the sleeper isn't woken up, this deadlocks. An easy fix is to wake up sleepers before processing the driver disconnect callbacks but right after setting the card->shutdown flag. Then all sleepers will abort immediately, and the code flows again. So, basically this patch moves the wait_event() call at the right timing. While we're at it, just to be sure, call wait_event_all() instead of wait_event(), although we don't use exclusive events on this queue for now.
In the Linux kernel, the following vulnerability has been resolved: block: refine the EOF check in blkdev_iomap_begin blkdev_iomap_begin rounds down the offset to the logical block size before stashing it in iomap->offset and checking that it still is inside the inode size. Check the i_size check to the raw pos value so that we don't try a zero size write if iter->pos is unaligned.
In the Linux kernel, the following vulnerability has been resolved: ALSA: core: Fix NULL module pointer assignment at card init The commit 81033c6b584b ("ALSA: core: Warn on empty module") introduced a WARN_ON() for a NULL module pointer passed at snd_card object creation, and it also wraps the code around it with '#ifdef MODULE'. This works in most cases, but the devils are always in details. "MODULE" is defined when the target code (i.e. the sound core) is built as a module; but this doesn't mean that the caller is also built-in or not. Namely, when only the sound core is built-in (CONFIG_SND=y) while the driver is a module (CONFIG_SND_USB_AUDIO=m), the passed module pointer is ignored even if it's non-NULL, and card->module remains as NULL. This would result in the missing module reference up/down at the device open/close, leading to a race with the code execution after the module removal. For addressing the bug, move the assignment of card->module again out of ifdef. The WARN_ON() is still wrapped with ifdef because the module can be really NULL when all sound drivers are built-in. Note that we keep 'ifdef MODULE' for WARN_ON(), otherwise it would lead to a false-positive NULL module check. Admittedly it won't catch perfectly, i.e. no check is performed when CONFIG_SND=y. But, it's no real problem as it's only for debugging, and the condition is pretty rare.
In the Linux kernel, the following vulnerability has been resolved: ipv6: sr: fix invalid unregister error path The error path of seg6_init() is wrong in case CONFIG_IPV6_SEG6_LWTUNNEL is not defined. In that case if seg6_hmac_init() fails, the genl_unregister_family() isn't called. This issue exist since commit 46738b1317e1 ("ipv6: sr: add option to control lwtunnel support"), and commit 5559cea2d5aa ("ipv6: sr: fix possible use-after-free and null-ptr-deref") replaced unregister_pernet_subsys() with genl_unregister_family() in this error path.
In the Linux kernel, the following vulnerability has been resolved: ALSA: timer: Set lower bound of start tick time Currently ALSA timer doesn't have the lower limit of the start tick time, and it allows a very small size, e.g. 1 tick with 1ns resolution for hrtimer. Such a situation may lead to an unexpected RCU stall, where the callback repeatedly queuing the expire update, as reported by fuzzer. This patch introduces a sanity check of the timer start tick time, so that the system returns an error when a too small start size is set. As of this patch, the lower limit is hard-coded to 100us, which is small enough but can still work somehow.
A vulnerability was found in the Linux kernel's stm class, where an improper memory management sequence in stm_register_device() could lead to a double-free error. This issue occurs when the put_device(&stm->dev) call triggers stm_device_release() to free "stm", making the subsequent vfree(stm) call redundant and potentially harmful.
In the Linux kernel, the following vulnerability has been resolved: dmaengine: idxd: Avoid unnecessary destruction of file_ida file_ida is allocated during cdev open and is freed accordingly during cdev release. This sequence is guaranteed by driver file operations. Therefore, there is no need to destroy an already empty file_ida when the WQ cdev is removed. Worse, ida_free() in cdev release may happen after destruction of file_ida per WQ cdev. This can lead to accessing an id in file_ida after it has been destroyed, resulting in a kernel panic. Remove ida_destroy(&file_ida) to address these issues.
In the Linux kernel, the following vulnerability has been resolved: vfio/pci: fix potential memory leak in vfio_intx_enable() If vfio_irq_ctx_alloc() failed will lead to 'name' memory leak.
in Linux kernel soundwire, an offset is added to the PDI, which leads to an out-of-bounds error.
In the Linux kernel, the following vulnerability has been resolved: ext4: fix mb_cache_entry's e_refcnt leak in ext4_xattr_block_cache_find() Syzbot reports a warning as follows: ============================================ WARNING: CPU: 0 PID: 5075 at fs/mbcache.c:419 mb_cache_destroy+0x224/0x290 Modules linked in: CPU: 0 PID: 5075 Comm: syz-executor199 Not tainted 6.9.0-rc6-gb947cc5bf6d7 RIP: 0010:mb_cache_destroy+0x224/0x290 fs/mbcache.c:419 Call Trace: <TASK> ext4_put_super+0x6d4/0xcd0 fs/ext4/super.c:1375 generic_shutdown_super+0x136/0x2d0 fs/super.c:641 kill_block_super+0x44/0x90 fs/super.c:1675 ext4_kill_sb+0x68/0xa0 fs/ext4/super.c:7327 [...] ============================================ This is because when finding an entry in ext4_xattr_block_cache_find(), if ext4_sb_bread() returns -ENOMEM, the ce's e_refcnt, which has already grown in the __entry_find(), won't be put away, and eventually trigger the above issue in mb_cache_destroy() due to reference count leakage. So call mb_cache_entry_put() on the -ENOMEM error branch as a quick fix.
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Fix buffer size in gfx_v9_4_3_init_ cp_compute_microcode() and rlc_microcode() The function gfx_v9_4_3_init_microcode in gfx_v9_4_3.c was generating about potential truncation of output when using the snprintf function. The issue was due to the size of the buffer 'ucode_prefix' being too small to accommodate the maximum possible length of the string being written into it. The string being written is "amdgpu/%s_mec.bin" or "amdgpu/%s_rlc.bin", where %s is replaced by the value of 'chip_name'. The length of this string without the %s is 16 characters. The warning message indicated that 'chip_name' could be up to 29 characters long, resulting in a total of 45 characters, which exceeds the buffer size of 30 characters. To resolve this issue, the size of the 'ucode_prefix' buffer has been reduced from 30 to 15. This ensures that the maximum possible length of the string being written into the buffer will not exceed its size, thus preventing potential buffer overflow and truncation issues. Fixes the below with gcc W=1: drivers/gpu/drm/amd/amdgpu/gfx_v9_4_3.c: In function ‘gfx_v9_4_3_early_init’: drivers/gpu/drm/amd/amdgpu/gfx_v9_4_3.c:379:52: warning: ‘%s’ directive output may be truncated writing up to 29 bytes into a region of size 23 [-Wformat-truncation=] 379 | snprintf(fw_name, sizeof(fw_name), "amdgpu/%s_rlc.bin", chip_name); | ^~ ...... 439 | r = gfx_v9_4_3_init_rlc_microcode(adev, ucode_prefix); | ~~~~~~~~~~~~ drivers/gpu/drm/amd/amdgpu/gfx_v9_4_3.c:379:9: note: ‘snprintf’ output between 16 and 45 bytes into a destination of size 30 379 | snprintf(fw_name, sizeof(fw_name), "amdgpu/%s_rlc.bin", chip_name); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/gpu/drm/amd/amdgpu/gfx_v9_4_3.c:413:52: warning: ‘%s’ directive output may be truncated writing up to 29 bytes into a region of size 23 [-Wformat-truncation=] 413 | snprintf(fw_name, sizeof(fw_name), "amdgpu/%s_mec.bin", chip_name); | ^~ ...... 443 | r = gfx_v9_4_3_init_cp_compute_microcode(adev, ucode_prefix); | ~~~~~~~~~~~~ drivers/gpu/drm/amd/amdgpu/gfx_v9_4_3.c:413:9: note: ‘snprintf’ output between 16 and 45 bytes into a destination of size 30 413 | snprintf(fw_name, sizeof(fw_name), "amdgpu/%s_mec.bin", chip_name); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In the Linux kernel, the following vulnerability has been resolved: mm/memory-failure: fix handling of dissolved but not taken off from buddy pages When I did memory failure tests recently, below panic occurs: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x8cee00 flags: 0x6fffe0000000000(node=1|zone=2|lastcpupid=0x7fff) raw: 06fffe0000000000 dead000000000100 dead000000000122 0000000000000000 raw: 0000000000000000 0000000000000009 00000000ffffffff 0000000000000000 page dumped because: VM_BUG_ON_PAGE(!PageBuddy(page)) ------------[ cut here ]------------ kernel BUG at include/linux/page-flags.h:1009! invalid opcode: 0000 [#1] PREEMPT SMP NOPTI RIP: 0010:__del_page_from_free_list+0x151/0x180 RSP: 0018:ffffa49c90437998 EFLAGS: 00000046 RAX: 0000000000000035 RBX: 0000000000000009 RCX: ffff8dd8dfd1c9c8 RDX: 0000000000000000 RSI: 0000000000000027 RDI: ffff8dd8dfd1c9c0 RBP: ffffd901233b8000 R08: ffffffffab5511f8 R09: 0000000000008c69 R10: 0000000000003c15 R11: ffffffffab5511f8 R12: ffff8dd8fffc0c80 R13: 0000000000000001 R14: ffff8dd8fffc0c80 R15: 0000000000000009 FS: 00007ff916304740(0000) GS:ffff8dd8dfd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000055eae50124c8 CR3: 00000008479e0000 CR4: 00000000000006f0 Call Trace: <TASK> __rmqueue_pcplist+0x23b/0x520 get_page_from_freelist+0x26b/0xe40 __alloc_pages_noprof+0x113/0x1120 __folio_alloc_noprof+0x11/0xb0 alloc_buddy_hugetlb_folio.isra.0+0x5a/0x130 __alloc_fresh_hugetlb_folio+0xe7/0x140 alloc_pool_huge_folio+0x68/0x100 set_max_huge_pages+0x13d/0x340 hugetlb_sysctl_handler_common+0xe8/0x110 proc_sys_call_handler+0x194/0x280 vfs_write+0x387/0x550 ksys_write+0x64/0xe0 do_syscall_64+0xc2/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7ff916114887 RSP: 002b:00007ffec8a2fd78 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 000055eae500e350 RCX: 00007ff916114887 RDX: 0000000000000004 RSI: 000055eae500e390 RDI: 0000000000000003 RBP: 000055eae50104c0 R08: 0000000000000000 R09: 000055eae50104c0 R10: 0000000000000077 R11: 0000000000000246 R12: 0000000000000004 R13: 0000000000000004 R14: 00007ff916216b80 R15: 00007ff916216a00 </TASK> Modules linked in: mce_inject hwpoison_inject ---[ end trace 0000000000000000 ]--- And before the panic, there had an warning about bad page state: BUG: Bad page state in process page-types pfn:8cee00 page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x8cee00 flags: 0x6fffe0000000000(node=1|zone=2|lastcpupid=0x7fff) page_type: 0xffffff7f(buddy) raw: 06fffe0000000000 ffffd901241c0008 ffffd901240f8008 0000000000000000 raw: 0000000000000000 0000000000000009 00000000ffffff7f 0000000000000000 page dumped because: nonzero mapcount Modules linked in: mce_inject hwpoison_inject CPU: 8 PID: 154211 Comm: page-types Not tainted 6.9.0-rc4-00499-g5544ec3178e2-dirty #22 Call Trace: <TASK> dump_stack_lvl+0x83/0xa0 bad_page+0x63/0xf0 free_unref_page+0x36e/0x5c0 unpoison_memory+0x50b/0x630 simple_attr_write_xsigned.constprop.0.isra.0+0xb3/0x110 debugfs_attr_write+0x42/0x60 full_proxy_write+0x5b/0x80 vfs_write+0xcd/0x550 ksys_write+0x64/0xe0 do_syscall_64+0xc2/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f189a514887 RSP: 002b:00007ffdcd899718 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f189a514887 RDX: 0000000000000009 RSI: 00007ffdcd899730 RDI: 0000000000000003 RBP: 00007ffdcd8997a0 R08: 0000000000000000 R09: 00007ffdcd8994b2 R10: 0000000000000000 R11: 0000000000000246 R12: 00007ffdcda199a8 R13: 0000000000404af1 R14: 000000000040ad78 R15: 00007f189a7a5040 </TASK> The root cause should be the below race: memory_failure try_memory_failure_hugetlb me_huge_page __page_handle_poison dissolve_free_hugetlb_folio drain_all_pages -- Buddy page can be isolated e.g. for compaction. take_page_off_buddy -- Failed as page is not in the ---truncated---
A flaw was found in the Linux kernel's `drm/amdgpu` component. This vulnerability, caused by an out-of-bounds read in the `sdma_v4_0_irq_id_to_seq` function, could allow a local attacker to read sensitive information from kernel memory. This could lead to information disclosure or a denial of service (DoS) due to a system crash.
In the Linux kernel, the following vulnerability has been resolved: ASoC: SOF: ipc4-topology: Fix input format query of process modules without base extension If a process module does not have base config extension then the same format applies to all of it's inputs and the process->base_config_ext is NULL, causing NULL dereference when specifically crafted topology and sequences used.
In the Linux kernel, the following vulnerability has been resolved: mm/vmalloc: fix vmalloc which may return null if called with __GFP_NOFAIL commit a421ef303008 ("mm: allow !GFP_KERNEL allocations for kvmalloc") includes support for __GFP_NOFAIL, but it presents a conflict with commit dd544141b9eb ("vmalloc: back off when the current task is OOM-killed"). A possible scenario is as follows: process-a __vmalloc_node_range(GFP_KERNEL | __GFP_NOFAIL) __vmalloc_area_node() vm_area_alloc_pages() --> oom-killer send SIGKILL to process-a if (fatal_signal_pending(current)) break; --> return NULL; To fix this, do not check fatal_signal_pending() in vm_area_alloc_pages() if __GFP_NOFAIL set. This issue occurred during OPLUS KASAN TEST. Below is part of the log -> oom-killer sends signal to process [65731.222840] [ T1308] oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0,global_oom,task_memcg=/apps/uid_10198,task=gs.intelligence,pid=32454,uid=10198 [65731.259685] [T32454] Call trace: [65731.259698] [T32454] dump_backtrace+0xf4/0x118 [65731.259734] [T32454] show_stack+0x18/0x24 [65731.259756] [T32454] dump_stack_lvl+0x60/0x7c [65731.259781] [T32454] dump_stack+0x18/0x38 [65731.259800] [T32454] mrdump_common_die+0x250/0x39c [mrdump] [65731.259936] [T32454] ipanic_die+0x20/0x34 [mrdump] [65731.260019] [T32454] atomic_notifier_call_chain+0xb4/0xfc [65731.260047] [T32454] notify_die+0x114/0x198 [65731.260073] [T32454] die+0xf4/0x5b4 [65731.260098] [T32454] die_kernel_fault+0x80/0x98 [65731.260124] [T32454] __do_kernel_fault+0x160/0x2a8 [65731.260146] [T32454] do_bad_area+0x68/0x148 [65731.260174] [T32454] do_mem_abort+0x151c/0x1b34 [65731.260204] [T32454] el1_abort+0x3c/0x5c [65731.260227] [T32454] el1h_64_sync_handler+0x54/0x90 [65731.260248] [T32454] el1h_64_sync+0x68/0x6c [65731.260269] [T32454] z_erofs_decompress_queue+0x7f0/0x2258 --> be->decompressed_pages = kvcalloc(be->nr_pages, sizeof(struct page *), GFP_KERNEL | __GFP_NOFAIL); kernel panic by NULL pointer dereference. erofs assume kvmalloc with __GFP_NOFAIL never return NULL. [65731.260293] [T32454] z_erofs_runqueue+0xf30/0x104c [65731.260314] [T32454] z_erofs_readahead+0x4f0/0x968 [65731.260339] [T32454] read_pages+0x170/0xadc [65731.260364] [T32454] page_cache_ra_unbounded+0x874/0xf30 [65731.260388] [T32454] page_cache_ra_order+0x24c/0x714 [65731.260411] [T32454] filemap_fault+0xbf0/0x1a74 [65731.260437] [T32454] __do_fault+0xd0/0x33c [65731.260462] [T32454] handle_mm_fault+0xf74/0x3fe0 [65731.260486] [T32454] do_mem_abort+0x54c/0x1b34 [65731.260509] [T32454] el0_da+0x44/0x94 [65731.260531] [T32454] el0t_64_sync_handler+0x98/0xb4 [65731.260553] [T32454] el0t_64_sync+0x198/0x19c
In the Linux kernel, the following vulnerability has been resolved: drm/i915/hwmon: Get rid of devm When both hwmon and hwmon drvdata (on which hwmon depends) are device managed resources, the expectation, on device unbind, is that hwmon will be released before drvdata. However, in i915 there are two separate code paths, which both release either drvdata or hwmon and either can be released before the other. These code paths (for device unbind) are as follows (see also the bug referenced below): Call Trace: release_nodes+0x11/0x70 devres_release_group+0xb2/0x110 component_unbind_all+0x8d/0xa0 component_del+0xa5/0x140 intel_pxp_tee_component_fini+0x29/0x40 [i915] intel_pxp_fini+0x33/0x80 [i915] i915_driver_remove+0x4c/0x120 [i915] i915_pci_remove+0x19/0x30 [i915] pci_device_remove+0x32/0xa0 device_release_driver_internal+0x19c/0x200 unbind_store+0x9c/0xb0 and Call Trace: release_nodes+0x11/0x70 devres_release_all+0x8a/0xc0 device_unbind_cleanup+0x9/0x70 device_release_driver_internal+0x1c1/0x200 unbind_store+0x9c/0xb0 This means that in i915, if use devm, we cannot gurantee that hwmon will always be released before drvdata. Which means that we have a uaf if hwmon sysfs is accessed when drvdata has been released but hwmon hasn't. The only way out of this seems to be do get rid of devm_ and release/free everything explicitly during device unbind. v2: Change commit message and other minor code changes v3: Cleanup from i915_hwmon_register on error (Armin Wolf) v4: Eliminate potential static analyzer warning (Rodrigo) Eliminate fetch_and_zero (Jani) v5: Restore previous logic for ddat_gt->hwmon_dev error return (Andi)
A race condition was found in the Linux kernel. The rm_file_update_pid() only increments the refcount of a struct pid after storing a pointer to it in filp->pid, dropping the dev->filelist_mutex, resulting in a use-after-free vulnerability.
In the Linux kernel, the following vulnerability has been resolved: arm64: asm-bug: Add .align 2 to the end of __BUG_ENTRY When CONFIG_DEBUG_BUGVERBOSE=n, we fail to add necessary padding bytes to bug_table entries, and as a result the last entry in a bug table will be ignored, potentially leading to an unexpected panic(). All prior entries in the table will be handled correctly. The arm64 ABI requires that struct fields of up to 8 bytes are naturally-aligned, with padding added within a struct such that struct are suitably aligned within arrays. When CONFIG_DEBUG_BUGVERPOSE=y, the layout of a bug_entry is: struct bug_entry { signed int bug_addr_disp; // 4 bytes signed int file_disp; // 4 bytes unsigned short line; // 2 bytes unsigned short flags; // 2 bytes } ... with 12 bytes total, requiring 4-byte alignment. When CONFIG_DEBUG_BUGVERBOSE=n, the layout of a bug_entry is: struct bug_entry { signed int bug_addr_disp; // 4 bytes unsigned short flags; // 2 bytes < implicit padding > // 2 bytes } ... with 8 bytes total, with 6 bytes of data and 2 bytes of trailing padding, requiring 4-byte alginment. When we create a bug_entry in assembly, we align the start of the entry to 4 bytes, which implicitly handles padding for any prior entries. However, we do not align the end of the entry, and so when CONFIG_DEBUG_BUGVERBOSE=n, the final entry lacks the trailing padding bytes. For the main kernel image this is not a problem as find_bug() doesn't depend on the trailing padding bytes when searching for entries: for (bug = __start___bug_table; bug < __stop___bug_table; ++bug) if (bugaddr == bug_addr(bug)) return bug; However for modules, module_bug_finalize() depends on the trailing bytes when calculating the number of entries: mod->num_bugs = sechdrs[i].sh_size / sizeof(struct bug_entry); ... and as the last bug_entry lacks the necessary padding bytes, this entry will not be counted, e.g. in the case of a single entry: sechdrs[i].sh_size == 6 sizeof(struct bug_entry) == 8; sechdrs[i].sh_size / sizeof(struct bug_entry) == 0; Consequently module_find_bug() will miss the last bug_entry when it does: for (i = 0; i < mod->num_bugs; ++i, ++bug) if (bugaddr == bug_addr(bug)) goto out; ... which can lead to a kenrel panic due to an unhandled bug. This can be demonstrated with the following module: static int __init buginit(void) { WARN(1, "hello\n"); return 0; } static void __exit bugexit(void) { } module_init(buginit); module_exit(bugexit); MODULE_LICENSE("GPL"); ... which will trigger a kernel panic when loaded: ------------[ cut here ]------------ hello Unexpected kernel BRK exception at EL1 Internal error: BRK handler: 00000000f2000800 [#1] PREEMPT SMP Modules linked in: hello(O+) CPU: 0 PID: 50 Comm: insmod Tainted: G O 6.9.1 #8 Hardware name: linux,dummy-virt (DT) pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : buginit+0x18/0x1000 [hello] lr : buginit+0x18/0x1000 [hello] sp : ffff800080533ae0 x29: ffff800080533ae0 x28: 0000000000000000 x27: 0000000000000000 x26: ffffaba8c4e70510 x25: ffff800080533c30 x24: ffffaba8c4a28a58 x23: 0000000000000000 x22: 0000000000000000 x21: ffff3947c0eab3c0 x20: ffffaba8c4e3f000 x19: ffffaba846464000 x18: 0000000000000006 x17: 0000000000000000 x16: ffffaba8c2492834 x15: 0720072007200720 x14: 0720072007200720 x13: ffffaba8c49b27c8 x12: 0000000000000312 x11: 0000000000000106 x10: ffffaba8c4a0a7c8 x9 : ffffaba8c49b27c8 x8 : 00000000ffffefff x7 : ffffaba8c4a0a7c8 x6 : 80000000fffff000 x5 : 0000000000000107 x4 : 0000000000000000 x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff3947c0eab3c0 Call trace: buginit+0x18/0x1000 [hello] do_one_initcall+0x80/0x1c8 do_init_module+0x60/0x218 load_module+0x1ba4/0x1d70 __do_sys_init_module+0x198/0x1d0 __arm64_sys_init_module+0x1c/0x28 invoke_syscall+0x48/0x114 el0_svc ---truncated---
A flaw was found in the Linux kernel's HDA driver before initialization. This issue occurs when a user unloads and then reloads the module, and could allow a local user to crash the system.
In the Linux kernel, the following vulnerability has been resolved: drm/shmem-helper: Fix BUG_ON() on mmap(PROT_WRITE, MAP_PRIVATE) Lack of check for copy-on-write (COW) mapping in drm_gem_shmem_mmap allows users to call mmap with PROT_WRITE and MAP_PRIVATE flag causing a kernel panic due to BUG_ON in vmf_insert_pfn_prot: BUG_ON((vma->vm_flags & VM_PFNMAP) && is_cow_mapping(vma->vm_flags)); Return -EINVAL early if COW mapping is detected. This bug affects all drm drivers using default shmem helpers. It can be reproduced by this simple example: void *ptr = mmap(0, size, PROT_WRITE, MAP_PRIVATE, fd, mmap_offset); ptr[0] = 0;
In the Linux kernel, the following vulnerability has been resolved: drm/mst: Fix NULL pointer dereference at drm_dp_add_payload_part2 [Why] Commit: - commit 5aa1dfcdf0a4 ("drm/mst: Refactor the flow for payload allocation/removement") accidently overwrite the commit - commit 54d217406afe ("drm: use mgr->dev in drm_dbg_kms in drm_dp_add_payload_part2") which cause regression. [How] Recover the original NULL fix and remove the unnecessary input parameter 'state' for drm_dp_add_payload_part2(). (cherry picked from commit 4545614c1d8da603e57b60dd66224d81b6ffc305)
A vulnerability was found in the event_deliver() function in the Linux kernel's VMCI component, where the issue involves a lack of sanitization for the event_data.event index controlled by user-space, which could lead to speculative information leaks.
This CVE has been marked as Rejected by the assigning CNA.
In the Linux kernel, the following vulnerability has been resolved: netfilter: ipset: Fix race between namespace cleanup and gc in the list:set type Lion Ackermann reported that there is a race condition between namespace cleanup in ipset and the garbage collection of the list:set type. The namespace cleanup can destroy the list:set type of sets while the gc of the set type is waiting to run in rcu cleanup. The latter uses data from the destroyed set which thus leads use after free. The patch contains the following parts: - When destroying all sets, first remove the garbage collectors, then wait if needed and then destroy the sets. - Fix the badly ordered "wait then remove gc" for the destroy a single set case. - Fix the missing rcu locking in the list:set type in the userspace test case. - Use proper RCU list handlings in the list:set type. The patch depends on c1193d9bbbd3 (netfilter: ipset: Add list flush to cancel_gc).
In the Linux kernel, the following vulnerability has been resolved: net: hns3: fix kernel crash problem in concurrent scenario When link status change, the nic driver need to notify the roce driver to handle this event, but at this time, the roce driver may uninit, then cause kernel crash. To fix the problem, when link status change, need to check whether the roce registered, and when uninit, need to wait link update finish.
A vulnerability was found in the Linux kernel's io_uring subsystem within the io_wq handling functions, where the issue stems from concurrent access to worker->flags, which can lead to data races when multiple tasks manipulate this structure simultaneously, which result in crashes, impacting the reliability of asynchronous I/O operations.
In the Linux kernel, the following vulnerability has been resolved: scsi: mpt3sas: Avoid test/set_bit() operating in non-allocated memory There is a potential out-of-bounds access when using test_bit() on a single word. The test_bit() and set_bit() functions operate on long values, and when testing or setting a single word, they can exceed the word boundary. KASAN detects this issue and produces a dump: BUG: KASAN: slab-out-of-bounds in _scsih_add_device.constprop.0 (./arch/x86/include/asm/bitops.h:60 ./include/asm-generic/bitops/instrumented-atomic.h:29 drivers/scsi/mpt3sas/mpt3sas_scsih.c:7331) mpt3sas Write of size 8 at addr ffff8881d26e3c60 by task kworker/u1536:2/2965 For full log, please look at [1]. Make the allocation at least the size of sizeof(unsigned long) so that set_bit() and test_bit() have sufficient room for read/write operations without overwriting unallocated memory. [1] Link: https://lore.kernel.org/all/ZkNcALr3W3KGYYJG@gmail.com/
A vulnerability was found in the tcpm_register_source_caps function in the Linux kernel's USB Type-C TCPM component. This issue arises when new, potentially invalid source capabilities are advertised while existing capabilities are unregistered, leading to a use-after-free condition if the registration fails.
A vulnerability was found in the Linux kernel's mlx5 driver, in the driver removal process where the teardown_hca function can fail, where the health timer may continue running, leading to a use-after-free condition when the timer attempts to access freed resources.
A vulnerability was found in the Linux kernel's ionic driver, in the XDP_TX action, where the driver sends a packet using a received page that is subsequently freed, if the RX ring buffer is not reset to NULL after this operation, it results in a use of a freed page, leading to a kernel panic.
A vulnerability was found in the Linux kernel's cachefiles component, regarding the handling of anonymous file descriptors. This issue occurs when an anonymous fd is exposed to userland before confirming the success of the copy_to_user() operation, which can lead to a use-after-free condition.
In the Linux kernel, the following vulnerability has been resolved: bnxt_en: Adjust logging of firmware messages in case of released token in __hwrm_send() In case of token is released due to token->state == BNXT_HWRM_DEFERRED, released token (set to NULL) is used in log messages. This issue is expected to be prevented by HWRM_ERR_CODE_PF_UNAVAILABLE error code. But this error code is returned by recent firmware. So some firmware may not return it. This may lead to NULL pointer dereference. Adjust this issue by adding token pointer check. Found by Linux Verification Center (linuxtesting.org) with SVACE.
In the Linux kernel, the following vulnerability has been resolved: io_uring/rsrc: don't lock while !TASK_RUNNING There is a report of io_rsrc_ref_quiesce() locking a mutex while not TASK_RUNNING, which is due to forgetting restoring the state back after io_run_task_work_sig() and attempts to break out of the waiting loop. do not call blocking ops when !TASK_RUNNING; state=1 set at [<ffffffff815d2494>] prepare_to_wait+0xa4/0x380 kernel/sched/wait.c:237 WARNING: CPU: 2 PID: 397056 at kernel/sched/core.c:10099 __might_sleep+0x114/0x160 kernel/sched/core.c:10099 RIP: 0010:__might_sleep+0x114/0x160 kernel/sched/core.c:10099 Call Trace: <TASK> __mutex_lock_common kernel/locking/mutex.c:585 [inline] __mutex_lock+0xb4/0x940 kernel/locking/mutex.c:752 io_rsrc_ref_quiesce+0x590/0x940 io_uring/rsrc.c:253 io_sqe_buffers_unregister+0xa2/0x340 io_uring/rsrc.c:799 __io_uring_register io_uring/register.c:424 [inline] __do_sys_io_uring_register+0x5b9/0x2400 io_uring/register.c:613 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xd8/0x270 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x6f/0x77
A vulnerability was found in the Linux kernel's vmxnet3 driver in the vmxnet3_rq_create() function, where this issue occurs when memory allocation fails for the RX data ring, leading to an improper reference size that may cause the hypervisor to access invalid memory during packet reception, which can result in kernel crashes.
In the Linux kernel, the following vulnerability has been resolved: drm/i915/dpt: Make DPT object unshrinkable In some scenarios, the DPT object gets shrunk but the actual framebuffer did not and thus its still there on the DPT's vm->bound_list. Then it tries to rewrite the PTEs via a stale CPU mapping. This causes panic. [vsyrjala: Add TODO comment] (cherry picked from commit 51064d471c53dcc8eddd2333c3f1c1d9131ba36c)
A vulnerability was found in the Linux kernel's block subsystem, where the issue arises when the request queue list is not properly initialized for the first request in the PREFLUSH/POSTFLUSH sequences, leading to potential kernel crashes due to improper list manipulation.
A vulnerability was found in the Linux kernel's cfg80211 component, related to the parsing of HE operation elements, where the issue occurs when the length of the HE operation element is not validated before parsing, potentially leading to buffer overflows or undefined behavior.
In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Fix tainted pointer delete is case of flow rules creation fail In case of flow rule creation fail in mlx5_lag_create_port_sel_table(), instead of previously created rules, the tainted pointer is deleted deveral times. Fix this bug by using correct flow rules pointers. Found by Linux Verification Center (linuxtesting.org) with SVACE.
In the Linux kernel, the following vulnerability has been resolved: iommu: Return right value in iommu_sva_bind_device() iommu_sva_bind_device() should return either a sva bond handle or an ERR_PTR value in error cases. Existing drivers (idxd and uacce) only check the return value with IS_ERR(). This could potentially lead to a kernel NULL pointer dereference issue if the function returns NULL instead of an error pointer. In reality, this doesn't cause any problems because iommu_sva_bind_device() only returns NULL when the kernel is not configured with CONFIG_IOMMU_SVA. In this case, iommu_dev_enable_feature(dev, IOMMU_DEV_FEAT_SVA) will return an error, and the device drivers won't call iommu_sva_bind_device() at all.
A vulnerability was found in the Linux kernel's mm/page_table_check component, specifically related to ZONE_DEVICE pages. When page-table-check is enabled, attempting to map DAX memory can lead to a kernel crash due to invalid checks on these pages, which do not allocate page_ext.
A vulnerability was found in the lpi2c driver in the Linux kernel's i2c subsystem, where the clk_get_rate function is called during data transfers, which can lead to a deadlock situation when an audio codec attempts to access the i2c bus while holding the clock mutex, resulting in a denial of service.
A vulnerability was found in the Linux kernel's TTY subsystem, where the option to reject a new ldisc was improperly implemented, which can lead to a situation where the con_write() routine is called while holding a spinlock, potentially causing a sleep operation in an invalid context.
A vulnerability was found in the Linux kernel's imx serial driver, where the system could experience DoS while waiting for the transmitter to become empty, without a timeout mechanism, the code risks entering a deadlock situation if the USR2_TXDC signal is not set.
A vulnerability was found in the Linux kernel's DRM/Radeon driver, specifically in the sumo_vid_mapping_entry within the kv_dpm.c file. Insufficient bounds checking can lead to memory corruption.
A vulnerability was found in the Linux kernel's KVM for ARM64 within the vgic-init.c, vgic-mmio-v3.c, and vgic.h files. The virtual vCPUs may retain dangling pointers in a redistributor region after they have been torn down, leading to potential memory corruption.
In the Linux kernel, the following vulnerability has been resolved: cpufreq: amd-pstate: fix memory leak on CPU EPP exit The cpudata memory from kzalloc() in amd_pstate_epp_cpu_init() is not freed in the analogous exit function, so fix that. [ rjw: Subject and changelog edits ]
In the Linux kernel, the following vulnerability has been resolved: io_uring/sqpoll: work around a potential audit memory leak kmemleak complains that there's a memory leak related to connect handling: unreferenced object 0xffff0001093bdf00 (size 128): comm "iou-sqp-455", pid 457, jiffies 4294894164 hex dump (first 32 bytes): 02 00 fa ea 7f 00 00 01 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace (crc 2e481b1a): [<00000000c0a26af4>] kmemleak_alloc+0x30/0x38 [<000000009c30bb45>] kmalloc_trace+0x228/0x358 [<000000009da9d39f>] __audit_sockaddr+0xd0/0x138 [<0000000089a93e34>] move_addr_to_kernel+0x1a0/0x1f8 [<000000000b4e80e6>] io_connect_prep+0x1ec/0x2d4 [<00000000abfbcd99>] io_submit_sqes+0x588/0x1e48 [<00000000e7c25e07>] io_sq_thread+0x8a4/0x10e4 [<00000000d999b491>] ret_from_fork+0x10/0x20 which can can happen if: 1) The command type does something on the prep side that triggers an audit call. 2) The thread hasn't done any operations before this that triggered an audit call inside ->issue(), where we have audit_uring_entry() and audit_uring_exit(). Work around this by issuing a blanket NOP operation before the SQPOLL does anything.
A vulnerability was found in the tcp_retransmit_timer function in the Linux kernel's TCP implementation. This issue occurs when a TCP socket uses TCP_USER_TIMEOUT and the peer's window retracts to zero, leading to excessive retransmission of packets every two milliseconds for up to four minutes after the timeout, which can result in network congestion and performance degradation.
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: change vm->task_info handling This patch changes the handling and lifecycle of vm->task_info object. The major changes are: - vm->task_info is a dynamically allocated ptr now, and its uasge is reference counted. - introducing two new helper funcs for task_info lifecycle management - amdgpu_vm_get_task_info: reference counts up task_info before returning this info - amdgpu_vm_put_task_info: reference counts down task_info - last put to task_info() frees task_info from the vm. This patch also does logistical changes required for existing usage of vm->task_info. V2: Do not block all the prints when task_info not found (Felix) V3: Fixed review comments from Felix - Fix wrong indentation - No debug message for -ENOMEM - Add NULL check for task_info - Do not duplicate the debug messages (ti vs no ti) - Get first reference of task_info in vm_init(), put last in vm_fini() V4: Fixed review comments from Felix - fix double reference increment in create_task_info - change amdgpu_vm_get_task_info_pasid - additional changes in amdgpu_gem.c while porting
In the Linux kernel, the following vulnerability has been resolved: filelock: Remove locks reliably when fcntl/close race is detected When fcntl_setlk() races with close(), it removes the created lock with do_lock_file_wait(). However, LSMs can allow the first do_lock_file_wait() that created the lock while denying the second do_lock_file_wait() that tries to remove the lock. Separately, posix_lock_file() could also fail to remove a lock due to GFP_KERNEL allocation failure (when splitting a range in the middle). After the bug has been triggered, use-after-free reads will occur in lock_get_status() when userspace reads /proc/locks. This can likely be used to read arbitrary kernel memory, but can't corrupt kernel memory. Fix it by calling locks_remove_posix() instead, which is designed to reliably get rid of POSIX locks associated with the given file and files_struct and is also used by filp_flush().
A vulnerability was found in the Linux kernel in the fcntl_setlk64() function where a potential race condition can be triggered when a file descriptor is closed during a fcntl operation's execution. This can lead to system instability or crashes.
A vulnerability was found in the Linux kernel that involves improper handling of per-CPU data in systems where cpu_possible_mask has gaps between CPUs. This can lead to an index which accesses non-existent or unset CPU areas and potentially causes kernel crashes.
A vulnerability was found in the Linux kernel in the cs_dsp firmware involving the V2 algorithm headers and the wmfw V2 format, which introduced variable-length strings into the algorithm block header. This means the overall header length is variable and without proper checks can result in an overflow of the firmware data buffer, leading to memory overwrite and potential system instability.
A vulnerability was found in the Linux kernel's firmware driver cs_dsp.c, where a buffer overflow is possible in the wmfw header due to insufficient buffer size checks. The issue stems from the size of one of the structs that the code checks, the wmfw_adsp?_sizes struct, which can vary depending on whether the firmware used is ADSP1 or ADSP2 and Halo Core. In the second case, the wmfw_adsp2_sizes struct is 4 bytes longer, which can cause a buffer overflow, potentially leading to undefined behavior in the system.
In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: prefer nft_chain_validate nft_chain_validate already performs loop detection because a cycle will result in a call stack overflow (ctx->level >= NFT_JUMP_STACK_SIZE). It also follows maps via ->validate callback in nft_lookup, so there appears no reason to iterate the maps again. nf_tables_check_loops() and all its helper functions can be removed. This improves ruleset load time significantly, from 23s down to 12s. This also fixes a crash bug. Old loop detection code can result in unbounded recursion: BUG: TASK stack guard page was hit at .... Oops: stack guard page: 0000 [#1] PREEMPT SMP KASAN CPU: 4 PID: 1539 Comm: nft Not tainted 6.10.0-rc5+ #1 [..] with a suitable ruleset during validation of register stores. I can't see any actual reason to attempt to check for this from nft_validate_register_store(), at this point the transaction is still in progress, so we don't have a full picture of the rule graph. For nf-next it might make sense to either remove it or make this depend on table->validate_state in case we could catch an error earlier (for improved error reporting to userspace).
A use-after-free vulnerability was found in the Linux kernel in trace_posix_lock_inode(). This issue occurred when the request pointer was changed to point to a lock entry added to the inode's list. Before the tracepoint could fire, another task raced in and freed the lock.
A buffer overrun flaw exists in the Linux kernel when the strlen function is used on name fields in V1 wmfw files. This issue results in a loss of system availability.
A potential use after free was found in the Linux kernel.
A slab-use-after-free was found in fscache_withdraw_volume() in the Linux kernel.
In the Linux kernel, the following vulnerability has been resolved: drm/radeon: check bo_va->bo is non-NULL before using it The call to radeon_vm_clear_freed might clear bo_va->bo, so we have to check it before dereferencing it.
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_core: cancel all works upon hci_unregister_dev() syzbot is reporting that calling hci_release_dev() from hci_error_reset() due to hci_dev_put() from hci_error_reset() can cause deadlock at destroy_workqueue(), for hci_error_reset() is called from hdev->req_workqueue which destroy_workqueue() needs to flush. We need to make sure that hdev->{rx_work,cmd_work,tx_work} which are queued into hdev->workqueue and hdev->{power_on,error_reset} which are queued into hdev->req_workqueue are no longer running by the moment destroy_workqueue(hdev->workqueue); destroy_workqueue(hdev->req_workqueue); are called from hci_release_dev(). Call cancel_work_sync() on these work items from hci_unregister_dev() as soon as hdev->list is removed from hci_dev_list.
In the Linux kernel, the following vulnerability has been resolved: powerpc/pseries: Whitelist dtl slub object for copying to userspace Reading the dispatch trace log from /sys/kernel/debug/powerpc/dtl/cpu-* results in a BUG() when the config CONFIG_HARDENED_USERCOPY is enabled as shown below. kernel BUG at mm/usercopy.c:102! Oops: Exception in kernel mode, sig: 5 [#1] LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA pSeries Modules linked in: xfs libcrc32c dm_service_time sd_mod t10_pi sg ibmvfc scsi_transport_fc ibmveth pseries_wdt dm_multipath dm_mirror dm_region_hash dm_log dm_mod fuse CPU: 27 PID: 1815 Comm: python3 Not tainted 6.10.0-rc3 #85 Hardware name: IBM,9040-MRX POWER10 (raw) 0x800200 0xf000006 of:IBM,FW1060.00 (NM1060_042) hv:phyp pSeries NIP: c0000000005d23d4 LR: c0000000005d23d0 CTR: 00000000006ee6f8 REGS: c000000120c078c0 TRAP: 0700 Not tainted (6.10.0-rc3) MSR: 8000000000029033 <SF,EE,ME,IR,DR,RI,LE> CR: 2828220f XER: 0000000e CFAR: c0000000001fdc80 IRQMASK: 0 [ ... GPRs omitted ... ] NIP [c0000000005d23d4] usercopy_abort+0x78/0xb0 LR [c0000000005d23d0] usercopy_abort+0x74/0xb0 Call Trace: usercopy_abort+0x74/0xb0 (unreliable) __check_heap_object+0xf8/0x120 check_heap_object+0x218/0x240 __check_object_size+0x84/0x1a4 dtl_file_read+0x17c/0x2c4 full_proxy_read+0x8c/0x110 vfs_read+0xdc/0x3a0 ksys_read+0x84/0x144 system_call_exception+0x124/0x330 system_call_vectored_common+0x15c/0x2ec --- interrupt: 3000 at 0x7fff81f3ab34 Commit 6d07d1cd300f ("usercopy: Restrict non-usercopy caches to size 0") requires that only whitelisted areas in slab/slub objects can be copied to userspace when usercopy hardening is enabled using CONFIG_HARDENED_USERCOPY. Dtl contains hypervisor dispatch events which are expected to be read by privileged users. Hence mark this safe for user access. Specify useroffset=0 and usersize=DISPATCH_LOG_BYTES to whitelist the entire object.
In the Linux kernel, the following vulnerability has been resolved: null_blk: fix validation of block size Block size should be between 512 and PAGE_SIZE and be a power of 2. The current check does not validate this, so update the check. Without this patch, null_blk would Oops due to a null pointer deref when loaded with bs=1536 [1]. [axboe: remove unnecessary braces and != 0 check]
In the Linux kernel, the following vulnerability has been resolved: nvmet: always initialize cqe.result The spec doesn't mandate that the first two double words (aka results) for the command queue entry need to be set to 0 when they are not used (not specified). Though, the target implemention returns 0 for TCP and FC but not for RDMA. Let's make RDMA behave the same and thus explicitly initializing the result field. This prevents leaking any data from the stack.
In the Linux kernel, the following vulnerability has been resolved: nvme-fabrics: use reserved tag for reg read/write command In some scenarios, if too many commands are issued by nvme command in the same time by user tasks, this may exhaust all tags of admin_q. If a reset (nvme reset or IO timeout) occurs before these commands finish, reconnect routine may fail to update nvme regs due to insufficient tags, which will cause kernel hang forever. In order to workaround this issue, maybe we can let reg_read32()/reg_read64()/reg_write32() use reserved tags. This maybe safe for nvmf: 1. For the disable ctrl path, we will not issue connect command 2. For the enable ctrl / fw activate path, since connect and reg_xx() are called serially. So the reserved tags may still be enough while reg_xx() use reserved tags.
In the Linux kernel, the following vulnerability has been resolved: cxl/region: Avoid null pointer dereference in region lookup cxl_dpa_to_region() looks up a region based on a memdev and DPA. It wrongly assumes an endpoint found mapping the DPA is also of a fully assembled region. When not true it leads to a null pointer dereference looking up the region name. This appears during testing of region lookup after a failure to assemble a BIOS defined region or if the lookup raced with the assembly of the BIOS defined region. Failure to clean up BIOS defined regions that fail assembly is an issue in itself and a fix to that problem will alleviate some of the impact. It will not alleviate the race condition so let's harden this path. The behavior change is that the kernel oops due to a null pointer dereference is replaced with a dev_dbg() message noting that an endpoint was mapped. Additional comments are added so that future users of this function can more clearly understand what it provides.
In the Linux kernel, the following vulnerability has been resolved: cxl/mem: Fix no cxl_nvd during pmem region auto-assembling When CXL subsystem is auto-assembling a pmem region during cxl endpoint port probing, always hit below calltrace. BUG: kernel NULL pointer dereference, address: 0000000000000078 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page RIP: 0010:cxl_pmem_region_probe+0x22e/0x360 [cxl_pmem] Call Trace: <TASK> ? __die+0x24/0x70 ? page_fault_oops+0x82/0x160 ? do_user_addr_fault+0x65/0x6b0 ? exc_page_fault+0x7d/0x170 ? asm_exc_page_fault+0x26/0x30 ? cxl_pmem_region_probe+0x22e/0x360 [cxl_pmem] ? cxl_pmem_region_probe+0x1ac/0x360 [cxl_pmem] cxl_bus_probe+0x1b/0x60 [cxl_core] really_probe+0x173/0x410 ? __pfx___device_attach_driver+0x10/0x10 __driver_probe_device+0x80/0x170 driver_probe_device+0x1e/0x90 __device_attach_driver+0x90/0x120 bus_for_each_drv+0x84/0xe0 __device_attach+0xbc/0x1f0 bus_probe_device+0x90/0xa0 device_add+0x51c/0x710 devm_cxl_add_pmem_region+0x1b5/0x380 [cxl_core] cxl_bus_probe+0x1b/0x60 [cxl_core] The cxl_nvd of the memdev needs to be available during the pmem region probe. Currently the cxl_nvd is registered after the endpoint port probe. The endpoint probe, in the case of autoassembly of regions, can cause a pmem region probe requiring the not yet available cxl_nvd. Adjust the sequence so this dependency is met. This requires adding a port parameter to cxl_find_nvdimm_bridge() that can be used to query the ancestor root port. The endpoint port is not yet available, but will share a common ancestor with its parent, so start the query from there instead.
A flaw was found in the nouveau driver module of the Linux kernel in which certain TV tuner cards can cause a null pointer dereference when querying the capabilities of some displays, resulting in a denial of service.
A use-after-free was found in drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c in the Linux kernel. This issue can be caused by a race among revocation of fence registers on one side and sequential execution of signal callbacks invoked on completion of a request that was using them on the other, processed in parallel to revocation of those fence registers.
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: avoid using null object of framebuffer Instead of using state->fb->obj[0] directly, get object from framebuffer by calling drm_gem_fb_get_obj() and return error code when object is null to avoid using null object of framebuffer.
In the Linux kernel, the following vulnerability has been resolved: drm/fbdev-dma: Only set smem_start is enable per module option Only export struct fb_info.fix.smem_start if that is required by the user and the memory does not come from vmalloc(). Setting struct fb_info.fix.smem_start breaks systems where DMA memory is backed by vmalloc address space. An example error is shown below. [ 3.536043] ------------[ cut here ]------------ [ 3.540716] virt_to_phys used for non-linear address: 000000007fc4f540 (0xffff800086001000) [ 3.552628] WARNING: CPU: 4 PID: 61 at arch/arm64/mm/physaddr.c:12 __virt_to_phys+0x68/0x98 [ 3.565455] Modules linked in: [ 3.568525] CPU: 4 PID: 61 Comm: kworker/u12:5 Not tainted 6.6.23-06226-g4986cc3e1b75-dirty #250 [ 3.577310] Hardware name: NXP i.MX95 19X19 board (DT) [ 3.582452] Workqueue: events_unbound deferred_probe_work_func [ 3.588291] pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 3.595233] pc : __virt_to_phys+0x68/0x98 [ 3.599246] lr : __virt_to_phys+0x68/0x98 [ 3.603276] sp : ffff800083603990 [ 3.677939] Call trace: [ 3.680393] __virt_to_phys+0x68/0x98 [ 3.684067] drm_fbdev_dma_helper_fb_probe+0x138/0x238 [ 3.689214] __drm_fb_helper_initial_config_and_unlock+0x2b0/0x4c0 [ 3.695385] drm_fb_helper_initial_config+0x4c/0x68 [ 3.700264] drm_fbdev_dma_client_hotplug+0x8c/0xe0 [ 3.705161] drm_client_register+0x60/0xb0 [ 3.709269] drm_fbdev_dma_setup+0x94/0x148 Additionally, DMA memory is assumed to by contiguous in physical address space, which is not guaranteed by vmalloc(). Resolve this by checking the module flag drm_leak_fbdev_smem when DRM allocated the instance of struct fb_info. Fbdev-dma then only sets smem_start only if required (via FBINFO_HIDE_SMEM_START). Also guarantee that the framebuffer is not located in vmalloc address space.
A flaw was found in the Linux kernel’s nouveau module. The return value of the drm_mode_duplicate function is not checked in the nv17_tv_get_ld_modes function in the drivers/gpu/drm/nouveau/dispnv04/tvnv17.c file, possibly causing a NULL pointer dereference and resulting in a denial of service.
In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: fully validate NFT_DATA_VALUE on store to data registers register store validation for NFT_DATA_VALUE is conditional, however, the datatype is always either NFT_DATA_VALUE or NFT_DATA_VERDICT. This only requires a new helper function to infer the register type from the set datatype so this conditional check can be removed. Otherwise, pointer to chain object can be leaked through the registers.
In the Linux kernel, the following vulnerability has been resolved: nfsd: initialise nfsd_info.mutex early. nfsd_info.mutex can be dereferenced by svc_pool_stats_start() immediately after the new netns is created. Currently this can trigger an oops. Move the initialisation earlier before it can possibly be dereferenced.
An unexpected file truncate flaw was found when opening files with specific parameters in the Linux kernel's file-system. This vulnerability allows a local user to corrupt specific files when having access to these files.
A deadlock flaw was found in the Linux kernel’s pinctrl subsystem. This flaw allows a local user to crash the system.
A flaw was found in the Linux kernel’s nouveau module. The return value of the drm_mode_duplicate function is not checked in the nouveau_connector_get_modes function in the drivers/gpu/drm/nouveau/nouveau_connector.c file, possibly causing a NULL pointer dereference and resulting in a denial of service.
A vulnerability was found in the cfg80211 component in the Linux kernel, where a lack of proper range validation applied to the NL80211_ATTR_TXQ_QUANTUM can lead to a scenario where the userspace passes an extremely high value that the kernel is not designed to handle efficiently (ex. 2^31). This can cause soft lockups and system instability.
A vulnerability was found in the amdgpu_umc_handle_bad_pages() function in the Linux kernel's amdgpu driver. If the function is called multiple times in quick succession, a double free error can occur because the err_data->err_addr pointer that is being freed is not being set to NULL in between calls. This could lead to memory corruption or crashes.
A vulnerability was found in the Linux kernel's qedf driver function qedf_execute_tmf(), where the function call smp_processor_id() is done from preemptible code (before acquiring a lock) which can result in BUG_ON() when running an RT kernel. This can result in system inconsistencies.
A vulnerability was found in the Linux kernel's rtw89 driver function rtw89_scan_get_6g_disabled_chan() caused by its handling of 6 GHz band channels during scans. A lack of proper sband checks can lead to a situation where the sband is not available due to device limitations/restrictions set by the BIOS and this leads to a NULL pointer dereference. This can lead to system instability or crashes.
A warning was observed in the Linux kernel in hci_conn_del() caused by freeing handle that was not allocated using ida allocator. This is caused by handle bigger than HCI_CONN_HANDLE_MAX passed by hci_le_big_sync_established_evt(), which makes code think it's unset connection.
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: ISO: Check socket flag instead of hcon This fixes the following Smatch static checker warning: net/bluetooth/iso.c:1364 iso_sock_recvmsg() error: we previously assumed 'pi->conn->hcon' could be null (line 1359) net/bluetooth/iso.c 1347 static int iso_sock_recvmsg(struct socket *sock, struct msghdr *msg, 1348 size_t len, int flags) 1349 { 1350 struct sock *sk = sock->sk; 1351 struct iso_pinfo *pi = iso_pi(sk); 1352 1353 BT_DBG("sk %p", sk); 1354 1355 if (test_and_clear_bit(BT_SK_DEFER_SETUP, &bt_sk(sk)->flags)) { 1356 lock_sock(sk); 1357 switch (sk->sk_state) { 1358 case BT_CONNECT2: 1359 if (pi->conn->hcon && ^^^^^^^^^^^^^^ If ->hcon is NULL 1360 test_bit(HCI_CONN_PA_SYNC, &pi->conn->hcon->flags)) { 1361 iso_conn_big_sync(sk); 1362 sk->sk_state = BT_LISTEN; 1363 } else { --> 1364 iso_conn_defer_accept(pi->conn->hcon); ^^^^^^^^^^^^^^ then we're toast 1365 sk->sk_state = BT_CONFIG; 1366 } 1367 release_sock(sk); 1368 return 0; 1369 case BT_CONNECTED: 1370 if (test_bit(BT_SK_PA_SYNC,
A vulnerability was found in the Linux kernel's tcp_metrics.c, where insufficient validation of the length of the source address for TCP metrics could lead to incorrect memory read (out of boundary read).
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.
In the Linux kernel, the following vulnerability has been resolved: usb: xhci: prevent potential failure in handle_tx_event() for Transfer events without TRB Some transfer events don't always point to a TRB, and consequently don't have a endpoint ring. In these cases, function handle_tx_event() should not proceed, because if 'ep->skip' is set, the pointer to the endpoint ring is used. To prevent a potential failure and make the code logical, return after checking the completion code for a Transfer event without TRBs.
A vulnerability was found in the Linux kernel's amdgpu driver in the amdgpu_vce_ring_parse_cs() function where the size variable is initialized with a pointer that may not be properly set before use. This issue could lead to unpredictable behavior in the system.
In the Linux kernel, the following vulnerability has been resolved: firmware: cs_dsp: Validate payload length before processing block Move the payload length check in cs_dsp_load() and cs_dsp_coeff_load() to be done before the block is processed. The check that the length of a block payload does not exceed the number of remaining bytes in the firwmware file buffer was being done near the end of the loop iteration. However, some code before that check used the length field without validating it.
A denial of service vulnerability was found in the Linux kernel. No error was returned from the cs_dsp_power_up() function if a block header is longer than the amount of data left in the file.
A denial of service vulnerability was found in the Linux kernel. When BHI mitigation is enabled, if SYSENTER is invoked with the TF flag set, then entry_SYSENTER_compat() uses CLEAR_BRANCH_HISTORY and calls the clear_bhb_loop() before the TF flag is cleared. This causes the #DB handler (exc_debug_kernel()) to issue a warning that results in a software crash.
In the Linux kernel, the following vulnerability has been resolved: Revert "sched/fair: Make sure to try to detach at least one movable task" This reverts commit b0defa7ae03ecf91b8bfd10ede430cff12fcbd06. b0defa7ae03ec changed the load balancing logic to ignore env.max_loop if all tasks examined to that point were pinned. The goal of the patch was to make it more likely to be able to detach a task buried in a long list of pinned tasks. However, this has the unfortunate side effect of creating an O(n) iteration in detach_tasks(), as we now must fully iterate every task on a cpu if all or most are pinned. Since this load balance code is done with rq lock held, and often in softirq context, it is very easy to trigger hard lockups. We observed such hard lockups with a user who affined O(10k) threads to a single cpu. When I discussed this with Vincent he initially suggested that we keep the limit on the number of tasks to detach, but increase the number of tasks we can search. However, after some back and forth on the mailing list, he recommended we instead revert the original patch, as it seems likely no one was actually getting hit by the original issue.
In the Linux kernel, the following vulnerability has been resolved: mm: huge_memory: use !CONFIG_64BIT to relax huge page alignment on 32 bit machines Yves-Alexis Perez reported commit 4ef9ad19e176 ("mm: huge_memory: don't force huge page alignment on 32 bit") didn't work for x86_32 [1]. It is because x86_32 uses CONFIG_X86_32 instead of CONFIG_32BIT. !CONFIG_64BIT should cover all 32 bit machines. [1] https://lore.kernel.org/linux-mm/CAHbLzkr1LwH3pcTgM+aGQ31ip2bKqiqEQ8=FQB+t2c3dhNKNHA@mail.gmail.com/
On sync reset reload work, when remote host updates devlink on reload actions performed on that host, it misses taking devlink lock before calling devlink_remote_reload_actions_performed() which results in triggering lock assert. This may lead to a crash.
A possible use-after-free vulnerability was found in the Linux kernel in iucv_sock_close(). This issue may lead to a crash or memory corruption.
nvme-pci in linux kernel does not call nvme_unmap_data for the same instances of nvme_map_data, which can lead to incorrect dereferencing.
An array out-of-bounds flaw was found in dev/parport in the Linux kernel. This issue may result in a crash.
In the Linux kernel, the following vulnerability has been resolved: net: missing check virtio Two missing check in virtio_net_hdr_to_skb() allowed syzbot to crash kernels again 1. After the skb_segment function the buffer may become non-linear (nr_frags != 0), but since the SKBTX_SHARED_FRAG flag is not set anywhere the __skb_linearize function will not be executed, then the buffer will remain non-linear. Then the condition (offset >= skb_headlen(skb)) becomes true, which causes WARN_ON_ONCE in skb_checksum_help. 2. The struct sk_buff and struct virtio_net_hdr members must be mathematically related. (gso_size) must be greater than (needed) otherwise WARN_ON_ONCE. (remainder) must be greater than (needed) otherwise WARN_ON_ONCE. (remainder) may be 0 if division is without remainder. offset+2 (4191) > skb_headlen() (1116) WARNING: CPU: 1 PID: 5084 at net/core/dev.c:3303 skb_checksum_help+0x5e2/0x740 net/core/dev.c:3303 Modules linked in: CPU: 1 PID: 5084 Comm: syz-executor336 Not tainted 6.7.0-rc3-syzkaller-00014-gdf60cee26a2e #0 Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google 11/10/2023 RIP: 0010:skb_checksum_help+0x5e2/0x740 net/core/dev.c:3303 Code: 89 e8 83 e0 07 83 c0 03 38 d0 7c 08 84 d2 0f 85 52 01 00 00 44 89 e2 2b 53 74 4c 89 ee 48 c7 c7 40 57 e9 8b e8 af 8f dd f8 90 <0f> 0b 90 90 e9 87 fe ff ff e8 40 0f 6e f9 e9 4b fa ff ff 48 89 ef RSP: 0018:ffffc90003a9f338 EFLAGS: 00010286 RAX: 0000000000000000 RBX: ffff888025125780 RCX: ffffffff814db209 RDX: ffff888015393b80 RSI: ffffffff814db216 RDI: 0000000000000001 RBP: ffff8880251257f4 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000001 R12: 000000000000045c R13: 000000000000105f R14: ffff8880251257f0 R15: 000000000000105d FS: 0000555555c24380(0000) GS:ffff8880b9900000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000002000f000 CR3: 0000000023151000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> ip_do_fragment+0xa1b/0x18b0 net/ipv4/ip_output.c:777 ip_fragment.constprop.0+0x161/0x230 net/ipv4/ip_output.c:584 ip_finish_output_gso net/ipv4/ip_output.c:286 [inline] __ip_finish_output net/ipv4/ip_output.c:308 [inline] __ip_finish_output+0x49c/0x650 net/ipv4/ip_output.c:295 ip_finish_output+0x31/0x310 net/ipv4/ip_output.c:323 NF_HOOK_COND include/linux/netfilter.h:303 [inline] ip_output+0x13b/0x2a0 net/ipv4/ip_output.c:433 dst_output include/net/dst.h:451 [inline] ip_local_out+0xaf/0x1a0 net/ipv4/ip_output.c:129 iptunnel_xmit+0x5b4/0x9b0 net/ipv4/ip_tunnel_core.c:82 ipip6_tunnel_xmit net/ipv6/sit.c:1034 [inline] sit_tunnel_xmit+0xed2/0x28f0 net/ipv6/sit.c:1076 __netdev_start_xmit include/linux/netdevice.h:4940 [inline] netdev_start_xmit include/linux/netdevice.h:4954 [inline] xmit_one net/core/dev.c:3545 [inline] dev_hard_start_xmit+0x13d/0x6d0 net/core/dev.c:3561 __dev_queue_xmit+0x7c1/0x3d60 net/core/dev.c:4346 dev_queue_xmit include/linux/netdevice.h:3134 [inline] packet_xmit+0x257/0x380 net/packet/af_packet.c:276 packet_snd net/packet/af_packet.c:3087 [inline] packet_sendmsg+0x24ca/0x5240 net/packet/af_packet.c:3119 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0xd5/0x180 net/socket.c:745 __sys_sendto+0x255/0x340 net/socket.c:2190 __do_sys_sendto net/socket.c:2202 [inline] __se_sys_sendto net/socket.c:2198 [inline] __x64_sys_sendto+0xe0/0x1b0 net/socket.c:2198 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x40/0x110 arch/x86/entry/common.c:82 entry_SYSCALL_64_after_hwframe+0x63/0x6b Found by Linux Verification Center (linuxtesting.org) with Syzkaller
nfs in linux kernel permits using nfs_folio_length without locking the folio and without checking for null mapping. This can permit truncation and lead to kernel crash.
leds in linux kernel permits calling sysfs attributes show/store functions after deactivate has been called.
A possible array out-of-bounds read flaw was found in the Linux kernel. This issue may lead to a crash.
A vulnerability was found in the Linux kernel's dma subsystem in the dmam_free_coherent() function where a race condition is possible between the calls to dmam_free_coherent() and devres_destroy() leading to a double entry in the devres list. This flaw could potentially lead to memory corruption or unexpected behavior.
In the Linux kernel, the following vulnerability has been resolved: s390/fpu: Re-add exception handling in load_fpu_state() With the recent rewrite of the fpu code exception handling for the lfpc instruction within load_fpu_state() was erroneously removed. Add it again to prevent that loading invalid floating point register values cause an unhandled specification exception.
In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Always drain health in shutdown callback There is no point in recovery during device shutdown. if health work started need to wait for it to avoid races and NULL pointer access. Hence, drain health WQ on shutdown callback.
Linux kernel perf pending task work is never waited upon the matching event release; in the case of a child event, released via free_event() directly, this can potentially result in a leaked event.
A logical flaw exists in the Linux kernel. When a task is scheduled, pending sigtrap deliveries are deferred to the target task upon resuming to userspace via task_work. However, failures are ignored while adding an event's callback to the task_work engine. Since the last call for the event exit happens after task work is eventually closed, there is a small window where the pending sigtrap can be queued to be ignored.
In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: handle 2x996 RU allocation in cfg80211_calculate_bitrate_he() Currently NL80211_RATE_INFO_HE_RU_ALLOC_2x996 is not handled in cfg80211_calculate_bitrate_he(), leading to below warning: kernel: invalid HE MCS: bw:6, ru:6 kernel: WARNING: CPU: 0 PID: 2312 at net/wireless/util.c:1501 cfg80211_calculate_bitrate_he+0x22b/0x270 [cfg80211] Fix it by handling 2x996 RU allocation in the same way as 160 MHz bandwidth.
A possible use-after-free was found in the Linux kernel in mm/list_lru.c.
memcg in linux kernel permit concurrent access to mem_cgroup_idr which can lead to kernel crashes.
linux wifi mac80211 connection link_data allocations can result in null pointer dereferencing.
In the Linux kernel, the following vulnerability has been resolved: fuse: Initialize beyond-EOF page contents before setting uptodate fuse_notify_store(), unlike fuse_do_readpage(), does not enable page zeroing (because it can be used to change partial page contents). So fuse_notify_store() must be more careful to fully initialize page contents (including parts of the page that are beyond end-of-file) before marking the page uptodate. The current code can leave beyond-EOF page contents uninitialized, which makes these uninitialized page contents visible to userspace via mmap(). This is an information leak, but only affects systems which do not enable init-on-alloc (via CONFIG_INIT_ON_ALLOC_DEFAULT_ON=y or the corresponding kernel command line parameter).
A flaw was found in the USB gadget core component of the Linux kernel. This vulnerability occurs when a USB gadget does not properly set up its endpoint descriptor or provides malformed descriptors. A local attacker with the ability to connect a specially crafted USB gadget could trigger a null pointer panic, leading to a system crash and a Denial of Service (DoS).
In the Linux kernel, the following vulnerability has been resolved: x86/mm: Fix pti_clone_pgtable() alignment assumption Guenter reported dodgy crashes on an i386-nosmp build using GCC-11 that had the form of endless traps until entry stack exhaust and then #DF from the stack guard. It turned out that pti_clone_pgtable() had alignment assumptions on the start address, notably it hard assumes start is PMD aligned. This is true on x86_64, but very much not true on i386. These assumptions can cause the end condition to malfunction, leading to a 'short' clone. Guess what happens when the user mapping has a short copy of the entry text? Use the correct increment form for addr to avoid alignment assumptions.
In Linux kernel net/mlx5e, for SHAMPO, it is possible to receive CQEs with 0 consumed strides for the same WQE even after the WQE is fully consumed and unlinked. This triggers an additional unlink for the same wqe which corrupts the linked list.
A flaw was found in the bnxt_en module in the Linux kernel. A double DMA unmapping can trigger a kernel warning and cause a denial of service.
Fix validity interception issue when gisa is switched off. If gisa has been disabled either via using kernel parameter "kvm.use_gisa=0" or by setting the related sysfs attribute to N (echo N >/sys/module/kvm/parameters/use_gisa). The validity is caused by an invalid value in the SIE control block's gisa designation. That happens because we pass the uninitialized gisa origin to virt_to_phys() before writing it to the gisa designation. To fix this we return 0 in kvm_s390_get_gisa_desc() if the origin is 0. kvm_s390_get_gisa_desc() is used to determine which gisa designation to set in the SIE control block. A value of 0 in the gisa designation disables gisa usage. The issue surfaces in the host kernel with the following kernel message as soon a new kvm guest start is attempted.
In the Linux kernel, the following vulnerability has been resolved: tls: stop recv() if initial process_rx_list gave us non-DATA If we have a non-DATA record on the rx_list and another record of the same type still on the queue, we will end up merging them: - process_rx_list copies the non-DATA record - we start the loop and process the first available record since it's of the same type - we break out of the loop since the record was not DATA Just check the record type and jump to the end in case process_rx_list did some work.
Loading 44.5 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.