ISHACK AI BOT

Red Hat: CVE-2022-48760: kernel: USB: core: Fix hang in usb_kill_urb by adding memory barriers (Multiple Advisories) Severity 4 CVSS (AV:L/AC:H/Au:M/C:N/I:N/A:C) Published 06/20/2024 Created 09/26/2024 Added 09/25/2024 Modified 09/25/2024 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 0 CPU 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) redhat-upgrade-kernel redhat-upgrade-kernel-rt References CVE-2022-48760 RHSA-2024:7000 RHSA-2024:7001

Red Hat: CVE-2022-48757: kernel: net: fix information leakage in /proc/net/ptype (Multiple Advisories) Severity 2 CVSS (AV:L/AC:L/Au:S/C:P/I:N/A:N) Published 06/20/2024 Created 08/13/2024 Added 08/12/2024 Modified 09/13/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) redhat-upgrade-kernel redhat-upgrade-kernel-rt References CVE-2022-48757 RHSA-2024:5101 RHSA-2024:5102 RHSA-2024:6206

Debian: CVE-2021-47620: linux -- security update Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:C/A:N) 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: Bluetooth: refactor malicious adv data check Check for out-of-bound read was being performed at the end of while num_reports loop, and would fill journal with false positives. Added check to beginning of loop processing so that it doesn't get checked after ptr has been advanced. Solution(s) debian-upgrade-linux References https://attackerkb.com/topics/cve-2021-47620 CVE - 2021-47620

Debian: CVE-2021-47617: 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: PCI: pciehp: Fix infinite loop in IRQ handler upon power fault The Power Fault Detected bit in the Slot Status register differs from all other hotplug events in that it is sticky:It can only be cleared after turning off slot power.Per PCIe r5.0, sec. 6.7.1.8: If a power controller detects a main power fault on the hot-plug slot, it must automatically set its internal main power fault latch [...]. The main power fault latch is cleared when software turns off power to the hot-plug slot. The stickiness used to cause interrupt storms and infinite loops which were fixed in 2009 by commits 5651c48cfafe ("PCI pciehp: fix power fault interrupt storm problem") and 99f0169c17f3 ("PCI: pciehp: enable software notification on empty slots"). Unfortunately in 2020 the infinite loop issue was inadvertently reintroduced by commit 8edf5332c393 ("PCI: pciehp: Fix MSI interrupt race"):The hardirq handler pciehp_isr() clears the PFD bit until pciehp's power_fault_detected flag is set.That happens in the IRQ thread pciehp_ist(), which never learns of the event because the hardirq handler is stuck in an infinite loop.Fix by setting the power_fault_detected flag already in the hardirq handler. Solution(s) debian-upgrade-linux References https://attackerkb.com/topics/cve-2021-47617 CVE - 2021-47617

Huawei EulerOS: CVE-2022-48713: 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: perf/x86/intel/pt: Fix crash with stop filters in single-range mode Add a check for !buf->single before calling pt_buffer_region_size in a place where a missing check can cause a kernel crash. Fixes a bug introduced by commit 670638477aed ("perf/x86/intel/pt: Opportunistically use single range output mode"), which added a support for PT single-range output mode. Since that commit if a PT stop filter range is hit while tracing, the kernel will crash because of a null pointer dereference in pt_handle_status due to calling pt_buffer_region_size without a ToPA configured. The commit which introduced single-range mode guarded almost all uses of the ToPA buffer variables with checks of the buf->single variable, but missed the case where tracing was stopped by the PT hardware, which happens when execution hits a configured stop filter. Tested that hitting a stop filter while PT recording successfully records a trace with this patch but crashes without this patch. 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-48713 CVE - 2022-48713 EulerOS-SA-2024-2544

Red Hat: CVE-2024-38619: kernel: usb-storage: alauda: Check whether the media is initialized (Multiple Advisories) Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 06/20/2024 Created 09/26/2024 Added 09/25/2024 Modified 12/05/2024 Description In the Linux kernel, the following vulnerability has been resolved: usb-storage: alauda: Check whether the media is initialized The member "uzonesize" of struct alauda_info will remain 0 if alauda_init_media() fails, potentially causing divide errors in alauda_read_data() and alauda_write_lba(). - Add a member "media_initialized" to struct alauda_info. - Change a condition in alauda_check_media() to ensure the first initialization. - Add an error check for the return value of alauda_init_media(). Solution(s) redhat-upgrade-kernel redhat-upgrade-kernel-rt References CVE-2024-38619 RHSA-2024:6567 RHSA-2024:7000 RHSA-2024:7001

SUSE: CVE-2022-48735: SUSE Linux Security Advisory Severity 7 CVSS (AV:L/AC:L/Au:S/C:C/I:C/A:C) Published 06/20/2024 Created 08/16/2024 Added 08/09/2024 Modified 01/28/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) suse-upgrade-cluster-md-kmp-azure suse-upgrade-cluster-md-kmp-rt suse-upgrade-dlm-kmp-azure suse-upgrade-dlm-kmp-rt suse-upgrade-gfs2-kmp-azure suse-upgrade-gfs2-kmp-rt suse-upgrade-kernel-azure suse-upgrade-kernel-azure-devel suse-upgrade-kernel-azure-extra suse-upgrade-kernel-azure-livepatch-devel suse-upgrade-kernel-azure-optional suse-upgrade-kernel-azure-vdso suse-upgrade-kernel-devel-azure suse-upgrade-kernel-devel-rt suse-upgrade-kernel-rt suse-upgrade-kernel-rt-devel suse-upgrade-kernel-rt-extra suse-upgrade-kernel-rt-livepatch suse-upgrade-kernel-rt-livepatch-devel suse-upgrade-kernel-rt-optional suse-upgrade-kernel-rt-vdso suse-upgrade-kernel-rt_debug suse-upgrade-kernel-rt_debug-devel suse-upgrade-kernel-rt_debug-livepatch-devel suse-upgrade-kernel-rt_debug-vdso suse-upgrade-kernel-source-azure suse-upgrade-kernel-source-rt suse-upgrade-kernel-syms-azure suse-upgrade-kernel-syms-rt suse-upgrade-kselftests-kmp-azure suse-upgrade-kselftests-kmp-rt suse-upgrade-ocfs2-kmp-azure suse-upgrade-ocfs2-kmp-rt suse-upgrade-reiserfs-kmp-azure suse-upgrade-reiserfs-kmp-rt References https://attackerkb.com/topics/cve-2022-48735 CVE - 2022-48735

SUSE: CVE-2022-48769: SUSE Linux Security Advisory Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 06/20/2024 Created 08/16/2024 Added 08/09/2024 Modified 08/09/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) suse-upgrade-cluster-md-kmp-azure suse-upgrade-cluster-md-kmp-rt suse-upgrade-dlm-kmp-azure suse-upgrade-dlm-kmp-rt suse-upgrade-gfs2-kmp-azure suse-upgrade-gfs2-kmp-rt suse-upgrade-kernel-azure suse-upgrade-kernel-azure-devel suse-upgrade-kernel-azure-extra suse-upgrade-kernel-azure-livepatch-devel suse-upgrade-kernel-azure-optional suse-upgrade-kernel-azure-vdso suse-upgrade-kernel-devel-azure suse-upgrade-kernel-devel-rt suse-upgrade-kernel-rt suse-upgrade-kernel-rt-devel suse-upgrade-kernel-rt-extra suse-upgrade-kernel-rt-livepatch suse-upgrade-kernel-rt-livepatch-devel suse-upgrade-kernel-rt-optional suse-upgrade-kernel-rt-vdso suse-upgrade-kernel-rt_debug suse-upgrade-kernel-rt_debug-devel suse-upgrade-kernel-rt_debug-livepatch-devel suse-upgrade-kernel-rt_debug-vdso suse-upgrade-kernel-source-azure suse-upgrade-kernel-source-rt suse-upgrade-kernel-syms-azure suse-upgrade-kernel-syms-rt suse-upgrade-kselftests-kmp-azure suse-upgrade-kselftests-kmp-rt suse-upgrade-ocfs2-kmp-azure suse-upgrade-ocfs2-kmp-rt suse-upgrade-reiserfs-kmp-azure suse-upgrade-reiserfs-kmp-rt References https://attackerkb.com/topics/cve-2022-48769 CVE - 2022-48769

SUSE: CVE-2022-48768: SUSE Linux Security Advisory Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 06/20/2024 Created 08/16/2024 Added 08/09/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) suse-upgrade-cluster-md-kmp-azure suse-upgrade-cluster-md-kmp-rt suse-upgrade-dlm-kmp-azure suse-upgrade-dlm-kmp-rt suse-upgrade-gfs2-kmp-azure suse-upgrade-gfs2-kmp-rt suse-upgrade-kernel-64kb suse-upgrade-kernel-64kb-devel suse-upgrade-kernel-azure suse-upgrade-kernel-azure-devel suse-upgrade-kernel-azure-extra suse-upgrade-kernel-azure-livepatch-devel suse-upgrade-kernel-azure-optional suse-upgrade-kernel-azure-vdso suse-upgrade-kernel-default suse-upgrade-kernel-default-base suse-upgrade-kernel-default-devel suse-upgrade-kernel-devel suse-upgrade-kernel-devel-azure suse-upgrade-kernel-devel-rt suse-upgrade-kernel-docs suse-upgrade-kernel-macros suse-upgrade-kernel-obs-build suse-upgrade-kernel-preempt suse-upgrade-kernel-preempt-devel suse-upgrade-kernel-rt suse-upgrade-kernel-rt-devel suse-upgrade-kernel-rt-extra suse-upgrade-kernel-rt-livepatch suse-upgrade-kernel-rt-livepatch-devel suse-upgrade-kernel-rt-optional suse-upgrade-kernel-rt-vdso suse-upgrade-kernel-rt_debug suse-upgrade-kernel-rt_debug-devel suse-upgrade-kernel-rt_debug-livepatch-devel suse-upgrade-kernel-rt_debug-vdso suse-upgrade-kernel-source suse-upgrade-kernel-source-azure suse-upgrade-kernel-source-rt suse-upgrade-kernel-syms suse-upgrade-kernel-syms-azure suse-upgrade-kernel-syms-rt suse-upgrade-kernel-zfcpdump suse-upgrade-kselftests-kmp-azure suse-upgrade-kselftests-kmp-rt suse-upgrade-ocfs2-kmp-azure suse-upgrade-ocfs2-kmp-rt suse-upgrade-reiserfs-kmp-azure suse-upgrade-reiserfs-kmp-default suse-upgrade-reiserfs-kmp-rt References https://attackerkb.com/topics/cve-2022-48768 CVE - 2022-48768

SUSE: CVE-2022-48760: SUSE Linux Security Advisory Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 06/20/2024 Created 08/16/2024 Added 08/09/2024 Modified 08/09/2024 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 0 CPU 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) suse-upgrade-cluster-md-kmp-azure suse-upgrade-cluster-md-kmp-rt suse-upgrade-dlm-kmp-azure suse-upgrade-dlm-kmp-rt suse-upgrade-gfs2-kmp-azure suse-upgrade-gfs2-kmp-rt suse-upgrade-kernel-64kb suse-upgrade-kernel-64kb-devel suse-upgrade-kernel-azure suse-upgrade-kernel-azure-base suse-upgrade-kernel-azure-devel suse-upgrade-kernel-azure-extra suse-upgrade-kernel-azure-livepatch-devel suse-upgrade-kernel-azure-optional suse-upgrade-kernel-azure-vdso suse-upgrade-kernel-default suse-upgrade-kernel-default-base suse-upgrade-kernel-default-devel suse-upgrade-kernel-default-extra suse-upgrade-kernel-default-man suse-upgrade-kernel-devel suse-upgrade-kernel-devel-azure suse-upgrade-kernel-devel-rt suse-upgrade-kernel-docs suse-upgrade-kernel-macros suse-upgrade-kernel-obs-build suse-upgrade-kernel-preempt suse-upgrade-kernel-preempt-devel suse-upgrade-kernel-rt suse-upgrade-kernel-rt-devel suse-upgrade-kernel-rt-extra suse-upgrade-kernel-rt-livepatch suse-upgrade-kernel-rt-livepatch-devel suse-upgrade-kernel-rt-optional suse-upgrade-kernel-rt-vdso suse-upgrade-kernel-rt_debug suse-upgrade-kernel-rt_debug-devel suse-upgrade-kernel-rt_debug-livepatch-devel suse-upgrade-kernel-rt_debug-vdso suse-upgrade-kernel-source suse-upgrade-kernel-source-azure suse-upgrade-kernel-source-rt suse-upgrade-kernel-syms suse-upgrade-kernel-syms-azure suse-upgrade-kernel-syms-rt suse-upgrade-kernel-zfcpdump suse-upgrade-kselftests-kmp-azure suse-upgrade-kselftests-kmp-rt suse-upgrade-ocfs2-kmp-azure suse-upgrade-ocfs2-kmp-rt suse-upgrade-reiserfs-kmp-azure suse-upgrade-reiserfs-kmp-default suse-upgrade-reiserfs-kmp-rt References https://attackerkb.com/topics/cve-2022-48760 CVE - 2022-48760

SUSE: CVE-2022-48765: SUSE Linux Security Advisory Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 06/20/2024 Created 08/16/2024 Added 08/09/2024 Modified 08/09/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) suse-upgrade-cluster-md-kmp-azure suse-upgrade-cluster-md-kmp-rt suse-upgrade-dlm-kmp-azure suse-upgrade-dlm-kmp-rt suse-upgrade-gfs2-kmp-azure suse-upgrade-gfs2-kmp-rt suse-upgrade-kernel-azure suse-upgrade-kernel-azure-devel suse-upgrade-kernel-azure-extra suse-upgrade-kernel-azure-livepatch-devel suse-upgrade-kernel-azure-optional suse-upgrade-kernel-azure-vdso suse-upgrade-kernel-devel-azure suse-upgrade-kernel-devel-rt suse-upgrade-kernel-rt suse-upgrade-kernel-rt-devel suse-upgrade-kernel-rt-extra suse-upgrade-kernel-rt-livepatch suse-upgrade-kernel-rt-livepatch-devel suse-upgrade-kernel-rt-optional suse-upgrade-kernel-rt-vdso suse-upgrade-kernel-rt_debug suse-upgrade-kernel-rt_debug-devel suse-upgrade-kernel-rt_debug-livepatch-devel suse-upgrade-kernel-rt_debug-vdso suse-upgrade-kernel-source-azure suse-upgrade-kernel-source-rt suse-upgrade-kernel-syms-azure suse-upgrade-kernel-syms-rt suse-upgrade-kselftests-kmp-azure suse-upgrade-kselftests-kmp-rt suse-upgrade-ocfs2-kmp-azure suse-upgrade-ocfs2-kmp-rt suse-upgrade-reiserfs-kmp-azure suse-upgrade-reiserfs-kmp-rt References https://attackerkb.com/topics/cve-2022-48765 CVE - 2022-48765

SUSE: CVE-2021-47617: SUSE Linux Security Advisory Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 06/20/2024 Created 08/16/2024 Added 08/09/2024 Modified 01/28/2025 Description In the Linux kernel, the following vulnerability has been resolved: PCI: pciehp: Fix infinite loop in IRQ handler upon power fault The Power Fault Detected bit in the Slot Status register differs from all other hotplug events in that it is sticky:It can only be cleared after turning off slot power.Per PCIe r5.0, sec. 6.7.1.8: If a power controller detects a main power fault on the hot-plug slot, it must automatically set its internal main power fault latch [...]. The main power fault latch is cleared when software turns off power to the hot-plug slot. The stickiness used to cause interrupt storms and infinite loops which were fixed in 2009 by commits 5651c48cfafe ("PCI pciehp: fix power fault interrupt storm problem") and 99f0169c17f3 ("PCI: pciehp: enable software notification on empty slots"). Unfortunately in 2020 the infinite loop issue was inadvertently reintroduced by commit 8edf5332c393 ("PCI: pciehp: Fix MSI interrupt race"):The hardirq handler pciehp_isr() clears the PFD bit until pciehp's power_fault_detected flag is set.That happens in the IRQ thread pciehp_ist(), which never learns of the event because the hardirq handler is stuck in an infinite loop.Fix by setting the power_fault_detected flag already in the hardirq handler. Solution(s) suse-upgrade-cluster-md-kmp-azure suse-upgrade-cluster-md-kmp-rt suse-upgrade-dlm-kmp-azure suse-upgrade-dlm-kmp-rt suse-upgrade-gfs2-kmp-azure suse-upgrade-gfs2-kmp-rt suse-upgrade-kernel-64kb suse-upgrade-kernel-64kb-devel suse-upgrade-kernel-azure suse-upgrade-kernel-azure-base suse-upgrade-kernel-azure-devel suse-upgrade-kernel-azure-extra suse-upgrade-kernel-azure-livepatch-devel suse-upgrade-kernel-azure-optional suse-upgrade-kernel-azure-vdso suse-upgrade-kernel-default suse-upgrade-kernel-default-base suse-upgrade-kernel-default-devel suse-upgrade-kernel-default-extra suse-upgrade-kernel-default-man suse-upgrade-kernel-devel suse-upgrade-kernel-devel-azure suse-upgrade-kernel-devel-rt suse-upgrade-kernel-docs suse-upgrade-kernel-macros suse-upgrade-kernel-obs-build suse-upgrade-kernel-preempt suse-upgrade-kernel-preempt-devel suse-upgrade-kernel-rt suse-upgrade-kernel-rt-devel suse-upgrade-kernel-rt-extra suse-upgrade-kernel-rt-livepatch suse-upgrade-kernel-rt-livepatch-devel suse-upgrade-kernel-rt-optional suse-upgrade-kernel-rt-vdso suse-upgrade-kernel-rt_debug suse-upgrade-kernel-rt_debug-devel suse-upgrade-kernel-rt_debug-livepatch-devel suse-upgrade-kernel-rt_debug-vdso suse-upgrade-kernel-source suse-upgrade-kernel-source-azure suse-upgrade-kernel-source-rt suse-upgrade-kernel-syms suse-upgrade-kernel-syms-azure suse-upgrade-kernel-syms-rt suse-upgrade-kernel-zfcpdump suse-upgrade-kselftests-kmp-azure suse-upgrade-kselftests-kmp-rt suse-upgrade-ocfs2-kmp-azure suse-upgrade-ocfs2-kmp-rt suse-upgrade-reiserfs-kmp-azure suse-upgrade-reiserfs-kmp-default suse-upgrade-reiserfs-kmp-rt References https://attackerkb.com/topics/cve-2021-47617 CVE - 2021-47617

IBM WebSphere Application Server: CVE-2024-37532: IBM WebSphere Application Server is vulnerable to identity spoofing (CVE-2024-37532) Severity 9 CVSS (AV:N/AC:L/Au:S/C:C/I:C/A:C) Published 06/20/2024 Created 06/20/2024 Added 06/20/2024 Modified 01/28/2025 Description IBM WebSphere Application Server 8.5 and 9.0 is vulnerable to identity spoofing by an authenticated user due to improper signature validation.IBM X-Force ID:294721. Solution(s) ibm-was-install-8-5-0-0-ph61504 ibm-was-install-9-0-0-0-ph61504 ibm-was-upgrade-8-5-0-0-8-5-5-26 ibm-was-upgrade-9-0-0-0-9-0-5-21 References https://attackerkb.com/topics/cve-2024-37532 CVE - 2024-37532 https://exchange.xforce.ibmcloud.com/vulnerabilities/294721 https://www.ibm.com/support/pages/node/7158031

SUSE: CVE-2021-47619: SUSE Linux Security Advisory Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 06/20/2024 Created 08/16/2024 Added 08/09/2024 Modified 01/28/2025 Description In the Linux kernel, the following vulnerability has been resolved: i40e: Fix queues reservation for XDP When XDP was configured on a system with large number of CPUs and X722 NIC there was a call trace with NULL pointer dereference. i40e 0000:87:00.0: failed to get tracking for 256 queues for VSI 0 err -12 i40e 0000:87:00.0: setup of MAIN VSI failed BUG: kernel NULL pointer dereference, address: 0000000000000000 RIP: 0010:i40e_xdp+0xea/0x1b0 [i40e] Call Trace: ? i40e_reconfig_rss_queues+0x130/0x130 [i40e] dev_xdp_install+0x61/0xe0 dev_xdp_attach+0x18a/0x4c0 dev_change_xdp_fd+0x1e6/0x220 do_setlink+0x616/0x1030 ? ahci_port_stop+0x80/0x80 ? ata_qc_issue+0x107/0x1e0 ? lock_timer_base+0x61/0x80 ? __mod_timer+0x202/0x380 rtnl_setlink+0xe5/0x170 ? bpf_lsm_binder_transaction+0x10/0x10 ? security_capable+0x36/0x50 rtnetlink_rcv_msg+0x121/0x350 ? rtnl_calcit.isra.0+0x100/0x100 netlink_rcv_skb+0x50/0xf0 netlink_unicast+0x1d3/0x2a0 netlink_sendmsg+0x22a/0x440 sock_sendmsg+0x5e/0x60 __sys_sendto+0xf0/0x160 ? __sys_getsockname+0x7e/0xc0 ? _copy_from_user+0x3c/0x80 ? __sys_setsockopt+0xc8/0x1a0 __x64_sys_sendto+0x20/0x30 do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7f83fa7a39e0 This was caused by PF queue pile fragmentation due to flow director VSI queue being placed right after main VSI. Because of this main VSI was not able to resize its queue allocation for XDP resulting in no queues allocated for main VSI when XDP was turned on. Fix this by always allocating last queue in PF queue pile for a flow director VSI. Solution(s) suse-upgrade-cluster-md-kmp-azure suse-upgrade-cluster-md-kmp-rt suse-upgrade-dlm-kmp-azure suse-upgrade-dlm-kmp-rt suse-upgrade-gfs2-kmp-azure suse-upgrade-gfs2-kmp-rt suse-upgrade-kernel-64kb suse-upgrade-kernel-64kb-devel suse-upgrade-kernel-azure suse-upgrade-kernel-azure-devel suse-upgrade-kernel-azure-extra suse-upgrade-kernel-azure-livepatch-devel suse-upgrade-kernel-azure-optional suse-upgrade-kernel-azure-vdso suse-upgrade-kernel-default suse-upgrade-kernel-default-base suse-upgrade-kernel-default-devel suse-upgrade-kernel-devel suse-upgrade-kernel-devel-azure suse-upgrade-kernel-devel-rt suse-upgrade-kernel-docs suse-upgrade-kernel-macros suse-upgrade-kernel-obs-build suse-upgrade-kernel-preempt suse-upgrade-kernel-preempt-devel suse-upgrade-kernel-rt suse-upgrade-kernel-rt-devel suse-upgrade-kernel-rt-extra suse-upgrade-kernel-rt-livepatch suse-upgrade-kernel-rt-livepatch-devel suse-upgrade-kernel-rt-optional suse-upgrade-kernel-rt-vdso suse-upgrade-kernel-rt_debug suse-upgrade-kernel-rt_debug-devel suse-upgrade-kernel-rt_debug-livepatch-devel suse-upgrade-kernel-rt_debug-vdso suse-upgrade-kernel-source suse-upgrade-kernel-source-azure suse-upgrade-kernel-source-rt suse-upgrade-kernel-syms suse-upgrade-kernel-syms-azure suse-upgrade-kernel-syms-rt suse-upgrade-kernel-zfcpdump suse-upgrade-kselftests-kmp-azure suse-upgrade-kselftests-kmp-rt suse-upgrade-ocfs2-kmp-azure suse-upgrade-ocfs2-kmp-rt suse-upgrade-reiserfs-kmp-azure suse-upgrade-reiserfs-kmp-default suse-upgrade-reiserfs-kmp-rt References https://attackerkb.com/topics/cve-2021-47619 CVE - 2021-47619

Huawei EulerOS: CVE-2022-48742: kernel security update Severity 7 CVSS (AV:L/AC:L/Au:S/C:C/I:C/A:C) Published 06/20/2024 Created 01/23/2025 Added 01/21/2025 Modified 01/28/2025 Description In the Linux kernel, the following vulnerability has been resolved: rtnetlink: make sure to refresh master_dev/m_ops in __rtnl_newlink() While looking at one unrelated syzbot bug, I found the replay logic in __rtnl_newlink() to potentially trigger use-after-free. It is better to clear master_dev and m_ops inside the loop, in case we have to replay it. Solution(s) huawei-euleros-2_0_sp8-upgrade-bpftool huawei-euleros-2_0_sp8-upgrade-kernel huawei-euleros-2_0_sp8-upgrade-kernel-devel huawei-euleros-2_0_sp8-upgrade-kernel-headers huawei-euleros-2_0_sp8-upgrade-kernel-tools huawei-euleros-2_0_sp8-upgrade-kernel-tools-libs huawei-euleros-2_0_sp8-upgrade-perf huawei-euleros-2_0_sp8-upgrade-python-perf huawei-euleros-2_0_sp8-upgrade-python3-perf References https://attackerkb.com/topics/cve-2022-48742 CVE - 2022-48742 EulerOS-SA-2025-1123

Ubuntu: (CVE-2022-48723): linux-intel-iotg-5.15 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 01/28/2025 Description In the Linux kernel, the following vulnerability has been resolved: spi: uniphier: fix reference count leak in uniphier_spi_probe() The issue happens in several error paths in uniphier_spi_probe(). When either dma_get_slave_caps() or devm_spi_register_master() returns an error code, the function forgets to decrease the refcount of both `dma_rx` and `dma_tx` objects, which may lead to refcount leaks. Fix it by decrementing the reference count of specific objects in those error paths. Solution(s) ubuntu-upgrade-linux-intel-iotg-5-15 References https://attackerkb.com/topics/cve-2022-48723 CVE - 2022-48723 https://git.kernel.org/linus/37c2c83ca4f1ef4b6908181ac98e18360af89b42 https://git.kernel.org/stable/c/37c2c83ca4f1ef4b6908181ac98e18360af89b42 https://git.kernel.org/stable/c/447c3d4046d7b54052d07d8b27e15e6edea5662c https://git.kernel.org/stable/c/dd00b4f8f768d81c3788a8ac88fdb3d745e55ea3 https://git.kernel.org/stable/c/e895e067d73e154b1ebc84a124e00831e311d9b0 https://www.cve.org/CVERecord?id=CVE-2022-48723 View more

Debian: CVE-2022-48725: 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: RDMA/siw: Fix refcounting leak in siw_create_qp() The atomic_inc() needs to be paired with an atomic_dec() on the error path. Solution(s) debian-upgrade-linux References https://attackerkb.com/topics/cve-2022-48725 CVE - 2022-48725

Debian: CVE-2022-48723: 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: spi: uniphier: fix reference count leak in uniphier_spi_probe() The issue happens in several error paths in uniphier_spi_probe(). When either dma_get_slave_caps() or devm_spi_register_master() returns an error code, the function forgets to decrease the refcount of both `dma_rx` and `dma_tx` objects, which may lead to refcount leaks. Fix it by decrementing the reference count of specific objects in those error paths. Solution(s) debian-upgrade-linux References https://attackerkb.com/topics/cve-2022-48723 CVE - 2022-48723

Debian: CVE-2022-48714: 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: bpf: Use VM_MAP instead of VM_ALLOC for ringbuf After commit 2fd3fb0be1d1 ("kasan, vmalloc: unpoison VM_ALLOC pages after mapping"), non-VM_ALLOC mappings will be marked as accessible in __get_vm_area_node() when KASAN is enabled. But now the flag for ringbuf area is VM_ALLOC, so KASAN will complain out-of-bound access after vmap() returns. Because the ringbuf area is created by mapping allocated pages, so use VM_MAP instead. After the change, info in /proc/vmallocinfo also changes from [start]-[end] 24576 ringbuf_map_alloc+0x171/0x290 vmalloc user to [start]-[end] 24576 ringbuf_map_alloc+0x171/0x290 vmap user Solution(s) debian-upgrade-linux References https://attackerkb.com/topics/cve-2022-48714 CVE - 2022-48714

Debian: CVE-2022-48712: 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: ext4: fix error handling in ext4_fc_record_modified_inode() Current code does not fully takes care of krealloc() error case, which could lead to silent memory corruption or a kernel bug.This patch fixes that. Also it cleans up some duplicated error handling logic from various functions in fast_commit.c file. Solution(s) debian-upgrade-linux References https://attackerkb.com/topics/cve-2022-48712 CVE - 2022-48712

Debian: CVE-2022-48711: 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: tipc: improve size validations for received domain records The function tipc_mon_rcv() allows a node to receive and process domain_record structs from peer nodes to track their views of the network topology. This patch verifies that the number of members in a received domain record does not exceed the limit defined by MAX_MON_DOMAIN, something that may otherwise lead to a stack overflow. tipc_mon_rcv() is called from the function tipc_link_proto_rcv(), where we are reading a 32 bit message data length field into a uint16.To avert any risk of bit overflow, we add an extra sanity check for this in that function.We cannot see that happen with the current code, but future designers being unaware of this risk, may introduce it by allowing delivery of very large (> 64k) sk buffers from the bearer layer.This potential problem was identified by Eric Dumazet. This fixes CVE-2022-0435 Solution(s) debian-upgrade-linux References https://attackerkb.com/topics/cve-2022-48711 CVE - 2022-48711

SUSE: CVE-2022-48711: SUSE Linux Security Advisory Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 06/20/2024 Created 08/16/2024 Added 08/09/2024 Modified 08/09/2024 Description In the Linux kernel, the following vulnerability has been resolved: tipc: improve size validations for received domain records The function tipc_mon_rcv() allows a node to receive and process domain_record structs from peer nodes to track their views of the network topology. This patch verifies that the number of members in a received domain record does not exceed the limit defined by MAX_MON_DOMAIN, something that may otherwise lead to a stack overflow. tipc_mon_rcv() is called from the function tipc_link_proto_rcv(), where we are reading a 32 bit message data length field into a uint16.To avert any risk of bit overflow, we add an extra sanity check for this in that function.We cannot see that happen with the current code, but future designers being unaware of this risk, may introduce it by allowing delivery of very large (> 64k) sk buffers from the bearer layer.This potential problem was identified by Eric Dumazet. This fixes CVE-2022-0435 Solution(s) suse-upgrade-cluster-md-kmp-azure suse-upgrade-cluster-md-kmp-rt suse-upgrade-dlm-kmp-azure suse-upgrade-dlm-kmp-rt suse-upgrade-gfs2-kmp-azure suse-upgrade-gfs2-kmp-rt suse-upgrade-kernel-64kb suse-upgrade-kernel-64kb-devel suse-upgrade-kernel-azure suse-upgrade-kernel-azure-base suse-upgrade-kernel-azure-devel suse-upgrade-kernel-azure-extra suse-upgrade-kernel-azure-livepatch-devel suse-upgrade-kernel-azure-optional suse-upgrade-kernel-azure-vdso suse-upgrade-kernel-default suse-upgrade-kernel-default-base suse-upgrade-kernel-default-devel suse-upgrade-kernel-default-extra suse-upgrade-kernel-default-man suse-upgrade-kernel-devel suse-upgrade-kernel-devel-azure suse-upgrade-kernel-devel-rt suse-upgrade-kernel-docs suse-upgrade-kernel-macros suse-upgrade-kernel-obs-build suse-upgrade-kernel-preempt suse-upgrade-kernel-preempt-devel suse-upgrade-kernel-rt suse-upgrade-kernel-rt-devel suse-upgrade-kernel-rt-extra suse-upgrade-kernel-rt-livepatch suse-upgrade-kernel-rt-livepatch-devel suse-upgrade-kernel-rt-optional suse-upgrade-kernel-rt-vdso suse-upgrade-kernel-rt_debug suse-upgrade-kernel-rt_debug-devel suse-upgrade-kernel-rt_debug-livepatch-devel suse-upgrade-kernel-rt_debug-vdso suse-upgrade-kernel-source suse-upgrade-kernel-source-azure suse-upgrade-kernel-source-rt suse-upgrade-kernel-syms suse-upgrade-kernel-syms-azure suse-upgrade-kernel-syms-rt suse-upgrade-kernel-zfcpdump suse-upgrade-kselftests-kmp-azure suse-upgrade-kselftests-kmp-rt suse-upgrade-ocfs2-kmp-azure suse-upgrade-ocfs2-kmp-rt suse-upgrade-reiserfs-kmp-azure suse-upgrade-reiserfs-kmp-default suse-upgrade-reiserfs-kmp-rt References https://attackerkb.com/topics/cve-2022-48711 CVE - 2022-48711

SUSE: CVE-2022-48729: SUSE Linux Security Advisory Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 06/20/2024 Created 08/16/2024 Added 08/09/2024 Modified 01/28/2025 Description In the Linux kernel, the following vulnerability has been resolved: IB/hfi1: Fix panic with larger ipoib send_queue_size When the ipoib send_queue_size is increased from the default the following panic happens: RIP: 0010:hfi1_ipoib_drain_tx_ring+0x45/0xf0 [hfi1] Code: 31 e4 eb 0f 8b 85 c8 02 00 00 41 83 c4 01 44 39 e0 76 60 8b 8d cc 02 00 00 44 89 e3 be 01 00 00 00 d3 e3 48 03 9d c0 02 00 00 <c7> 83 18 01 00 00 00 00 00 00 48 8b bb 30 01 00 00 e8 25 af a7 e0 RSP: 0018:ffffc9000798f4a0 EFLAGS: 00010286 RAX: 0000000000008000 RBX: ffffc9000aa0f000 RCX: 000000000000000f RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000000 RBP: ffff88810ff08000 R08: ffff88889476d900 R09: 0000000000000101 R10: 0000000000000000 R11: ffffc90006590ff8 R12: 0000000000000200 R13: ffffc9000798fba8 R14: 0000000000000000 R15: 0000000000000001 FS:00007fd0f79cc3c0(0000) GS:ffff88885fb00000(0000) knlGS:0000000000000000 CS:0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffc9000aa0f118 CR3: 0000000889c84001 CR4: 00000000001706e0 Call Trace: <TASK> hfi1_ipoib_napi_tx_disable+0x45/0x60 [hfi1] hfi1_ipoib_dev_stop+0x18/0x80 [hfi1] ipoib_ib_dev_stop+0x1d/0x40 [ib_ipoib] ipoib_stop+0x48/0xc0 [ib_ipoib] __dev_close_many+0x9e/0x110 __dev_change_flags+0xd9/0x210 dev_change_flags+0x21/0x60 do_setlink+0x31c/0x10f0 ? __nla_validate_parse+0x12d/0x1a0 ? __nla_parse+0x21/0x30 ? inet6_validate_link_af+0x5e/0xf0 ? cpumask_next+0x1f/0x20 ? __snmp6_fill_stats64.isra.53+0xbb/0x140 ? __nla_validate_parse+0x47/0x1a0 __rtnl_newlink+0x530/0x910 ? pskb_expand_head+0x73/0x300 ? __kmalloc_node_track_caller+0x109/0x280 ? __nla_put+0xc/0x20 ? cpumask_next_and+0x20/0x30 ? update_sd_lb_stats.constprop.144+0xd3/0x820 ? _raw_spin_unlock_irqrestore+0x25/0x37 ? __wake_up_common_lock+0x87/0xc0 ? kmem_cache_alloc_trace+0x3d/0x3d0 rtnl_newlink+0x43/0x60 The issue happens when the shift that should have been a function of the txq item size mistakenly used the ring size. Fix by using the item size. Solution(s) suse-upgrade-cluster-md-kmp-azure suse-upgrade-cluster-md-kmp-rt suse-upgrade-dlm-kmp-azure suse-upgrade-dlm-kmp-rt suse-upgrade-gfs2-kmp-azure suse-upgrade-gfs2-kmp-rt suse-upgrade-kernel-azure suse-upgrade-kernel-azure-devel suse-upgrade-kernel-azure-extra suse-upgrade-kernel-azure-livepatch-devel suse-upgrade-kernel-azure-optional suse-upgrade-kernel-azure-vdso suse-upgrade-kernel-devel-azure suse-upgrade-kernel-devel-rt suse-upgrade-kernel-rt suse-upgrade-kernel-rt-devel suse-upgrade-kernel-rt-extra suse-upgrade-kernel-rt-livepatch suse-upgrade-kernel-rt-livepatch-devel suse-upgrade-kernel-rt-optional suse-upgrade-kernel-rt-vdso suse-upgrade-kernel-rt_debug suse-upgrade-kernel-rt_debug-devel suse-upgrade-kernel-rt_debug-livepatch-devel suse-upgrade-kernel-rt_debug-vdso suse-upgrade-kernel-source-azure suse-upgrade-kernel-source-rt suse-upgrade-kernel-syms-azure suse-upgrade-kernel-syms-rt suse-upgrade-kselftests-kmp-azure suse-upgrade-kselftests-kmp-rt suse-upgrade-ocfs2-kmp-azure suse-upgrade-ocfs2-kmp-rt suse-upgrade-reiserfs-kmp-azure suse-upgrade-reiserfs-kmp-rt References https://attackerkb.com/topics/cve-2022-48729 CVE - 2022-48729

SUSE: CVE-2022-48723: SUSE Linux Security Advisory Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 06/20/2024 Created 08/16/2024 Added 08/09/2024 Modified 01/28/2025 Description In the Linux kernel, the following vulnerability has been resolved: spi: uniphier: fix reference count leak in uniphier_spi_probe() The issue happens in several error paths in uniphier_spi_probe(). When either dma_get_slave_caps() or devm_spi_register_master() returns an error code, the function forgets to decrease the refcount of both `dma_rx` and `dma_tx` objects, which may lead to refcount leaks. Fix it by decrementing the reference count of specific objects in those error paths. Solution(s) suse-upgrade-cluster-md-kmp-azure suse-upgrade-cluster-md-kmp-rt suse-upgrade-dlm-kmp-azure suse-upgrade-dlm-kmp-rt suse-upgrade-gfs2-kmp-azure suse-upgrade-gfs2-kmp-rt suse-upgrade-kernel-azure suse-upgrade-kernel-azure-devel suse-upgrade-kernel-azure-extra suse-upgrade-kernel-azure-livepatch-devel suse-upgrade-kernel-azure-optional suse-upgrade-kernel-azure-vdso suse-upgrade-kernel-devel-azure suse-upgrade-kernel-devel-rt suse-upgrade-kernel-rt suse-upgrade-kernel-rt-devel suse-upgrade-kernel-rt-extra suse-upgrade-kernel-rt-livepatch suse-upgrade-kernel-rt-livepatch-devel suse-upgrade-kernel-rt-optional suse-upgrade-kernel-rt-vdso suse-upgrade-kernel-rt_debug suse-upgrade-kernel-rt_debug-devel suse-upgrade-kernel-rt_debug-livepatch-devel suse-upgrade-kernel-rt_debug-vdso suse-upgrade-kernel-source-azure suse-upgrade-kernel-source-rt suse-upgrade-kernel-syms-azure suse-upgrade-kernel-syms-rt suse-upgrade-kselftests-kmp-azure suse-upgrade-kselftests-kmp-rt suse-upgrade-ocfs2-kmp-azure suse-upgrade-ocfs2-kmp-rt suse-upgrade-reiserfs-kmp-azure suse-upgrade-reiserfs-kmp-rt References https://attackerkb.com/topics/cve-2022-48723 CVE - 2022-48723

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