ISHACK AI BOT

Huawei EulerOS: CVE-2022-48724: kernel security update Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 06/20/2024 Created 11/06/2024 Added 11/05/2024 Modified 01/30/2025 Description In the Linux kernel, the following vulnerability has been resolved: iommu/vt-d: Fix potential memory leak in intel_setup_irq_remapping() After commit e3beca48a45b ("irqdomain/treewide: Keep firmware node unconditionally allocated"). For tear down scenario, fn is only freed after fail to allocate ir_domain, though it also should be freed in case dmar_enable_qi returns error. Besides free fn, irq_domain and ir_msi_domain need to be removed as well if intel_setup_irq_remapping fails to enable queued invalidation. Improve the rewinding path by add out_free_ir_domain and out_free_fwnode lables per Baolu's suggestion. Solution(s) huawei-euleros-2_0_sp12-upgrade-bpftool huawei-euleros-2_0_sp12-upgrade-kernel huawei-euleros-2_0_sp12-upgrade-kernel-abi-stablelists huawei-euleros-2_0_sp12-upgrade-kernel-tools huawei-euleros-2_0_sp12-upgrade-kernel-tools-libs huawei-euleros-2_0_sp12-upgrade-python3-perf References https://attackerkb.com/topics/cve-2022-48724 CVE - 2022-48724 EulerOS-SA-2024-2806

SUSE: CVE-2024-32608: SUSE Linux Security Advisory Severity 10 CVSS (AV:N/AC:L/Au:N/C:C/I:C/A:C) Published 06/20/2024 Created 06/21/2024 Added 06/21/2024 Modified 01/28/2025 Description This CVE is addressed in the SUSE advisories SUSE-SU-2024:2105-1, SUSE-SU-2024:2195-1, CVE-2024-32608. Solution(s) suse-upgrade-hdf5-gnu-hpc suse-upgrade-hdf5-gnu-hpc-devel suse-upgrade-hdf5-gnu-mpich-hpc suse-upgrade-hdf5-gnu-mpich-hpc-devel suse-upgrade-hdf5-gnu-mvapich2-hpc suse-upgrade-hdf5-gnu-mvapich2-hpc-devel suse-upgrade-hdf5-gnu-openmpi1-hpc-devel suse-upgrade-hdf5-gnu-openmpi3-hpc suse-upgrade-hdf5-gnu-openmpi3-hpc-devel suse-upgrade-hdf5-gnu-openmpi4-hpc suse-upgrade-hdf5-gnu-openmpi4-hpc-devel suse-upgrade-hdf5-hpc-examples suse-upgrade-hdf5_1_10_11-gnu-hpc suse-upgrade-hdf5_1_10_11-gnu-hpc-devel suse-upgrade-hdf5_1_10_11-gnu-hpc-devel-static suse-upgrade-hdf5_1_10_11-gnu-hpc-module suse-upgrade-hdf5_1_10_11-gnu-mpich-hpc suse-upgrade-hdf5_1_10_11-gnu-mpich-hpc-devel suse-upgrade-hdf5_1_10_11-gnu-mpich-hpc-devel-static suse-upgrade-hdf5_1_10_11-gnu-mpich-hpc-module suse-upgrade-hdf5_1_10_11-gnu-mvapich2-hpc suse-upgrade-hdf5_1_10_11-gnu-mvapich2-hpc-devel suse-upgrade-hdf5_1_10_11-gnu-mvapich2-hpc-devel-static suse-upgrade-hdf5_1_10_11-gnu-mvapich2-hpc-module suse-upgrade-hdf5_1_10_11-gnu-openmpi1-hpc suse-upgrade-hdf5_1_10_11-gnu-openmpi1-hpc-devel suse-upgrade-hdf5_1_10_11-gnu-openmpi1-hpc-devel-static suse-upgrade-hdf5_1_10_11-gnu-openmpi1-hpc-module suse-upgrade-hdf5_1_10_11-gnu-openmpi3-hpc suse-upgrade-hdf5_1_10_11-gnu-openmpi3-hpc-devel suse-upgrade-hdf5_1_10_11-gnu-openmpi3-hpc-devel-static suse-upgrade-hdf5_1_10_11-gnu-openmpi3-hpc-module suse-upgrade-hdf5_1_10_11-gnu-openmpi4-hpc suse-upgrade-hdf5_1_10_11-gnu-openmpi4-hpc-devel suse-upgrade-hdf5_1_10_11-gnu-openmpi4-hpc-devel-static suse-upgrade-hdf5_1_10_11-gnu-openmpi4-hpc-module suse-upgrade-hdf5_1_10_11-hpc-examples suse-upgrade-libhdf5-gnu-hpc suse-upgrade-libhdf5-gnu-mpich-hpc suse-upgrade-libhdf5-gnu-mvapich2-hpc suse-upgrade-libhdf5-gnu-openmpi1-hpc suse-upgrade-libhdf5-gnu-openmpi3-hpc suse-upgrade-libhdf5-gnu-openmpi4-hpc suse-upgrade-libhdf5_1_10_11-gnu-hpc suse-upgrade-libhdf5_1_10_11-gnu-mpich-hpc suse-upgrade-libhdf5_1_10_11-gnu-mvapich2-hpc suse-upgrade-libhdf5_1_10_11-gnu-openmpi1-hpc suse-upgrade-libhdf5_1_10_11-gnu-openmpi3-hpc suse-upgrade-libhdf5_1_10_11-gnu-openmpi4-hpc suse-upgrade-libhdf5_cpp-gnu-hpc suse-upgrade-libhdf5_cpp-gnu-mpich-hpc suse-upgrade-libhdf5_cpp-gnu-mvapich2-hpc suse-upgrade-libhdf5_cpp-gnu-openmpi3-hpc suse-upgrade-libhdf5_cpp-gnu-openmpi4-hpc suse-upgrade-libhdf5_cpp_1_10_11-gnu-hpc suse-upgrade-libhdf5_cpp_1_10_11-gnu-mpich-hpc suse-upgrade-libhdf5_cpp_1_10_11-gnu-mvapich2-hpc suse-upgrade-libhdf5_cpp_1_10_11-gnu-openmpi1-hpc suse-upgrade-libhdf5_cpp_1_10_11-gnu-openmpi3-hpc suse-upgrade-libhdf5_cpp_1_10_11-gnu-openmpi4-hpc suse-upgrade-libhdf5_fortran-gnu-hpc suse-upgrade-libhdf5_fortran-gnu-mpich-hpc suse-upgrade-libhdf5_fortran-gnu-mvapich2-hpc suse-upgrade-libhdf5_fortran-gnu-openmpi1-hpc suse-upgrade-libhdf5_fortran-gnu-openmpi3-hpc suse-upgrade-libhdf5_fortran-gnu-openmpi4-hpc suse-upgrade-libhdf5_fortran_1_10_11-gnu-hpc suse-upgrade-libhdf5_fortran_1_10_11-gnu-mpich-hpc suse-upgrade-libhdf5_fortran_1_10_11-gnu-mvapich2-hpc suse-upgrade-libhdf5_fortran_1_10_11-gnu-openmpi1-hpc suse-upgrade-libhdf5_fortran_1_10_11-gnu-openmpi3-hpc suse-upgrade-libhdf5_fortran_1_10_11-gnu-openmpi4-hpc suse-upgrade-libhdf5_hl-gnu-hpc suse-upgrade-libhdf5_hl-gnu-mpich-hpc suse-upgrade-libhdf5_hl-gnu-mvapich2-hpc suse-upgrade-libhdf5_hl-gnu-openmpi1-hpc suse-upgrade-libhdf5_hl-gnu-openmpi3-hpc suse-upgrade-libhdf5_hl-gnu-openmpi4-hpc suse-upgrade-libhdf5_hl_1_10_11-gnu-hpc suse-upgrade-libhdf5_hl_1_10_11-gnu-mpich-hpc suse-upgrade-libhdf5_hl_1_10_11-gnu-mvapich2-hpc suse-upgrade-libhdf5_hl_1_10_11-gnu-openmpi1-hpc suse-upgrade-libhdf5_hl_1_10_11-gnu-openmpi3-hpc suse-upgrade-libhdf5_hl_1_10_11-gnu-openmpi4-hpc suse-upgrade-libhdf5_hl_cpp-gnu-hpc suse-upgrade-libhdf5_hl_cpp-gnu-mpich-hpc suse-upgrade-libhdf5_hl_cpp-gnu-mvapich2-hpc suse-upgrade-libhdf5_hl_cpp-gnu-openmpi3-hpc suse-upgrade-libhdf5_hl_cpp-gnu-openmpi4-hpc suse-upgrade-libhdf5_hl_cpp_1_10_11-gnu-hpc suse-upgrade-libhdf5_hl_cpp_1_10_11-gnu-mpich-hpc suse-upgrade-libhdf5_hl_cpp_1_10_11-gnu-mvapich2-hpc suse-upgrade-libhdf5_hl_cpp_1_10_11-gnu-openmpi1-hpc suse-upgrade-libhdf5_hl_cpp_1_10_11-gnu-openmpi3-hpc suse-upgrade-libhdf5_hl_cpp_1_10_11-gnu-openmpi4-hpc suse-upgrade-libhdf5_hl_fortran-gnu-hpc suse-upgrade-libhdf5_hl_fortran-gnu-mpich-hpc suse-upgrade-libhdf5_hl_fortran-gnu-mvapich2-hpc suse-upgrade-libhdf5_hl_fortran-gnu-openmpi1-hpc suse-upgrade-libhdf5_hl_fortran-gnu-openmpi3-hpc suse-upgrade-libhdf5_hl_fortran-gnu-openmpi4-hpc suse-upgrade-libhdf5hl_fortran_1_10_11-gnu-hpc suse-upgrade-libhdf5hl_fortran_1_10_11-gnu-mpich-hpc suse-upgrade-libhdf5hl_fortran_1_10_11-gnu-mvapich2-hpc suse-upgrade-libhdf5hl_fortran_1_10_11-gnu-openmpi1-hpc suse-upgrade-libhdf5hl_fortran_1_10_11-gnu-openmpi3-hpc suse-upgrade-libhdf5hl_fortran_1_10_11-gnu-openmpi4-hpc suse-upgrade-libmca_common_dstore1 suse-upgrade-libopenmpi4-gnu-hpc suse-upgrade-libopenmpi_4_1_4-gnu-hpc suse-upgrade-libopenmpi_4_1_6-gnu-hpc suse-upgrade-libpmix2 suse-upgrade-lua51-luaposix suse-upgrade-lua51-luaterm suse-upgrade-lua53-luaposix suse-upgrade-lua53-luaterm suse-upgrade-luaposix-doc suse-upgrade-mpich suse-upgrade-mpich-devel suse-upgrade-mpich-gnu-hpc suse-upgrade-mpich-gnu-hpc-devel suse-upgrade-mpich-gnu-hpc-devel-static suse-upgrade-mpich-gnu-hpc-macros-devel suse-upgrade-mpich-ofi suse-upgrade-mpich-ofi-devel suse-upgrade-mpich-ofi-gnu-hpc suse-upgrade-mpich-ofi-gnu-hpc-devel suse-upgrade-mpich-ofi-gnu-hpc-devel-static suse-upgrade-mpich-ofi-gnu-hpc-macros-devel suse-upgrade-mpich-ofi_4_0_2-gnu-hpc suse-upgrade-mpich-ofi_4_0_2-gnu-hpc-devel suse-upgrade-mpich-ofi_4_0_2-gnu-hpc-devel-static suse-upgrade-mpich-ofi_4_0_2-gnu-hpc-macros-devel suse-upgrade-mpich-ofi_4_1_2-gnu-hpc suse-upgrade-mpich-ofi_4_1_2-gnu-hpc-devel suse-upgrade-mpich-ofi_4_1_2-gnu-hpc-devel-static suse-upgrade-mpich-ofi_4_1_2-gnu-hpc-macros-devel suse-upgrade-mpich_4_0_2-gnu-hpc suse-upgrade-mpich_4_0_2-gnu-hpc-devel suse-upgrade-mpich_4_0_2-gnu-hpc-devel-static suse-upgrade-mpich_4_0_2-gnu-hpc-macros-devel suse-upgrade-mpich_4_1_2-gnu-hpc suse-upgrade-mpich_4_1_2-gnu-hpc-devel suse-upgrade-mpich_4_1_2-gnu-hpc-devel-static suse-upgrade-mpich_4_1_2-gnu-hpc-macros-devel suse-upgrade-mvapich2 suse-upgrade-mvapich2-devel suse-upgrade-mvapich2-devel-static suse-upgrade-mvapich2-doc suse-upgrade-mvapich2-gnu-hpc suse-upgrade-mvapich2-gnu-hpc-devel suse-upgrade-mvapich2-gnu-hpc-doc suse-upgrade-mvapich2-gnu-hpc-macros-devel suse-upgrade-mvapich2-psm suse-upgrade-mvapich2-psm-devel suse-upgrade-mvapich2-psm-devel-static suse-upgrade-mvapich2-psm-doc suse-upgrade-mvapich2-psm-gnu-hpc suse-upgrade-mvapich2-psm-gnu-hpc-devel suse-upgrade-mvapich2-psm-gnu-hpc-doc suse-upgrade-mvapich2-psm-gnu-hpc-macros-devel suse-upgrade-mvapich2-psm2 suse-upgrade-mvapich2-psm2-devel suse-upgrade-mvapich2-psm2-devel-static suse-upgrade-mvapich2-psm2-doc suse-upgrade-mvapich2-psm2-gnu-hpc suse-upgrade-mvapich2-psm2-gnu-hpc-devel suse-upgrade-mvapich2-psm2-gnu-hpc-doc suse-upgrade-mvapich2-psm2-gnu-hpc-macros-devel suse-upgrade-mvapich2-psm2_2_3_7-gnu-hpc suse-upgrade-mvapich2-psm2_2_3_7-gnu-hpc-devel suse-upgrade-mvapich2-psm2_2_3_7-gnu-hpc-devel-static suse-upgrade-mvapich2-psm2_2_3_7-gnu-hpc-doc suse-upgrade-mvapich2-psm2_2_3_7-gnu-hpc-macros-devel suse-upgrade-mvapich2-psm_2_3_7-gnu-hpc suse-upgrade-mvapich2-psm_2_3_7-gnu-hpc-devel suse-upgrade-mvapich2-psm_2_3_7-gnu-hpc-devel-static suse-upgrade-mvapich2-psm_2_3_7-gnu-hpc-doc suse-upgrade-mvapich2-psm_2_3_7-gnu-hpc-macros-devel suse-upgrade-mvapich2_2_3_7-gnu-hpc suse-upgrade-mvapich2_2_3_7-gnu-hpc-devel suse-upgrade-mvapich2_2_3_7-gnu-hpc-devel-static suse-upgrade-mvapich2_2_3_7-gnu-hpc-doc suse-upgrade-mvapich2_2_3_7-gnu-hpc-macros-devel suse-upgrade-openmpi4 suse-upgrade-openmpi4-config suse-upgrade-openmpi4-devel suse-upgrade-openmpi4-docs suse-upgrade-openmpi4-gnu-hpc suse-upgrade-openmpi4-gnu-hpc-devel suse-upgrade-openmpi4-gnu-hpc-devel-static suse-upgrade-openmpi4-gnu-hpc-docs suse-upgrade-openmpi4-gnu-hpc-macros-devel suse-upgrade-openmpi4-libs suse-upgrade-openmpi4-libs-32bit suse-upgrade-openmpi4-macros-devel suse-upgrade-openmpi4-testsuite suse-upgrade-openmpi_4_1_4-gnu-hpc suse-upgrade-openmpi_4_1_4-gnu-hpc-devel suse-upgrade-openmpi_4_1_4-gnu-hpc-devel-static suse-upgrade-openmpi_4_1_4-gnu-hpc-docs suse-upgrade-openmpi_4_1_4-gnu-hpc-macros-devel suse-upgrade-openmpi_4_1_4-gnu-hpc-testsuite suse-upgrade-openmpi_4_1_6-gnu-hpc suse-upgrade-openmpi_4_1_6-gnu-hpc-devel suse-upgrade-openmpi_4_1_6-gnu-hpc-devel-static suse-upgrade-openmpi_4_1_6-gnu-hpc-docs suse-upgrade-openmpi_4_1_6-gnu-hpc-macros-devel suse-upgrade-openmpi_4_1_6-gnu-hpc-testsuite suse-upgrade-pmix suse-upgrade-pmix-devel suse-upgrade-pmix-headers suse-upgrade-pmix-mca-params suse-upgrade-pmix-plugin-munge suse-upgrade-pmix-plugins suse-upgrade-pmix-test References https://attackerkb.com/topics/cve-2024-32608 CVE - 2024-32608 SUSE-SU-2024:2105-1 SUSE-SU-2024:2195-1

Ubuntu: (CVE-2022-48724): linux vulnerability Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 06/20/2024 Created 11/21/2024 Added 11/19/2024 Modified 02/11/2025 Description In the Linux kernel, the following vulnerability has been resolved: iommu/vt-d: Fix potential memory leak in intel_setup_irq_remapping() After commit e3beca48a45b ("irqdomain/treewide: Keep firmware node unconditionally allocated"). For tear down scenario, fn is only freed after fail to allocate ir_domain, though it also should be freed in case dmar_enable_qi returns error. Besides free fn, irq_domain and ir_msi_domain need to be removed as well if intel_setup_irq_remapping fails to enable queued invalidation. Improve the rewinding path by add out_free_ir_domain and out_free_fwnode lables per Baolu's suggestion. Solution(s) ubuntu-upgrade-linux ubuntu-upgrade-linux-aws ubuntu-upgrade-linux-aws-5-4 ubuntu-upgrade-linux-aws-fips ubuntu-upgrade-linux-aws-hwe ubuntu-upgrade-linux-azure ubuntu-upgrade-linux-azure-4-15 ubuntu-upgrade-linux-azure-5-4 ubuntu-upgrade-linux-azure-fips ubuntu-upgrade-linux-bluefield ubuntu-upgrade-linux-fips ubuntu-upgrade-linux-gcp ubuntu-upgrade-linux-gcp-4-15 ubuntu-upgrade-linux-gcp-5-4 ubuntu-upgrade-linux-gcp-fips ubuntu-upgrade-linux-gkeop ubuntu-upgrade-linux-hwe ubuntu-upgrade-linux-hwe-5-4 ubuntu-upgrade-linux-ibm ubuntu-upgrade-linux-ibm-5-4 ubuntu-upgrade-linux-intel-iotg-5-15 ubuntu-upgrade-linux-iot ubuntu-upgrade-linux-kvm ubuntu-upgrade-linux-oracle ubuntu-upgrade-linux-oracle-5-4 ubuntu-upgrade-linux-raspi ubuntu-upgrade-linux-raspi-5-4 References https://attackerkb.com/topics/cve-2022-48724 CVE - 2022-48724 https://git.kernel.org/linus/99e675d473eb8cf2deac1376a0f840222fc1adcf https://git.kernel.org/stable/c/336d096b62bdc673e852b6b80d5072d7888ce85d https://git.kernel.org/stable/c/5c43d46daa0d2928234dd2792ebebc35d29ee2d1 https://git.kernel.org/stable/c/99e675d473eb8cf2deac1376a0f840222fc1adcf https://git.kernel.org/stable/c/9d9995b0371e4e8c18d4f955479e5d47efe7b2d4 https://git.kernel.org/stable/c/a0c685ba99961b1dd894b2e470e692a539770f6d https://git.kernel.org/stable/c/a31cb1f0fb6caf46ffe88c41252b6b7a4ee062d9 https://git.kernel.org/stable/c/b62eceb5f8f08815fe3f945fc55bbf997c344ecd https://www.cve.org/CVERecord?id=CVE-2022-48724 View more

Alma Linux: CVE-2022-48747: Important: kernel security update (Multiple Advisories) Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 06/20/2024 Created 08/13/2024 Added 08/12/2024 Modified 08/12/2024 Description In the Linux kernel, the following vulnerability has been resolved: block: Fix wrong offset in bio_truncate() bio_truncate() clears the buffer outside of last block of bdev, however current bio_truncate() is using the wrong offset of page. So it can return the uninitialized data. This happened when both of truncated/corrupted FS and userspace (via bdev) are trying to read the last of bdev. Solution(s) alma-upgrade-bpftool alma-upgrade-kernel alma-upgrade-kernel-abi-stablelists alma-upgrade-kernel-core alma-upgrade-kernel-cross-headers alma-upgrade-kernel-debug alma-upgrade-kernel-debug-core alma-upgrade-kernel-debug-devel alma-upgrade-kernel-debug-modules alma-upgrade-kernel-debug-modules-extra alma-upgrade-kernel-devel alma-upgrade-kernel-doc alma-upgrade-kernel-headers alma-upgrade-kernel-modules alma-upgrade-kernel-modules-extra alma-upgrade-kernel-rt alma-upgrade-kernel-rt-core alma-upgrade-kernel-rt-debug alma-upgrade-kernel-rt-debug-core alma-upgrade-kernel-rt-debug-devel alma-upgrade-kernel-rt-debug-kvm alma-upgrade-kernel-rt-debug-modules alma-upgrade-kernel-rt-debug-modules-extra alma-upgrade-kernel-rt-devel alma-upgrade-kernel-rt-kvm alma-upgrade-kernel-rt-modules alma-upgrade-kernel-rt-modules-extra alma-upgrade-kernel-tools alma-upgrade-kernel-tools-libs alma-upgrade-kernel-tools-libs-devel alma-upgrade-kernel-zfcpdump alma-upgrade-kernel-zfcpdump-core alma-upgrade-kernel-zfcpdump-devel alma-upgrade-kernel-zfcpdump-modules alma-upgrade-kernel-zfcpdump-modules-extra alma-upgrade-perf alma-upgrade-python3-perf References https://attackerkb.com/topics/cve-2022-48747 CVE - 2022-48747 https://errata.almalinux.org/8/ALSA-2024-5101.html https://errata.almalinux.org/8/ALSA-2024-5102.html

Alma Linux: CVE-2022-48754: Important: kernel security update (Multiple Advisories) Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 06/20/2024 Created 09/27/2024 Added 09/26/2024 Modified 09/26/2024 Description In the Linux kernel, the following vulnerability has been resolved: phylib: fix potential use-after-free Commit bafbdd527d56 ("phylib: Add device reset GPIO support") added call to phy_device_reset(phydev) after the put_device() call in phy_detach(). The comment before the put_device() call says that the phydev might go away with put_device(). Fix potential use-after-free by calling phy_device_reset() before put_device(). Solution(s) alma-upgrade-bpftool alma-upgrade-kernel alma-upgrade-kernel-abi-stablelists alma-upgrade-kernel-core alma-upgrade-kernel-cross-headers alma-upgrade-kernel-debug alma-upgrade-kernel-debug-core alma-upgrade-kernel-debug-devel alma-upgrade-kernel-debug-modules alma-upgrade-kernel-debug-modules-extra alma-upgrade-kernel-devel alma-upgrade-kernel-doc alma-upgrade-kernel-headers alma-upgrade-kernel-modules alma-upgrade-kernel-modules-extra alma-upgrade-kernel-rt alma-upgrade-kernel-rt-core alma-upgrade-kernel-rt-debug alma-upgrade-kernel-rt-debug-core alma-upgrade-kernel-rt-debug-devel alma-upgrade-kernel-rt-debug-kvm alma-upgrade-kernel-rt-debug-modules alma-upgrade-kernel-rt-debug-modules-extra alma-upgrade-kernel-rt-devel alma-upgrade-kernel-rt-kvm alma-upgrade-kernel-rt-modules alma-upgrade-kernel-rt-modules-extra alma-upgrade-kernel-tools alma-upgrade-kernel-tools-libs alma-upgrade-kernel-tools-libs-devel alma-upgrade-kernel-zfcpdump alma-upgrade-kernel-zfcpdump-core alma-upgrade-kernel-zfcpdump-devel alma-upgrade-kernel-zfcpdump-modules alma-upgrade-kernel-zfcpdump-modules-extra alma-upgrade-perf alma-upgrade-python3-perf References https://attackerkb.com/topics/cve-2022-48754 CVE - 2022-48754 https://errata.almalinux.org/8/ALSA-2024-7000.html https://errata.almalinux.org/8/ALSA-2024-7001.html

Oracle Linux: CVE-2022-48760: ELSA-2024-7000:kernel security update (IMPORTANT) (Multiple Advisories) Severity 4 CVSS (AV:L/AC:H/Au:M/C:N/I:N/A:C) Published 06/20/2024 Created 10/24/2024 Added 10/16/2024 Modified 01/23/2025 Description In the Linux kernel, the following vulnerability has been resolved: USB: core: Fix hang in usb_kill_urb by adding memory barriers The syzbot fuzzer has identified a bug in which processes hang waiting for usb_kill_urb() to return.It turns out the issue is not unlinking the URB; that works just fine.Rather, the problem arises when the wakeup notification that the URB has completed is not received. The reason is memory-access ordering on SMP systems.In outline form, usb_kill_urb() and __usb_hcd_giveback_urb() operating concurrently on different CPUs perform the following actions: CPU 0CPU 1 ------------------------------------------------------------- usb_kill_urb():__usb_hcd_giveback_urb(): ...... atomic_inc(&urb->reject);atomic_dec(&urb->use_count); ...... wait_event(usb_kill_urb_queue, atomic_read(&urb->use_count) == 0); if (atomic_read(&urb->reject)) wake_up(&usb_kill_urb_queue); Confining your attention to urb->reject and urb->use_count, you can see that the overall pattern of accesses on CPU 0 is: write urb->reject, then read urb->use_count; whereas the overall pattern of accesses on CPU 1 is: write urb->use_count, then read urb->reject. This pattern is referred to in memory-model circles as SB (for "Store Buffering"), and it is well known that without suitable enforcement of the desired order of accesses -- in the form of memory barriers -- it is entirely possible for one or both CPUs to execute their reads ahead of their writes.The end result will be that sometimes CPU 0 sees the old un-decremented value of urb->use_count while CPU 1 sees the old un-incremented value of urb->reject.Consequently CPU 0 ends up on the wait queue and never gets woken up, leading to the observed hang in usb_kill_urb(). The same pattern of accesses occurs in usb_poison_urb() and the failure pathway of usb_hcd_submit_urb(). The problem is fixed by adding suitable memory barriers.To provide proper memory-access ordering in the SB pattern, a full barrier is required on both CPUs.The atomic_inc() and atomic_dec() accesses themselves don't provide any memory ordering, but since they are present, we can use the optimized smp_mb__after_atomic() memory barrier in the various routines to obtain the desired effect. This patch adds the necessary memory barriers. Solution(s) oracle-linux-upgrade-kernel oracle-linux-upgrade-kernel-uek References https://attackerkb.com/topics/cve-2022-48760 CVE - 2022-48760 ELSA-2024-7000 ELSA-2024-12806

Debian: CVE-2022-48735: linux -- security update Severity 7 CVSS (AV:L/AC:L/Au:S/C:C/I:C/A:C) Published 06/20/2024 Created 07/31/2024 Added 07/30/2024 Modified 01/30/2025 Description In the Linux kernel, the following vulnerability has been resolved: ALSA: hda: Fix UAF of leds class devs at unbinding The LED class devices that are created by HD-audio codec drivers are registered via devm_led_classdev_register() and associated with the HD-audio codec device.Unfortunately, it turned out that the devres release doesn't work for this case; namely, since the codec resource release happens before the devm call chain, it triggers a NULL dereference or a UAF for a stale set_brightness_delay callback. For fixing the bug, this patch changes the LED class device register and unregister in a manual manner without devres, keeping the instances in hda_gen_spec. Solution(s) debian-upgrade-linux References https://attackerkb.com/topics/cve-2022-48735 CVE - 2022-48735

Debian: CVE-2022-48771: linux -- security update Severity 7 CVSS (AV:L/AC:L/Au:S/C:C/I:C/A:C) Published 06/20/2024 Created 07/31/2024 Added 07/30/2024 Modified 01/30/2025 Description In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: Fix stale file descriptors on failed usercopy A failing usercopy of the fence_rep object will lead to a stale entry in the file descriptor table as put_unused_fd() won't release it. This enables userland to refer to a dangling 'file' object through that still valid file descriptor, leading to all kinds of use-after-free exploitation scenarios. Fix this by deferring the call to fd_install() until after the usercopy has succeeded. Solution(s) debian-upgrade-linux References https://attackerkb.com/topics/cve-2022-48771 CVE - 2022-48771

Debian: CVE-2022-48770: linux -- security update Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 06/20/2024 Created 07/31/2024 Added 07/30/2024 Modified 01/28/2025 Description In the Linux kernel, the following vulnerability has been resolved: bpf: Guard against accessing NULL pt_regs in bpf_get_task_stack() task_pt_regs() can return NULL on powerpc for kernel threads. This is then used in __bpf_get_stack() to check for user mode, resulting in a kernel oops. Guard against this by checking return value of task_pt_regs() before trying to obtain the call chain. Solution(s) debian-upgrade-linux References https://attackerkb.com/topics/cve-2022-48770 CVE - 2022-48770

Debian: CVE-2022-48769: linux -- security update Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 06/20/2024 Created 07/31/2024 Added 07/30/2024 Modified 07/30/2024 Description In the Linux kernel, the following vulnerability has been resolved: efi: runtime: avoid EFIv2 runtime services on Apple x86 machines Aditya reports [0] that his recent MacbookPro crashes in the firmware when using the variable services at runtime. The culprit appears to be a call to QueryVariableInfo(), which we did not use to call on Apple x86 machines in the past as they only upgraded from EFI v1.10 to EFI v2.40 firmware fairly recently, and QueryVariableInfo() (along with UpdateCapsule() et al) was added in EFI v2.00. The only runtime service introduced in EFI v2.00 that we actually use in Linux is QueryVariableInfo(), as the capsule based ones are optional, generally not used at runtime (all the LVFS/fwupd firmware update infrastructure uses helper EFI programs that invoke capsule update at boot time, not runtime), and not implemented by Apple machines in the first place. QueryVariableInfo() is used to 'safely' set variables, i.e., only when there is enough space. This prevents machines with buggy firmwares from corrupting their NVRAMs when they run out of space. Given that Apple machines have been using EFI v1.10 services only for the longest time (the EFI v2.0 spec was released in 2006, and Linux support for the newly introduced runtime services was added in 2011, but the MacbookPro12,1 released in 2015 still claims to be EFI v1.10 only), let's avoid the EFI v2.0 ones on all Apple x86 machines. [0] https://lore.kernel.org/all/[email protected]/ Solution(s) debian-upgrade-linux References https://attackerkb.com/topics/cve-2022-48769 CVE - 2022-48769

Debian: CVE-2022-48768: linux -- security update Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 06/20/2024 Created 07/31/2024 Added 07/30/2024 Modified 01/28/2025 Description In the Linux kernel, the following vulnerability has been resolved: tracing/histogram: Fix a potential memory leak for kstrdup() kfree() is missing on an error path to free the memory allocated by kstrdup(): p = param = kstrdup(data->params[i], GFP_KERNEL); So it is better to free it via kfree(p). Solution(s) debian-upgrade-linux References https://attackerkb.com/topics/cve-2022-48768 CVE - 2022-48768

Debian: CVE-2022-48766: linux -- security update Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 06/20/2024 Created 07/31/2024 Added 07/30/2024 Modified 01/28/2025 Description In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Wrap dcn301_calculate_wm_and_dlg for FPU. Mirrors the logic for dcn30. Cue lots of WARNs and some kernel panics without this fix. Solution(s) debian-upgrade-linux References https://attackerkb.com/topics/cve-2022-48766 CVE - 2022-48766

Debian: CVE-2022-48765: linux -- security update Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 06/20/2024 Created 07/31/2024 Added 07/30/2024 Modified 07/30/2024 Description In the Linux kernel, the following vulnerability has been resolved: KVM: LAPIC: Also cancel preemption timer during SET_LAPIC The below warning is splatting during guest reboot. ------------[ cut here ]------------ WARNING: CPU: 0 PID: 1931 at arch/x86/kvm/x86.c:10322 kvm_arch_vcpu_ioctl_run+0x874/0x880 [kvm] CPU: 0 PID: 1931 Comm: qemu-system-x86 Tainted: GI 5.17.0-rc1+ #5 RIP: 0010:kvm_arch_vcpu_ioctl_run+0x874/0x880 [kvm] Call Trace: <TASK> kvm_vcpu_ioctl+0x279/0x710 [kvm] __x64_sys_ioctl+0x83/0xb0 do_syscall_64+0x3b/0xc0 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7fd39797350b This can be triggered by not exposing tsc-deadline mode and doing a reboot in the guest. The lapic_shutdown() function which is called in sys_reboot path will not disarm the flying timer, it just masks LVTT. lapic_shutdown() clears APIC state w/ LVT_MASKED and timer-mode bit is 0, this can trigger timer-mode switch between tsc-deadline and oneshot/periodic, which can result in preemption timer be cancelled in apic_update_lvtt(). However, We can't depend on this when not exposing tsc-deadline mode and oneshot/periodic modes emulated by preemption timer. Qemu will synchronise states around reset, let's cancel preemption timer under KVM_SET_LAPIC. Solution(s) debian-upgrade-linux References https://attackerkb.com/topics/cve-2022-48765 CVE - 2022-48765

Debian: CVE-2022-48764: linux -- security update Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 06/20/2024 Created 07/31/2024 Added 07/30/2024 Modified 07/30/2024 Description In the Linux kernel, the following vulnerability has been resolved: KVM: x86: Free kvm_cpuid_entry2 array on post-KVM_RUN KVM_SET_CPUID{,2} Free the "struct kvm_cpuid_entry2" array on successful post-KVM_RUN KVM_SET_CPUID{,2} to fix a memory leak, the callers of kvm_set_cpuid() free the array only on failure. BUG: memory leak unreferenced object 0xffff88810963a800 (size 2048): comm "syz-executor025", pid 3610, jiffies 4294944928 (age 8.080s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 0d 00 00 00................ 47 65 6e 75 6e 74 65 6c 69 6e 65 49 00 00 00 00GenuntelineI.... backtrace: [<ffffffff814948ee>] kmalloc_node include/linux/slab.h:604 [inline] [<ffffffff814948ee>] kvmalloc_node+0x3e/0x100 mm/util.c:580 [<ffffffff814950f2>] kvmalloc include/linux/slab.h:732 [inline] [<ffffffff814950f2>] vmemdup_user+0x22/0x100 mm/util.c:199 [<ffffffff8109f5ff>] kvm_vcpu_ioctl_set_cpuid2+0x8f/0xf0 arch/x86/kvm/cpuid.c:423 [<ffffffff810711b9>] kvm_arch_vcpu_ioctl+0xb99/0x1e60 arch/x86/kvm/x86.c:5251 [<ffffffff8103e92d>] kvm_vcpu_ioctl+0x4ad/0x950 arch/x86/kvm/../../../virt/kvm/kvm_main.c:4066 [<ffffffff815afacc>] vfs_ioctl fs/ioctl.c:51 [inline] [<ffffffff815afacc>] __do_sys_ioctl fs/ioctl.c:874 [inline] [<ffffffff815afacc>] __se_sys_ioctl fs/ioctl.c:860 [inline] [<ffffffff815afacc>] __x64_sys_ioctl+0xfc/0x140 fs/ioctl.c:860 [<ffffffff844a3335>] do_syscall_x64 arch/x86/entry/common.c:50 [inline] [<ffffffff844a3335>] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 [<ffffffff84600068>] entry_SYSCALL_64_after_hwframe+0x44/0xae Solution(s) debian-upgrade-linux References https://attackerkb.com/topics/cve-2022-48764 CVE - 2022-48764

Debian: CVE-2022-48762: linux -- security update Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 06/20/2024 Created 07/31/2024 Added 07/30/2024 Modified 07/30/2024 Description In the Linux kernel, the following vulnerability has been resolved: arm64: extable: fix load_unaligned_zeropad() reg indices In ex_handler_load_unaligned_zeropad() we erroneously extract the data and addr register indices from ex->type rather than ex->data. As ex->type will contain EX_TYPE_LOAD_UNALIGNED_ZEROPAD (i.e. 4): * We'll always treat X0 as the address register, since EX_DATA_REG_ADDR is extracted from bits [9:5]. Thus, we may attempt to dereference an arbitrary address as X0 may hold an arbitrary value. * We'll always treat X4 as the data register, since EX_DATA_REG_DATA is extracted from bits [4:0]. Thus we will corrupt X4 and cause arbitrary behaviour within load_unaligned_zeropad() and its caller. Fix this by extracting both values from ex->data as originally intended. On an MTE-enabled QEMU image we are hitting the following crash: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 Call trace: fixup_exception+0xc4/0x108 __do_kernel_fault+0x3c/0x268 do_tag_check_fault+0x3c/0x104 do_mem_abort+0x44/0xf4 el1_abort+0x40/0x64 el1h_64_sync_handler+0x60/0xa0 el1h_64_sync+0x7c/0x80 link_path_walk+0x150/0x344 path_openat+0xa0/0x7dc do_filp_open+0xb8/0x168 do_sys_openat2+0x88/0x17c __arm64_sys_openat+0x74/0xa0 invoke_syscall+0x48/0x148 el0_svc_common+0xb8/0xf8 do_el0_svc+0x28/0x88 el0_svc+0x24/0x84 el0t_64_sync_handler+0x88/0xec el0t_64_sync+0x1b4/0x1b8 Code: f8695a69 71007d1f 540000e0 927df12a (f940014a) Solution(s) debian-upgrade-linux References https://attackerkb.com/topics/cve-2022-48762 CVE - 2022-48762

Debian: CVE-2022-48761: linux -- security update Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 06/20/2024 Created 07/31/2024 Added 07/30/2024 Modified 07/30/2024 Description In the Linux kernel, the following vulnerability has been resolved: usb: xhci-plat: fix crash when suspend if remote wake enable Crashed at i.mx8qm platform when suspend if enable remote wakeup Internal error: synchronous external abort: 96000210 [#1] PREEMPT SMP Modules linked in: CPU: 2 PID: 244 Comm: kworker/u12:6 Not tainted 5.15.5-dirty #12 Hardware name: Freescale i.MX8QM MEK (DT) Workqueue: events_unbound async_run_entry_fn pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : xhci_disable_hub_port_wake.isra.62+0x60/0xf8 lr : xhci_disable_hub_port_wake.isra.62+0x34/0xf8 sp : ffff80001394bbf0 x29: ffff80001394bbf0 x28: 0000000000000000 x27: ffff00081193b578 x26: ffff00081193b570 x25: 0000000000000000 x24: 0000000000000000 x23: ffff00081193a29c x22: 0000000000020001 x21: 0000000000000001 x20: 0000000000000000 x19: ffff800014e90490 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 x14: 0000000000000000 x13: 0000000000000002 x12: 0000000000000000 x11: 0000000000000000 x10: 0000000000000960 x9 : ffff80001394baa0 x8 : ffff0008145d1780 x7 : ffff0008f95b8e80 x6 : 000000001853b453 x5 : 0000000000000496 x4 : 0000000000000000 x3 : ffff00081193a29c x2 : 0000000000000001 x1 : 0000000000000000 x0 : ffff000814591620 Call trace: xhci_disable_hub_port_wake.isra.62+0x60/0xf8 xhci_suspend+0x58/0x510 xhci_plat_suspend+0x50/0x78 platform_pm_suspend+0x2c/0x78 dpm_run_callback.isra.25+0x50/0xe8 __device_suspend+0x108/0x3c0 The basic flow: 1. run time suspend call xhci_suspend, xhci parent devices gate the clock. 2. echo mem >/sys/power/state, system _device_suspend call xhci_suspend 3. xhci_suspend call xhci_disable_hub_port_wake, which access register, but clock already gated by run time suspend. This problem was hidden by power domain driver, which call run time resume before it. But the below commit remove it and make this issue happen. commit c1df456d0f06e ("PM: domains: Don't runtime resume devices at genpd_prepare()") This patch call run time resume before suspend to make sure clock is on before access register. Testeb-by: Abel Vesa <[email protected]> Solution(s) debian-upgrade-linux References https://attackerkb.com/topics/cve-2022-48761 CVE - 2022-48761

Debian: CVE-2022-48757: linux -- security update Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 06/20/2024 Created 07/31/2024 Added 07/30/2024 Modified 07/30/2024 Description In the Linux kernel, the following vulnerability has been resolved: net: fix information leakage in /proc/net/ptype In one net namespace, after creating a packet socket without binding it to a device, users in other net namespaces can observe the new `packet_type` added by this packet socket by reading `/proc/net/ptype` file. This is minor information leakage as packet socket is namespace aware. Add a net pointer in `packet_type` to keep the net namespace of of corresponding packet socket. In `ptype_seq_show`, this net pointer must be checked when it is not NULL. Solution(s) debian-upgrade-linux References https://attackerkb.com/topics/cve-2022-48757 CVE - 2022-48757

Debian: CVE-2022-48756: linux -- security update Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 06/20/2024 Created 07/31/2024 Added 07/30/2024 Modified 01/30/2025 Description In the Linux kernel, the following vulnerability has been resolved: drm/msm/dsi: invalid parameter check in msm_dsi_phy_enable The function performs a check on the "phy" input parameter, however, it is used before the check. Initialize the "dev" variable after the sanity check to avoid a possible NULL pointer dereference. Addresses-Coverity-ID: 1493860 ("Null pointer dereference") Solution(s) debian-upgrade-linux References https://attackerkb.com/topics/cve-2022-48756 CVE - 2022-48756

Debian: CVE-2022-48755: linux -- security update Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 06/20/2024 Created 07/31/2024 Added 07/30/2024 Modified 01/30/2025 Description In the Linux kernel, the following vulnerability has been resolved: powerpc64/bpf: Limit 'ldbrx' to processors compliant with ISA v2.06 Johan reported the below crash with test_bpf on ppc64 e5500: test_bpf: #296 ALU_END_FROM_LE 64: 0x0123456789abcdef -> 0x67452301 jited:1 Oops: Exception in kernel mode, sig: 4 [#1] BE PAGE_SIZE=4K SMP NR_CPUS=24 QEMU e500 Modules linked in: test_bpf(+) CPU: 0 PID: 76 Comm: insmod Not tainted 5.14.0-03771-g98c2059e008a-dirty #1 NIP:8000000000061c3c LR: 80000000006dea64 CTR: 8000000000061c18 REGS: c0000000032d3420 TRAP: 0700 Not tainted (5.14.0-03771-g98c2059e008a-dirty) MSR:0000000080089000 <EE,ME>CR: 88002822XER: 20000000 IRQMASK: 0 <...> NIP [8000000000061c3c] 0x8000000000061c3c LR [80000000006dea64] .__run_one+0x104/0x17c [test_bpf] Call Trace: .__run_one+0x60/0x17c [test_bpf] (unreliable) .test_bpf_init+0x6a8/0xdc8 [test_bpf] .do_one_initcall+0x6c/0x28c .do_init_module+0x68/0x28c .load_module+0x2460/0x2abc .__do_sys_init_module+0x120/0x18c .system_call_exception+0x110/0x1b8 system_call_common+0xf0/0x210 --- interrupt: c00 at 0x101d0acc <...> ---[ end trace 47b2bf19090bb3d0 ]--- Illegal instruction The illegal instruction turned out to be 'ldbrx' emitted for BPF_FROM_[L|B]E, which was only introduced in ISA v2.06. Guard use of the same and implement an alternative approach for older processors. Solution(s) debian-upgrade-linux References https://attackerkb.com/topics/cve-2022-48755 CVE - 2022-48755

Debian: CVE-2022-48754: linux -- security update Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 06/20/2024 Created 07/31/2024 Added 07/30/2024 Modified 07/30/2024 Description In the Linux kernel, the following vulnerability has been resolved: phylib: fix potential use-after-free Commit bafbdd527d56 ("phylib: Add device reset GPIO support") added call to phy_device_reset(phydev) after the put_device() call in phy_detach(). The comment before the put_device() call says that the phydev might go away with put_device(). Fix potential use-after-free by calling phy_device_reset() before put_device(). Solution(s) debian-upgrade-linux References https://attackerkb.com/topics/cve-2022-48754 CVE - 2022-48754

Debian: CVE-2022-48753: linux -- security update Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 06/20/2024 Created 07/31/2024 Added 07/30/2024 Modified 01/30/2025 Description In the Linux kernel, the following vulnerability has been resolved: block: fix memory leak in disk_register_independent_access_ranges kobject_init_and_add() takes reference even when it fails. According to the doc of kobject_init_and_add() If this function returns an error, kobject_put() must be called to properly clean up the memory associated with the object. Fix this issue by adding kobject_put(). Callback function blk_ia_ranges_sysfs_release() in kobject_put() can handle the pointer "iars" properly. Solution(s) debian-upgrade-linux References https://attackerkb.com/topics/cve-2022-48753 CVE - 2022-48753

Huawei EulerOS: CVE-2022-48748: kernel security update Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 06/20/2024 Created 12/13/2024 Added 12/12/2024 Modified 12/12/2024 Description In the Linux kernel, the following vulnerability has been resolved: net: bridge: vlan: fix memory leak in __allowed_ingress When using per-vlan state, if vlan snooping and stats are disabled, untagged or priority-tagged ingress frame will go to check pvid state. If the port state is forwarding and the pvid state is not learning/forwarding, untagged or priority-tagged frame will be dropped but skb memory is not freed. Should free skb when __allowed_ingress returns false. Solution(s) huawei-euleros-2_0_sp12-upgrade-bpftool huawei-euleros-2_0_sp12-upgrade-kernel huawei-euleros-2_0_sp12-upgrade-kernel-abi-stablelists huawei-euleros-2_0_sp12-upgrade-kernel-tools huawei-euleros-2_0_sp12-upgrade-kernel-tools-libs huawei-euleros-2_0_sp12-upgrade-python3-perf References https://attackerkb.com/topics/cve-2022-48748 CVE - 2022-48748 EulerOS-SA-2024-2953

Huawei EulerOS: CVE-2022-48746: kernel security update Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 06/20/2024 Created 10/10/2024 Added 10/09/2024 Modified 01/28/2025 Description In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Fix handling of wrong devices during bond netevent Current implementation of bond netevent handler only check if the handled netdev is VF representor and it missing a check if the VF representor is on the same phys device of the bond handling the netevent. Fix by adding the missing check and optimizing the check if the netdev is VF representor so it will not access uninitialized private data and crashes. BUG: kernel NULL pointer dereference, address: 000000000000036c PGD 0 P4D 0 Oops: 0000 [#1] SMP NOPTI Workqueue: eth3bond0 bond_mii_monitor [bonding] RIP: 0010:mlx5e_is_uplink_rep+0xc/0x50 [mlx5_core] RSP: 0018:ffff88812d69fd60 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffff8881cf800000 RCX: 0000000000000000 RDX: ffff88812d69fe10 RSI: 000000000000001b RDI: ffff8881cf800880 RBP: ffff8881cf800000 R08: 00000445cabccf2b R09: 0000000000000008 R10: 0000000000000004 R11: 0000000000000008 R12: ffff88812d69fe10 R13: 00000000fffffffe R14: ffff88820c0f9000 R15: 0000000000000000 FS:0000000000000000(0000) GS:ffff88846fb00000(0000) knlGS:0000000000000000 CS:0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000000000036c CR3: 0000000103d80006 CR4: 0000000000370ea0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: mlx5e_eswitch_uplink_rep+0x31/0x40 [mlx5_core] mlx5e_rep_is_lag_netdev+0x94/0xc0 [mlx5_core] mlx5e_rep_esw_bond_netevent+0xeb/0x3d0 [mlx5_core] raw_notifier_call_chain+0x41/0x60 call_netdevice_notifiers_info+0x34/0x80 netdev_lower_state_changed+0x4e/0xa0 bond_mii_monitor+0x56b/0x640 [bonding] process_one_work+0x1b9/0x390 worker_thread+0x4d/0x3d0 ? rescuer_thread+0x350/0x350 kthread+0x124/0x150 ? set_kthread_struct+0x40/0x40 ret_from_fork+0x1f/0x30 Solution(s) huawei-euleros-2_0_sp12-upgrade-bpftool huawei-euleros-2_0_sp12-upgrade-kernel huawei-euleros-2_0_sp12-upgrade-kernel-abi-stablelists huawei-euleros-2_0_sp12-upgrade-kernel-tools huawei-euleros-2_0_sp12-upgrade-kernel-tools-libs huawei-euleros-2_0_sp12-upgrade-python3-perf References https://attackerkb.com/topics/cve-2022-48746 CVE - 2022-48746 EulerOS-SA-2024-2544

Huawei EulerOS: CVE-2022-48771: kernel security update Severity 7 CVSS (AV:L/AC:L/Au:S/C:C/I:C/A:C) Published 06/20/2024 Created 10/10/2024 Added 10/09/2024 Modified 01/30/2025 Description In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: Fix stale file descriptors on failed usercopy A failing usercopy of the fence_rep object will lead to a stale entry in the file descriptor table as put_unused_fd() won't release it. This enables userland to refer to a dangling 'file' object through that still valid file descriptor, leading to all kinds of use-after-free exploitation scenarios. Fix this by deferring the call to fd_install() until after the usercopy has succeeded. Solution(s) huawei-euleros-2_0_sp12-upgrade-bpftool huawei-euleros-2_0_sp12-upgrade-kernel huawei-euleros-2_0_sp12-upgrade-kernel-abi-stablelists huawei-euleros-2_0_sp12-upgrade-kernel-tools huawei-euleros-2_0_sp12-upgrade-kernel-tools-libs huawei-euleros-2_0_sp12-upgrade-python3-perf References https://attackerkb.com/topics/cve-2022-48771 CVE - 2022-48771 EulerOS-SA-2024-2544

Huawei EulerOS: CVE-2022-48767: kernel security update Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 06/20/2024 Created 10/10/2024 Added 10/09/2024 Modified 10/09/2024 Description In the Linux kernel, the following vulnerability has been resolved: ceph: properly put ceph_string reference after async create attempt The reference acquired by try_prep_async_create is currently leaked. Ensure we put it. Solution(s) huawei-euleros-2_0_sp12-upgrade-bpftool huawei-euleros-2_0_sp12-upgrade-kernel huawei-euleros-2_0_sp12-upgrade-kernel-abi-stablelists huawei-euleros-2_0_sp12-upgrade-kernel-tools huawei-euleros-2_0_sp12-upgrade-kernel-tools-libs huawei-euleros-2_0_sp12-upgrade-python3-perf References https://attackerkb.com/topics/cve-2022-48767 CVE - 2022-48767 EulerOS-SA-2024-2544