ISHACK AI BOT

Debian: CVE-2020-36782: linux -- security update Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 02/28/2024 Created 07/31/2024 Added 07/30/2024 Modified 01/28/2025 Description In the Linux kernel, the following vulnerability has been resolved: i2c: imx-lpi2c: fix reference leak when pm_runtime_get_sync fails The PM reference count is not expected to be incremented on return in lpi2c_imx_master_enable. However, pm_runtime_get_sync will increment the PM reference count even failed. Forgetting to putting operation will result in a reference leak here. Replace it with pm_runtime_resume_and_get to keep usage counter balanced. Solution(s) debian-upgrade-linux References https://attackerkb.com/topics/cve-2020-36782 CVE - 2020-36782

Debian: CVE-2020-36784: linux -- security update Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 02/28/2024 Created 07/31/2024 Added 07/30/2024 Modified 01/28/2025 Description In the Linux kernel, the following vulnerability has been resolved: i2c: cadence: fix reference leak when pm_runtime_get_sync fails The PM reference count is not expected to be incremented on return in functions cdns_i2c_master_xfer and cdns_reg_slave. However, pm_runtime_get_sync will increment pm usage counter even failed. Forgetting to putting operation will result in a reference leak here. Replace it with pm_runtime_resume_and_get to keep usage counter balanced. Solution(s) debian-upgrade-linux References https://attackerkb.com/topics/cve-2020-36784 CVE - 2020-36784

Amazon Linux AMI 2: CVE-2021-47009: Security patch for kernel (ALASKERNEL-5.10-2022-002) Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 02/28/2024 Created 06/11/2024 Added 06/11/2024 Modified 01/30/2025 Description In the Linux kernel, the following vulnerability has been resolved: KEYS: trusted: Fix memory leak on object td Two error return paths are neglecting to free allocated object td, causing a memory leak. Fix this by returning via the error return path that securely kfree's td. Fixes clang scan-build warning: security/keys/trusted-keys/trusted_tpm1.c:496:10: warning: Potential memory leak [unix.Malloc] Solution(s) amazon-linux-ami-2-upgrade-bpftool amazon-linux-ami-2-upgrade-bpftool-debuginfo amazon-linux-ami-2-upgrade-kernel amazon-linux-ami-2-upgrade-kernel-debuginfo amazon-linux-ami-2-upgrade-kernel-debuginfo-common-aarch64 amazon-linux-ami-2-upgrade-kernel-debuginfo-common-x86_64 amazon-linux-ami-2-upgrade-kernel-devel amazon-linux-ami-2-upgrade-kernel-headers amazon-linux-ami-2-upgrade-kernel-tools amazon-linux-ami-2-upgrade-kernel-tools-debuginfo amazon-linux-ami-2-upgrade-kernel-tools-devel amazon-linux-ami-2-upgrade-perf amazon-linux-ami-2-upgrade-perf-debuginfo amazon-linux-ami-2-upgrade-python-perf amazon-linux-ami-2-upgrade-python-perf-debuginfo References https://attackerkb.com/topics/cve-2021-47009 AL2/ALASKERNEL-5.10-2022-002 CVE - 2021-47009

Debian: CVE-2021-47047: linux -- security update Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 02/28/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: spi-zynqmp-gqspi: return -ENOMEM if dma_map_single fails The spi controller supports 44-bit address space on AXI in DMA mode, so set dma_addr_t width to 44-bit to avoid using a swiotlb mapping. In addition, if dma_map_single fails, it should return immediately instead of continuing doing the DMA operation which bases on invalid address. This fixes the following crash which occurs in reading a big block from flash: [123.633577] zynqmp-qspi ff0f0000.spi: swiotlb buffer is full (sz: 4194304 bytes), total 32768 (slots), used 0 (slots) [123.644230] zynqmp-qspi ff0f0000.spi: ERR:rxdma:memory not mapped [123.784625] Unable to handle kernel paging request at virtual address 00000000003fffc0 [123.792536] Mem abort info: [123.795313] ESR = 0x96000145 [123.798351] EC = 0x25: DABT (current EL), IL = 32 bits [123.803655] SET = 0, FnV = 0 [123.806693] EA = 0, S1PTW = 0 [123.809818] Data abort info: [123.812683] ISV = 0, ISS = 0x00000145 [123.816503] CM = 1, WnR = 1 [123.819455] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000805047000 [123.825887] [00000000003fffc0] pgd=0000000803b45003, p4d=0000000803b45003, pud=0000000000000000 [123.834586] Internal error: Oops: 96000145 [#1] PREEMPT SMP Solution(s) debian-upgrade-linux References https://attackerkb.com/topics/cve-2021-47047 CVE - 2021-47047

Debian: CVE-2021-46980: linux -- security update Severity 6 CVSS (AV:L/AC:L/Au:S/C:C/I:N/A:C) Published 02/28/2024 Created 07/31/2024 Added 07/30/2024 Modified 01/30/2025 Description In the Linux kernel, the following vulnerability has been resolved: usb: typec: ucsi: Retrieve all the PDOs instead of just the first 4 commit 4dbc6a4ef06d ("usb: typec: ucsi: save power data objects in PD mode") introduced retrieval of the PDOs when connected to a PD-capable source. But only the first 4 PDOs are received since that is the maximum number that can be fetched at a time given the MESSAGE_IN length limitation (16 bytes). However, as per the PD spec a connected source may advertise up to a maximum of 7 PDOs. If such a source is connected it's possible the PPM could have negotiated a power contract with one of the PDOs at index greater than 4, and would be reflected in the request data object's (RDO) object position field. This would result in an out-of-bounds access when the rdo_index() is used to index into the src_pdos array in ucsi_psy_get_voltage_now(). With the help of the UBSAN -fsanitize=array-bounds checker enabled this exact issue is revealed when connecting to a PD source adapter that advertise 5 PDOs and the PPM enters a contract having selected the 5th one. [151.545106][ T70] Unexpected kernel BRK exception at EL1 [151.545112][ T70] Internal error: BRK handler: f2005512 [#1] PREEMPT SMP ... [151.545499][ T70] pc : ucsi_psy_get_prop+0x208/0x20c [151.545507][ T70] lr : power_supply_show_property+0xc0/0x328 ... [151.545542][ T70] Call trace: [151.545544][ T70]ucsi_psy_get_prop+0x208/0x20c [151.545546][ T70]power_supply_uevent+0x1a4/0x2f0 [151.545550][ T70]dev_uevent+0x200/0x384 [151.545555][ T70]kobject_uevent_env+0x1d4/0x7e8 [151.545557][ T70]power_supply_changed_work+0x174/0x31c [151.545562][ T70]process_one_work+0x244/0x6f0 [151.545564][ T70]worker_thread+0x3e0/0xa64 We can resolve this by instead retrieving and storing up to the maximum of 7 PDOs in the con->src_pdos array. This would involve two calls to the GET_PDOS command. Solution(s) debian-upgrade-linux References https://attackerkb.com/topics/cve-2021-46980 CVE - 2021-46980

Debian: CVE-2021-46984: linux -- security update Severity 7 CVSS (AV:L/AC:L/Au:S/C:C/I:C/A:C) Published 02/28/2024 Created 07/31/2024 Added 07/30/2024 Modified 01/30/2025 Description In the Linux kernel, the following vulnerability has been resolved: kyber: fix out of bounds access when preempted __blk_mq_sched_bio_merge() gets the ctx and hctx for the current CPU and passes the hctx to ->bio_merge(). kyber_bio_merge() then gets the ctx for the current CPU again and uses that to get the corresponding Kyber context in the passed hctx. However, the thread may be preempted between the two calls to blk_mq_get_ctx(), and the ctx returned the second time may no longer correspond to the passed hctx. This "works" accidentally most of the time, but it can cause us to read garbage if the second ctx came from an hctx with more ctx's than the first one (i.e., if ctx->index_hw[hctx->type] > hctx->nr_ctx). This manifested as this UBSAN array index out of bounds error reported by Jakub: UBSAN: array-index-out-of-bounds in ../kernel/locking/qspinlock.c:130:9 index 13106 is out of range for type 'long unsigned int [128]' Call Trace: dump_stack+0xa4/0xe5 ubsan_epilogue+0x5/0x40 __ubsan_handle_out_of_bounds.cold.13+0x2a/0x34 queued_spin_lock_slowpath+0x476/0x480 do_raw_spin_lock+0x1c2/0x1d0 kyber_bio_merge+0x112/0x180 blk_mq_submit_bio+0x1f5/0x1100 submit_bio_noacct+0x7b0/0x870 submit_bio+0xc2/0x3a0 btrfs_map_bio+0x4f0/0x9d0 btrfs_submit_data_bio+0x24e/0x310 submit_one_bio+0x7f/0xb0 submit_extent_page+0xc4/0x440 __extent_writepage_io+0x2b8/0x5e0 __extent_writepage+0x28d/0x6e0 extent_write_cache_pages+0x4d7/0x7a0 extent_writepages+0xa2/0x110 do_writepages+0x8f/0x180 __writeback_single_inode+0x99/0x7f0 writeback_sb_inodes+0x34e/0x790 __writeback_inodes_wb+0x9e/0x120 wb_writeback+0x4d2/0x660 wb_workfn+0x64d/0xa10 process_one_work+0x53a/0xa80 worker_thread+0x69/0x5b0 kthread+0x20b/0x240 ret_from_fork+0x1f/0x30 Only Kyber uses the hctx, so fix it by passing the request_queue to ->bio_merge() instead. BFQ and mq-deadline just use that, and Kyber can map the queues itself to avoid the mismatch. Solution(s) debian-upgrade-linux References https://attackerkb.com/topics/cve-2021-46984 CVE - 2021-46984

Amazon Linux AMI 2: CVE-2021-46997: Security patch for kernel (ALASKERNEL-5.10-2022-002) Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 02/28/2024 Created 05/28/2024 Added 05/28/2024 Modified 01/30/2025 Description In the Linux kernel, the following vulnerability has been resolved: arm64: entry: always set GIC_PRIO_PSR_I_SET during entry Zenghui reports that booting a kernel with "irqchip.gicv3_pseudo_nmi=1" on the command line hits a warning during kernel entry, due to the way we manipulate the PMR. Early in the entry sequence, we call lockdep_hardirqs_off() to inform lockdep that interrupts have been masked (as the HW sets DAIF wqhen entering an exception). Architecturally PMR_EL1 is not affected by exception entry, and we don't set GIC_PRIO_PSR_I_SET in the PMR early in the exception entry sequence, so early in exception entry the PMR can indicate that interrupts are unmasked even though they are masked by DAIF. If DEBUG_LOCKDEP is selected, lockdep_hardirqs_off() will check that interrupts are masked, before we set GIC_PRIO_PSR_I_SET in any of the exception entry paths, and hence lockdep_hardirqs_off() will WARN() that something is amiss. We can avoid this by consistently setting GIC_PRIO_PSR_I_SET during exception entry so that kernel code sees a consistent environment. We must also update local_daif_inherit() to undo this, as currently only touches DAIF. For other paths, local_daif_restore() will update both DAIF and the PMR. With this done, we can remove the existing special cases which set this later in the entry code. We always use (GIC_PRIO_IRQON | GIC_PRIO_PSR_I_SET) for consistency with local_daif_save(), as this will warn if it ever encounters (GIC_PRIO_IRQOFF | GIC_PRIO_PSR_I_SET), and never sets this itself. This matches the gic_prio_kentry_setup that we have to retain for ret_to_user. The original splat from Zenghui's report was: | DEBUG_LOCKS_WARN_ON(!irqs_disabled()) | WARNING: CPU: 3 PID: 125 at kernel/locking/lockdep.c:4258 lockdep_hardirqs_off+0xd4/0xe8 | Modules linked in: | CPU: 3 PID: 125 Comm: modprobe Tainted: GW 5.12.0-rc8+ #463 | Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015 | pstate: 604003c5 (nZCv DAIF +PAN -UAO -TCO BTYPE=--) | pc : lockdep_hardirqs_off+0xd4/0xe8 | lr : lockdep_hardirqs_off+0xd4/0xe8 | sp : ffff80002a39bad0 | pmr_save: 000000e0 | x29: ffff80002a39bad0 x28: ffff0000de214bc0 | x27: ffff0000de1c0400 x26: 000000000049b328 | x25: 0000000000406f30 x24: ffff0000de1c00a0 | x23: 0000000020400005 x22: ffff8000105f747c | x21: 0000000096000044 x20: 0000000000498ef9 | x19: ffff80002a39bc88 x18: ffffffffffffffff | x17: 0000000000000000 x16: ffff800011c61eb0 | x15: ffff800011700a88 x14: 0720072007200720 | x13: 0720072007200720 x12: 0720072007200720 | x11: 0720072007200720 x10: 0720072007200720 | x9 : ffff80002a39bad0 x8 : ffff80002a39bad0 | x7 : ffff8000119f0800 x6 : c0000000ffff7fff | x5 : ffff8000119f07a8 x4 : 0000000000000001 | x3 : 9bcdab23f2432800 x2 : ffff800011730538 | x1 : 9bcdab23f2432800 x0 : 0000000000000000 | Call trace: |lockdep_hardirqs_off+0xd4/0xe8 |enter_from_kernel_mode.isra.5+0x7c/0xa8 |el1_abort+0x24/0x100 |el1_sync_handler+0x80/0xd0 |el1_sync+0x6c/0x100 |__arch_clear_user+0xc/0x90 |load_elf_binary+0x9fc/0x1450 |bprm_execve+0x404/0x880 |kernel_execve+0x180/0x188 |call_usermodehelper_exec_async+0xdc/0x158 |ret_from_fork+0x10/0x18 Solution(s) amazon-linux-ami-2-upgrade-bpftool amazon-linux-ami-2-upgrade-bpftool-debuginfo amazon-linux-ami-2-upgrade-kernel amazon-linux-ami-2-upgrade-kernel-debuginfo amazon-linux-ami-2-upgrade-kernel-debuginfo-common-aarch64 amazon-linux-ami-2-upgrade-kernel-debuginfo-common-x86_64 amazon-linux-ami-2-upgrade-kernel-devel amazon-linux-ami-2-upgrade-kernel-headers amazon-linux-ami-2-upgrade-kernel-tools amazon-linux-ami-2-upgrade-kernel-tools-debuginfo amazon-linux-ami-2-upgrade-kernel-tools-devel amazon-linux-ami-2-upgrade-perf amazon-linux-ami-2-upgrade-perf-debuginfo amazon-linux-ami-2-upgrade-python-perf amazon-linux-ami-2-upgrade-python-perf-debuginfo References https://attackerkb.com/topics/cve-2021-46997 AL2/ALASKERNEL-5.10-2022-002 CVE - 2021-46997

Amazon Linux AMI 2: CVE-2021-46991: Security patch for kernel (Multiple Advisories) Severity 7 CVSS (AV:L/AC:L/Au:S/C:C/I:C/A:C) Published 02/28/2024 Created 12/13/2024 Added 12/12/2024 Modified 01/30/2025 Description In the Linux kernel, the following vulnerability has been resolved: i40e: Fix use-after-free in i40e_client_subtask() Currently the call to i40e_client_del_instance frees the object pf->cinst, however pf->cinst->lan_info is being accessed after the free. Fix this by adding the missing return. Addresses-Coverity: ("Read from pointer after free") Solution(s) amazon-linux-ami-2-upgrade-bpftool amazon-linux-ami-2-upgrade-bpftool-debuginfo amazon-linux-ami-2-upgrade-kernel amazon-linux-ami-2-upgrade-kernel-debuginfo amazon-linux-ami-2-upgrade-kernel-debuginfo-common-aarch64 amazon-linux-ami-2-upgrade-kernel-debuginfo-common-x86_64 amazon-linux-ami-2-upgrade-kernel-devel amazon-linux-ami-2-upgrade-kernel-headers amazon-linux-ami-2-upgrade-kernel-tools amazon-linux-ami-2-upgrade-kernel-tools-debuginfo amazon-linux-ami-2-upgrade-kernel-tools-devel amazon-linux-ami-2-upgrade-perf amazon-linux-ami-2-upgrade-perf-debuginfo amazon-linux-ami-2-upgrade-python-perf amazon-linux-ami-2-upgrade-python-perf-debuginfo References https://attackerkb.com/topics/cve-2021-46991 AL2/ALASKERNEL-5.10-2022-002 AL2/ALASKERNEL-5.4-2022-004 CVE - 2021-46991

Cisco NX-OS: CVE-2024-20291: Cisco Nexus 3000 and 9000 Series Switches Port Channel ACL Programming Vulnerability Severity 5 CVSS (AV:N/AC:L/Au:N/C:N/I:P/A:N) Published 02/28/2024 Created 03/01/2024 Added 02/29/2024 Modified 07/16/2024 Description A vulnerability in the access control list (ACL) programming for port channel subinterfaces of Cisco Nexus 3000 and 9000 Series Switches in standalone NX-OS mode could allow an unauthenticated, remote attacker to send traffic that should be blocked through an affected device. This vulnerability is due to incorrect hardware programming that occurs when configuration changes are made to port channel member ports. An attacker could exploit this vulnerability by attempting to send traffic through an affected device. A successful exploit could allow the attacker to access network resources that should be protected by an ACL that was applied on port channel subinterfaces. Solution(s) cisco-nx-update-latest References https://attackerkb.com/topics/cve-2024-20291 CVE - 2024-20291 https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-nxos-po-acl-TkyePgvL cisco-sa-nxos-po-acl-TkyePgvL

Huawei EulerOS: CVE-2021-47049: kernel security update Severity 7 CVSS (AV:L/AC:L/Au:S/C:C/I:C/A:C) Published 02/28/2024 Created 11/12/2024 Added 11/11/2024 Modified 01/30/2025 Description In the Linux kernel, the following vulnerability has been resolved: Drivers: hv: vmbus: Use after free in __vmbus_open() The "open_info" variable is added to the &vmbus_connection.chn_msg_list, but the error handling frees "open_info" without removing it from the list.This will result in a use after free.First remove it from the list, and then free it. Solution(s) huawei-euleros-2_0_sp9-upgrade-kernel huawei-euleros-2_0_sp9-upgrade-kernel-tools huawei-euleros-2_0_sp9-upgrade-kernel-tools-libs huawei-euleros-2_0_sp9-upgrade-python3-perf References https://attackerkb.com/topics/cve-2021-47049 CVE - 2021-47049 EulerOS-SA-2024-2832

Huawei EulerOS: CVE-2024-21885: xorg-x11-server security update Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 02/28/2024 Created 03/14/2024 Added 03/13/2024 Modified 03/13/2024 Description A flaw was found in X.Org server. In the XISendDeviceHierarchyEvent function, it is possible to exceed the allocated array length when certain new device IDs are added to the xXIHierarchyInfo struct. This can trigger a heap buffer overflow condition, which may lead to an application crash or remote code execution in SSH X11 forwarding environments. Solution(s) huawei-euleros-2_0_sp10-upgrade-xorg-x11-server-help References https://attackerkb.com/topics/cve-2024-21885 CVE - 2024-21885 EulerOS-SA-2024-1352

Huawei EulerOS: CVE-2021-47024: kernel security update Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 02/28/2024 Created 07/17/2024 Added 07/17/2024 Modified 01/30/2025 Description In the Linux kernel, the following vulnerability has been resolved: vsock/virtio: free queued packets when closing socket As reported by syzbot [1], there is a memory leak while closing the socket. We partially solved this issue with commit ac03046ece2b ("vsock/virtio: free packets during the socket release"), but we forgot to drain the RX queue when the socket is definitely closed by the scheduled work. To avoid future issues, let's use the new virtio_transport_remove_sock() to drain the RX queue before removing the socket from the af_vsock lists calling vsock_remove_sock(). [1] https://syzkaller.appspot.com/bug?extid=24452624fc4c571eedd9 Solution(s) huawei-euleros-2_0_sp9-upgrade-kernel huawei-euleros-2_0_sp9-upgrade-kernel-tools huawei-euleros-2_0_sp9-upgrade-kernel-tools-libs huawei-euleros-2_0_sp9-upgrade-python3-perf References https://attackerkb.com/topics/cve-2021-47024 CVE - 2021-47024 EulerOS-SA-2024-1964

Huawei EulerOS: CVE-2021-47041: kernel security update Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 02/28/2024 Created 07/17/2024 Added 07/17/2024 Modified 01/28/2025 Description In the Linux kernel, the following vulnerability has been resolved: nvmet-tcp: fix incorrect locking in state_change sk callback We are not changing anything in the TCP connection state so we should not take a write_lock but rather a read lock. This caused a deadlock when running nvmet-tcp and nvme-tcp on the same system, where state_change callbacks on the host and on the controller side have causal relationship and made lockdep report on this with blktests: ================================ WARNING: inconsistent lock state 5.12.0-rc3 #1 Tainted: GI -------------------------------- inconsistent {IN-SOFTIRQ-W} -> {SOFTIRQ-ON-R} usage. nvme/1324 [HC0[0]:SC0[0]:HE1:SE1] takes: ffff888363151000 (clock-AF_INET){++-?}-{2:2}, at: nvme_tcp_state_change+0x21/0x150 [nvme_tcp] {IN-SOFTIRQ-W} state was registered at: __lock_acquire+0x79b/0x18d0 lock_acquire+0x1ca/0x480 _raw_write_lock_bh+0x39/0x80 nvmet_tcp_state_change+0x21/0x170 [nvmet_tcp] tcp_fin+0x2a8/0x780 tcp_data_queue+0xf94/0x1f20 tcp_rcv_established+0x6ba/0x1f00 tcp_v4_do_rcv+0x502/0x760 tcp_v4_rcv+0x257e/0x3430 ip_protocol_deliver_rcu+0x69/0x6a0 ip_local_deliver_finish+0x1e2/0x2f0 ip_local_deliver+0x1a2/0x420 ip_rcv+0x4fb/0x6b0 __netif_receive_skb_one_core+0x162/0x1b0 process_backlog+0x1ff/0x770 __napi_poll.constprop.0+0xa9/0x5c0 net_rx_action+0x7b3/0xb30 __do_softirq+0x1f0/0x940 do_softirq+0xa1/0xd0 __local_bh_enable_ip+0xd8/0x100 ip_finish_output2+0x6b7/0x18a0 __ip_queue_xmit+0x706/0x1aa0 __tcp_transmit_skb+0x2068/0x2e20 tcp_write_xmit+0xc9e/0x2bb0 __tcp_push_pending_frames+0x92/0x310 inet_shutdown+0x158/0x300 __nvme_tcp_stop_queue+0x36/0x270 [nvme_tcp] nvme_tcp_stop_queue+0x87/0xb0 [nvme_tcp] nvme_tcp_teardown_admin_queue+0x69/0xe0 [nvme_tcp] nvme_do_delete_ctrl+0x100/0x10c [nvme_core] nvme_sysfs_delete.cold+0x8/0xd [nvme_core] kernfs_fop_write_iter+0x2c7/0x460 new_sync_write+0x36c/0x610 vfs_write+0x5c0/0x870 ksys_write+0xf9/0x1d0 do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x44/0xae irq event stamp: 10687 hardirqs lastenabled at (10687): [<ffffffff9ec376bd>] _raw_spin_unlock_irqrestore+0x2d/0x40 hardirqs last disabled at (10686): [<ffffffff9ec374d8>] _raw_spin_lock_irqsave+0x68/0x90 softirqs lastenabled at (10684): [<ffffffff9f000608>] __do_softirq+0x608/0x940 softirqs last disabled at (10649): [<ffffffff9cdedd31>] do_softirq+0xa1/0xd0 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(clock-AF_INET); <Interrupt> lock(clock-AF_INET); *** DEADLOCK *** 5 locks held by nvme/1324: #0: ffff8884a01fe470 (sb_writers#4){.+.+}-{0:0}, at: ksys_write+0xf9/0x1d0 #1: ffff8886e435c090 (&of->mutex){+.+.}-{3:3}, at: kernfs_fop_write_iter+0x216/0x460 #2: ffff888104d90c38 (kn->active#255){++++}-{0:0}, at: kernfs_remove_self+0x22d/0x330 #3: ffff8884634538d0 (&queue->queue_lock){+.+.}-{3:3}, at: nvme_tcp_stop_queue+0x52/0xb0 [nvme_tcp] #4: ffff888363150d30 (sk_lock-AF_INET){+.+.}-{0:0}, at: inet_shutdown+0x59/0x300 stack backtrace: CPU: 26 PID: 1324 Comm: nvme Tainted: GI 5.12.0-rc3 #1 Hardware name: Dell Inc. PowerEdge R640/06NR82, BIOS 2.10.0 11/12/2020 Call Trace: dump_stack+0x93/0xc2 mark_lock_irq.cold+0x2c/0xb3 ? verify_lock_unused+0x390/0x390 ? stack_trace_consume_entry+0x160/0x160 ? lock_downgrade+0x100/0x100 ? save_trace+0x88/0x5e0 ? _raw_spin_unlock_irqrestore+0x2d/0x40 mark_lock+0x530/0x1470 ? mark_lock_irq+0x1d10/0x1d10 ? enqueue_timer+0x660/0x660 mark_usage+0x215/0x2a0 __lock_acquire+0x79b/0x18d0 ? tcp_schedule_loss_probe.part.0+0x38c/0x520 lock_acquire+0x1ca/0x480 ? nvme_tcp_state_change+0x21/0x150 [nvme_tcp] ? rcu_read_unlock+0x40/0x40 ? tcp_mtu_probe+0x1ae0/0x1ae0 ? kmalloc_reserve+0xa0/0xa0 ? sysfs_file_ops+0x170/0x170 _raw_read_lock+0x3d/0xa0 ? nvme_tcp_state_change+0x21/0x150 [nvme_tcp] nvme_tcp_state_change+0x21/0x150 [nvme_tcp] ? sysfs_file_ops ---truncated--- Solution(s) huawei-euleros-2_0_sp9-upgrade-kernel huawei-euleros-2_0_sp9-upgrade-kernel-tools huawei-euleros-2_0_sp9-upgrade-kernel-tools-libs huawei-euleros-2_0_sp9-upgrade-python3-perf References https://attackerkb.com/topics/cve-2021-47041 CVE - 2021-47041 EulerOS-SA-2024-1964

Huawei EulerOS: CVE-2024-21886: xorg-x11-server security update Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 02/28/2024 Created 03/14/2024 Added 03/13/2024 Modified 03/13/2024 Description A heap buffer overflow flaw was found in the DisableDevice function in the X.Org server. This issue may lead to an application crash or, in some circumstances, remote code execution in SSH X11 forwarding environments. Solution(s) huawei-euleros-2_0_sp10-upgrade-xorg-x11-server-help References https://attackerkb.com/topics/cve-2024-21886 CVE - 2024-21886 EulerOS-SA-2024-1352

Debian: CVE-2020-36787: linux -- security update Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 02/28/2024 Created 07/31/2024 Added 07/30/2024 Modified 01/30/2025 Description In the Linux kernel, the following vulnerability has been resolved: media: aspeed: fix clock handling logic Video engine uses eclk and vclk for its clock sources and its reset control is coupled with eclk so the current clock enabling sequence works like below. Enable eclk De-assert Video Engine reset 10ms delay Enable vclk It introduces improper reset on the Video Engine hardware and eventually the hardware generates unexpected DMA memory transfers that can corrupt memory region in random and sporadic patterns. This issue is observed very rarely on some specific AST2500 SoCs but it causes a critical kernel panic with making a various shape of signature so it's extremely hard to debug. Moreover, the issue is observed even when the video engine is not actively used because udevd turns on the video engine hardware for a short time to make a query in every boot. To fix this issue, this commit changes the clock handling logic to make the reset de-assertion triggered after enabling both eclk and vclk. Also, it adds clk_unprepare call for a case when probe fails. clk: ast2600: fix reset settings for eclk and vclk Video engine reset setting should be coupled with eclk to match it with the setting for previous Aspeed SoCs which is defined in clk-aspeed.c since all Aspeed SoCs are sharing a single video engine driver. Also, reset bit 6 is defined as 'Video Engine' reset in datasheet so it should be de-asserted when eclk is enabled. This commit fixes the setting. Solution(s) debian-upgrade-linux References https://attackerkb.com/topics/cve-2020-36787 CVE - 2020-36787

Debian: CVE-2020-36781: linux -- security update Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 02/28/2024 Created 07/31/2024 Added 07/30/2024 Modified 01/28/2025 Description In the Linux kernel, the following vulnerability has been resolved: i2c: imx: fix reference leak when pm_runtime_get_sync fails In i2c_imx_xfer() and i2c_imx_remove(), the pm reference count is not expected to be incremented on return. However, pm_runtime_get_sync will increment pm reference count even failed. Forgetting to putting operation will result in a reference leak here. Replace it with pm_runtime_resume_and_get to keep usage counter balanced. Solution(s) debian-upgrade-linux References https://attackerkb.com/topics/cve-2020-36781 CVE - 2020-36781

SUSE: CVE-2021-47047: SUSE Linux Security Advisory Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 02/28/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: spi-zynqmp-gqspi: return -ENOMEM if dma_map_single fails The spi controller supports 44-bit address space on AXI in DMA mode, so set dma_addr_t width to 44-bit to avoid using a swiotlb mapping. In addition, if dma_map_single fails, it should return immediately instead of continuing doing the DMA operation which bases on invalid address. This fixes the following crash which occurs in reading a big block from flash: [123.633577] zynqmp-qspi ff0f0000.spi: swiotlb buffer is full (sz: 4194304 bytes), total 32768 (slots), used 0 (slots) [123.644230] zynqmp-qspi ff0f0000.spi: ERR:rxdma:memory not mapped [123.784625] Unable to handle kernel paging request at virtual address 00000000003fffc0 [123.792536] Mem abort info: [123.795313] ESR = 0x96000145 [123.798351] EC = 0x25: DABT (current EL), IL = 32 bits [123.803655] SET = 0, FnV = 0 [123.806693] EA = 0, S1PTW = 0 [123.809818] Data abort info: [123.812683] ISV = 0, ISS = 0x00000145 [123.816503] CM = 1, WnR = 1 [123.819455] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000805047000 [123.825887] [00000000003fffc0] pgd=0000000803b45003, p4d=0000000803b45003, pud=0000000000000000 [123.834586] Internal error: Oops: 96000145 [#1] PREEMPT SMP Solution(s) suse-upgrade-cluster-md-kmp-64kb suse-upgrade-cluster-md-kmp-azure suse-upgrade-cluster-md-kmp-default suse-upgrade-cluster-md-kmp-rt suse-upgrade-dlm-kmp-64kb suse-upgrade-dlm-kmp-azure suse-upgrade-dlm-kmp-default suse-upgrade-dlm-kmp-rt suse-upgrade-dtb-allwinner suse-upgrade-dtb-altera suse-upgrade-dtb-amazon suse-upgrade-dtb-amd suse-upgrade-dtb-amlogic suse-upgrade-dtb-apm suse-upgrade-dtb-apple suse-upgrade-dtb-arm suse-upgrade-dtb-broadcom suse-upgrade-dtb-cavium suse-upgrade-dtb-exynos suse-upgrade-dtb-freescale suse-upgrade-dtb-hisilicon suse-upgrade-dtb-lg suse-upgrade-dtb-marvell suse-upgrade-dtb-mediatek suse-upgrade-dtb-nvidia suse-upgrade-dtb-qcom suse-upgrade-dtb-renesas suse-upgrade-dtb-rockchip suse-upgrade-dtb-socionext suse-upgrade-dtb-sprd suse-upgrade-dtb-xilinx suse-upgrade-gfs2-kmp-64kb suse-upgrade-gfs2-kmp-azure suse-upgrade-gfs2-kmp-default suse-upgrade-gfs2-kmp-rt suse-upgrade-kernel-64kb suse-upgrade-kernel-64kb-devel suse-upgrade-kernel-64kb-extra suse-upgrade-kernel-64kb-livepatch-devel suse-upgrade-kernel-64kb-optional 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-debug suse-upgrade-kernel-debug-devel suse-upgrade-kernel-debug-livepatch-devel suse-upgrade-kernel-debug-vdso suse-upgrade-kernel-default suse-upgrade-kernel-default-base suse-upgrade-kernel-default-base-rebuild suse-upgrade-kernel-default-devel suse-upgrade-kernel-default-extra suse-upgrade-kernel-default-livepatch suse-upgrade-kernel-default-livepatch-devel suse-upgrade-kernel-default-optional suse-upgrade-kernel-default-vdso suse-upgrade-kernel-devel suse-upgrade-kernel-devel-azure suse-upgrade-kernel-devel-rt suse-upgrade-kernel-docs suse-upgrade-kernel-docs-html suse-upgrade-kernel-kvmsmall suse-upgrade-kernel-kvmsmall-devel suse-upgrade-kernel-kvmsmall-livepatch-devel suse-upgrade-kernel-kvmsmall-vdso suse-upgrade-kernel-macros suse-upgrade-kernel-obs-build suse-upgrade-kernel-obs-qa 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-source-vanilla suse-upgrade-kernel-syms suse-upgrade-kernel-syms-azure suse-upgrade-kernel-syms-rt suse-upgrade-kernel-zfcpdump suse-upgrade-kselftests-kmp-64kb suse-upgrade-kselftests-kmp-azure suse-upgrade-kselftests-kmp-default suse-upgrade-kselftests-kmp-rt suse-upgrade-ocfs2-kmp-64kb suse-upgrade-ocfs2-kmp-azure suse-upgrade-ocfs2-kmp-default suse-upgrade-ocfs2-kmp-rt suse-upgrade-reiserfs-kmp-64kb suse-upgrade-reiserfs-kmp-azure suse-upgrade-reiserfs-kmp-default suse-upgrade-reiserfs-kmp-rt References https://attackerkb.com/topics/cve-2021-47047 CVE - 2021-47047

SUSE: CVE-2021-46991: SUSE Linux Security Advisory Severity 7 CVSS (AV:L/AC:L/Au:S/C:C/I:C/A:C) Published 02/28/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 use-after-free in i40e_client_subtask() Currently the call to i40e_client_del_instance frees the object pf->cinst, however pf->cinst->lan_info is being accessed after the free. Fix this by adding the missing return. Addresses-Coverity: ("Read from pointer after free") Solution(s) 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-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-docs suse-upgrade-kernel-macros suse-upgrade-kernel-obs-build suse-upgrade-kernel-preempt suse-upgrade-kernel-preempt-devel suse-upgrade-kernel-source suse-upgrade-kernel-source-azure suse-upgrade-kernel-syms suse-upgrade-kernel-syms-azure suse-upgrade-kernel-zfcpdump suse-upgrade-reiserfs-kmp-default References https://attackerkb.com/topics/cve-2021-46991 CVE - 2021-46991

SUSE: CVE-2021-47026: SUSE Linux Security Advisory Severity 7 CVSS (AV:L/AC:L/Au:S/C:C/I:C/A:C) Published 02/28/2024 Created 08/16/2024 Added 08/09/2024 Modified 01/28/2025 Description In the Linux kernel, the following vulnerability has been resolved: RDMA/rtrs-clt: destroy sysfs after removing session from active list A session can be removed dynamically by sysfs interface "remove_path" that eventually calls rtrs_clt_remove_path_from_sysfs function.The current rtrs_clt_remove_path_from_sysfs first removes the sysfs interfaces and frees sess->stats object. Second it removes the session from the active list. Therefore some functions could access non-connected session and access the freed sess->stats object even-if they check the session status before accessing the session. For instance rtrs_clt_request and get_next_path_min_inflight check the session status and try to send IO to the session.The session status could be changed when they are trying to send IO but they could not catch the change and update the statistics information in sess->stats object, and generate use-after-free problem. (see: "RDMA/rtrs-clt: Check state of the rtrs_clt_sess before reading its stats") This patch changes the rtrs_clt_remove_path_from_sysfs to remove the session from the active session list and then destroy the sysfs interfaces. Each function still should check the session status because closing or error recovery paths can change the status. Solution(s) suse-upgrade-kernel-64kb suse-upgrade-kernel-64kb-devel suse-upgrade-kernel-default suse-upgrade-kernel-default-base suse-upgrade-kernel-default-devel suse-upgrade-kernel-devel 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-source suse-upgrade-kernel-syms suse-upgrade-kernel-zfcpdump suse-upgrade-reiserfs-kmp-default References https://attackerkb.com/topics/cve-2021-47026 CVE - 2021-47026

SUSE: CVE-2021-46998: SUSE Linux Security Advisory Severity 7 CVSS (AV:L/AC:L/Au:S/C:C/I:C/A:C) Published 02/28/2024 Created 08/16/2024 Added 08/09/2024 Modified 01/28/2025 Description In the Linux kernel, the following vulnerability has been resolved: ethernet:enic: Fix a use after free bug in enic_hard_start_xmit In enic_hard_start_xmit, it calls enic_queue_wq_skb(). Inside enic_queue_wq_skb, if some error happens, the skb will be freed by dev_kfree_skb(skb). But the freed skb is still used in skb_tx_timestamp(skb). My patch makes enic_queue_wq_skb() return error and goto spin_unlock() incase of error. The solution is provided by Govind. See https://lkml.org/lkml/2021/4/30/961. Solution(s) 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-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-docs suse-upgrade-kernel-macros suse-upgrade-kernel-obs-build suse-upgrade-kernel-preempt suse-upgrade-kernel-preempt-devel suse-upgrade-kernel-source suse-upgrade-kernel-source-azure suse-upgrade-kernel-syms suse-upgrade-kernel-syms-azure suse-upgrade-kernel-zfcpdump suse-upgrade-reiserfs-kmp-default References https://attackerkb.com/topics/cve-2021-46998 CVE - 2021-46998

SUSE: CVE-2021-47015: SUSE Linux Security Advisory Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 02/28/2024 Created 08/16/2024 Added 08/09/2024 Modified 01/28/2025 Description In the Linux kernel, the following vulnerability has been resolved: bnxt_en: Fix RX consumer index logic in the error path. In bnxt_rx_pkt(), the RX buffers are expected to complete in order. If the RX consumer index indicates an out of order buffer completion, it means we are hitting a hardware bug and the driver will abort all remaining RX packets and reset the RX ring.The RX consumer index that we pass to bnxt_discard_rx() is not correct.We should be passing the current index (tmp_raw_cons) instead of the old index (raw_cons).This bug can cause us to be at the wrong index when trying to abort the next RX packet.It can crash like this: #0 [ffff9bbcdf5c39a8] machine_kexec at ffffffff9b05e007 #1 [ffff9bbcdf5c3a00] __crash_kexec at ffffffff9b111232 #2 [ffff9bbcdf5c3ad0] panic at ffffffff9b07d61e #3 [ffff9bbcdf5c3b50] oops_end at ffffffff9b030978 #4 [ffff9bbcdf5c3b78] no_context at ffffffff9b06aaf0 #5 [ffff9bbcdf5c3bd8] __bad_area_nosemaphore at ffffffff9b06ae2e #6 [ffff9bbcdf5c3c28] bad_area_nosemaphore at ffffffff9b06af24 #7 [ffff9bbcdf5c3c38] __do_page_fault at ffffffff9b06b67e #8 [ffff9bbcdf5c3cb0] do_page_fault at ffffffff9b06bb12 #9 [ffff9bbcdf5c3ce0] page_fault at ffffffff9bc015c5 [exception RIP: bnxt_rx_pkt+237] RIP: ffffffffc0259cddRSP: ffff9bbcdf5c3d98RFLAGS: 00010213 RAX: 000000005dd8097fRBX: ffff9ba4cb11b7e0RCX: ffffa923cf6e9000 RDX: 0000000000000fffRSI: 0000000000000627RDI: 0000000000001000 RBP: ffff9bbcdf5c3e60 R8: 0000000000420003 R9: 000000000000020d R10: ffffa923cf6ec138R11: ffff9bbcdf5c3e83R12: ffff9ba4d6f928c0 R13: ffff9ba4cac28080R14: ffff9ba4cb11b7f0R15: ffff9ba4d5a30000 ORIG_RAX: ffffffffffffffffCS: 0010SS: 0018 Solution(s) 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-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-docs suse-upgrade-kernel-macros suse-upgrade-kernel-obs-build suse-upgrade-kernel-preempt suse-upgrade-kernel-preempt-devel suse-upgrade-kernel-source suse-upgrade-kernel-source-azure suse-upgrade-kernel-syms suse-upgrade-kernel-syms-azure suse-upgrade-kernel-zfcpdump suse-upgrade-reiserfs-kmp-default References https://attackerkb.com/topics/cve-2021-47015 CVE - 2021-47015

SUSE: CVE-2021-47000: SUSE Linux Security Advisory Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 02/28/2024 Created 08/16/2024 Added 08/09/2024 Modified 08/09/2024 Description In the Linux kernel, the following vulnerability has been resolved: ceph: fix inode leak on getattr error in __fh_to_dentry Solution(s) suse-upgrade-kernel-64kb suse-upgrade-kernel-64kb-devel suse-upgrade-kernel-default suse-upgrade-kernel-default-base suse-upgrade-kernel-default-devel suse-upgrade-kernel-devel 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-source suse-upgrade-kernel-syms suse-upgrade-kernel-zfcpdump suse-upgrade-reiserfs-kmp-default References https://attackerkb.com/topics/cve-2021-47000 CVE - 2021-47000

Debian: CVE-2021-47040: linux -- security update Severity 7 CVSS (AV:L/AC:L/Au:S/C:C/I:C/A:C) Published 02/28/2024 Created 07/31/2024 Added 07/30/2024 Modified 01/30/2025 Description In the Linux kernel, the following vulnerability has been resolved: io_uring: fix overflows checks in provide buffers Colin reported before possible overflow and sign extension problems in io_provide_buffers_prep(). As Linus pointed out previous attempt did nothing useful, see d81269fecb8ce ("io_uring: fix provide_buffers sign extension"). Do that with help of check_<op>_overflow helpers. And fix struct io_provide_buf::len type, as it doesn't make much sense to keep it signed. Solution(s) debian-upgrade-linux References https://attackerkb.com/topics/cve-2021-47040 CVE - 2021-47040

Debian: CVE-2021-47036: linux -- security update Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 02/28/2024 Created 07/31/2024 Added 07/30/2024 Modified 01/28/2025 Description In the Linux kernel, the following vulnerability has been resolved: udp: skip L4 aggregation for UDP tunnel packets If NETIF_F_GRO_FRAGLIST or NETIF_F_GRO_UDP_FWD are enabled, and there are UDP tunnels available in the system, udp_gro_receive() could end-up doing L4 aggregation (either SKB_GSO_UDP_L4 or SKB_GSO_FRAGLIST) at the outer UDP tunnel level for packets effectively carrying and UDP tunnel header. That could cause inner protocol corruption. If e.g. the relevant packets carry a vxlan header, different vxlan ids will be ignored/ aggregated to the same GSO packet. Inner headers will be ignored, too, so that e.g. TCP over vxlan push packets will be held in the GRO engine till the next flush, etc. Just skip the SKB_GSO_UDP_L4 and SKB_GSO_FRAGLIST code path if the current packet could land in a UDP tunnel, and let udp_gro_receive() do GRO via udp_sk(sk)->gro_receive. The check implemented in this patch is broader than what is strictly needed, as the existing UDP tunnel could be e.g. configured on top of a different device: we could end-up skipping GRO at-all for some packets. Anyhow, that is a very thin corner case and covering it will add quite a bit of complexity. v1 -> v2: - hopefully clarify the commit message Solution(s) debian-upgrade-linux References https://attackerkb.com/topics/cve-2021-47036 CVE - 2021-47036

Debian: CVE-2021-47018: linux -- security update Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 02/28/2024 Created 07/31/2024 Added 07/30/2024 Modified 01/28/2025 Description In the Linux kernel, the following vulnerability has been resolved: powerpc/64: Fix the definition of the fixmap area At the time being, the fixmap area is defined at the top of the address space or just below KASAN. This definition is not valid for PPC64. For PPC64, use the top of the I/O space. Because of circular dependencies, it is not possible to include asm/fixmap.h in asm/book3s/64/pgtable.h , so define a fixed size AREA at the top of the I/O space for fixmap and ensure during build that the size is big enough. Solution(s) debian-upgrade-linux References https://attackerkb.com/topics/cve-2021-47018 CVE - 2021-47018