ISHACK AI BOT

Amazon Linux 2023: CVE-2023-52492: Important priority package update for kernel Severity 4 CVSS (AV:L/AC:L/Au:M/C:N/I:N/A:C) Published 02/29/2024 Created 02/14/2025 Added 02/14/2025 Modified 02/14/2025 Description In the Linux kernel, the following vulnerability has been resolved: dmaengine: fix NULL pointer in channel unregistration function __dma_async_device_channel_register() can fail. In case of failure, chan->local is freed (with free_percpu()), and chan->local is nullified. When dma_async_device_unregister() is called (because of managed API or intentionally by DMA controller driver), channels are unconditionally unregistered, leading to this NULL pointer: [1.318693] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000d0 [...] [1.484499] Call trace: [1.486930]device_del+0x40/0x394 [1.490314]device_unregister+0x20/0x7c [1.494220]__dma_async_device_channel_unregister+0x68/0xc0 Look at dma_async_device_register() function error path, channel device unregistration is done only if chan->local is not NULL. Then add the same condition at the beginning of __dma_async_device_channel_unregister() function, to avoid NULL pointer issue whatever the API used to reach this function. Solution(s) amazon-linux-2023-upgrade-bpftool amazon-linux-2023-upgrade-bpftool-debuginfo amazon-linux-2023-upgrade-kernel amazon-linux-2023-upgrade-kernel-debuginfo amazon-linux-2023-upgrade-kernel-debuginfo-common-aarch64 amazon-linux-2023-upgrade-kernel-debuginfo-common-x86-64 amazon-linux-2023-upgrade-kernel-devel amazon-linux-2023-upgrade-kernel-headers amazon-linux-2023-upgrade-kernel-libbpf amazon-linux-2023-upgrade-kernel-libbpf-devel amazon-linux-2023-upgrade-kernel-libbpf-static amazon-linux-2023-upgrade-kernel-livepatch-6-1-77-99-164 amazon-linux-2023-upgrade-kernel-modules-extra amazon-linux-2023-upgrade-kernel-modules-extra-common amazon-linux-2023-upgrade-kernel-tools amazon-linux-2023-upgrade-kernel-tools-debuginfo amazon-linux-2023-upgrade-kernel-tools-devel amazon-linux-2023-upgrade-perf amazon-linux-2023-upgrade-perf-debuginfo amazon-linux-2023-upgrade-python3-perf amazon-linux-2023-upgrade-python3-perf-debuginfo References https://attackerkb.com/topics/cve-2023-52492 CVE - 2023-52492 https://alas.aws.amazon.com/AL2023/ALAS-2024-517.html

Debian: CVE-2021-47061: linux -- security update Severity 7 CVSS (AV:L/AC:L/Au:S/C:C/I:C/A:C) Published 02/29/2024 Created 07/31/2024 Added 07/30/2024 Modified 01/30/2025 Description In the Linux kernel, the following vulnerability has been resolved: KVM: Destroy I/O bus devices on unregister failure _after_ sync'ing SRCU If allocating a new instance of an I/O bus fails when unregistering a device, wait to destroy the device until after all readers are guaranteed to see the new null bus.Destroying devices before the bus is nullified could lead to use-after-free since readers expect the devices on their reference of the bus to remain valid. Solution(s) debian-upgrade-linux References https://attackerkb.com/topics/cve-2021-47061 CVE - 2021-47061

Debian: CVE-2021-47064: linux -- security update Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 02/29/2024 Created 07/31/2024 Added 07/30/2024 Modified 07/30/2024 Description In the Linux kernel, the following vulnerability has been resolved: mt76: fix potential DMA mapping leak With buf uninitialized in mt76_dma_tx_queue_skb_raw, its field skip_unmap could potentially inherit a non-zero value from stack garbage. If this happens, it will cause DMA mappings for MCU command frames to not be unmapped after completion Solution(s) debian-upgrade-linux References https://attackerkb.com/topics/cve-2021-47064 CVE - 2021-47064

Debian: CVE-2021-47068: linux -- security update Severity 7 CVSS (AV:L/AC:L/Au:S/C:C/I:C/A:C) Published 02/29/2024 Created 07/31/2024 Added 07/30/2024 Modified 01/30/2025 Description In the Linux kernel, the following vulnerability has been resolved: net/nfc: fix use-after-free llcp_sock_bind/connect Commits 8a4cd82d ("nfc: fix refcount leak in llcp_sock_connect()") and c33b1cc62 ("nfc: fix refcount leak in llcp_sock_bind()") fixed a refcount leak bug in bind/connect but introduced a use-after-free if the same local is assigned to 2 different sockets. This can be triggered by the following simple program: int sock1 = socket( AF_NFC, SOCK_STREAM, NFC_SOCKPROTO_LLCP ); int sock2 = socket( AF_NFC, SOCK_STREAM, NFC_SOCKPROTO_LLCP ); memset( &addr, 0, sizeof(struct sockaddr_nfc_llcp) ); addr.sa_family = AF_NFC; addr.nfc_protocol = NFC_PROTO_NFC_DEP; bind( sock1, (struct sockaddr*) &addr, sizeof(struct sockaddr_nfc_llcp) ) bind( sock2, (struct sockaddr*) &addr, sizeof(struct sockaddr_nfc_llcp) ) close(sock1); close(sock2); Fix this by assigning NULL to llcp_sock->local after calling nfc_llcp_local_put. This addresses CVE-2021-23134. Solution(s) debian-upgrade-linux References https://attackerkb.com/topics/cve-2021-47068 CVE - 2021-47068

Oracle Linux: CVE-2023-52477: ELSA-2024-12606: Unbreakable Enterprise kernel security update (IMPORTANT) (Multiple Advisories) Severity 4 CVSS (AV:L/AC:L/Au:M/C:N/I:N/A:C) Published 02/29/2024 Created 06/07/2024 Added 06/06/2024 Modified 01/23/2025 Description In the Linux kernel, the following vulnerability has been resolved: usb: hub: Guard against accesses to uninitialized BOS descriptors Many functions in drivers/usb/core/hub.c and drivers/usb/core/hub.h access fields inside udev->bos without checking if it was allocated and initialized. If usb_get_bos_descriptor() fails for whatever reason, udev->bos will be NULL and those accesses will result in a crash: BUG: kernel NULL pointer dereference, address: 0000000000000018 PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 5 PID: 17818 Comm: kworker/5:1 Tainted: G W 5.15.108-18910-gab0e1cb584e1 #1 <HASH:1f9e 1> Hardware name: Google Kindred/Kindred, BIOS Google_Kindred.12672.413.0 02/03/2021 Workqueue: usb_hub_wq hub_event RIP: 0010:hub_port_reset+0x193/0x788 Code: 89 f7 e8 20 f7 15 00 48 8b 43 08 80 b8 96 03 00 00 03 75 36 0f b7 88 92 03 00 00 81 f9 10 03 00 00 72 27 48 8b 80 a8 03 00 00 <48> 83 78 18 00 74 19 48 89 df 48 8b 75 b0 ba 02 00 00 00 4c 89 e9 RSP: 0018:ffffab740c53fcf8 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffffa1bc5f678000 RCX: 0000000000000310 RDX: fffffffffffffdff RSI: 0000000000000286 RDI: ffffa1be9655b840 RBP: ffffab740c53fd70 R08: 00001b7d5edaa20c R09: ffffffffb005e060 R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000 R13: ffffab740c53fd3e R14: 0000000000000032 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffffa1be96540000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000018 CR3: 000000022e80c005 CR4: 00000000003706e0 Call Trace: hub_event+0x73f/0x156e ? hub_activate+0x5b7/0x68f process_one_work+0x1a2/0x487 worker_thread+0x11a/0x288 kthread+0x13a/0x152 ? process_one_work+0x487/0x487 ? kthread_associate_blkcg+0x70/0x70 ret_from_fork+0x1f/0x30 Fall back to a default behavior if the BOS descriptor isn't accessible and skip all the functionalities that depend on it: LPM support checks, Super Speed capabilitiy checks, U1/U2 states setup. Solution(s) oracle-linux-upgrade-kernel oracle-linux-upgrade-kernel-uek References https://attackerkb.com/topics/cve-2023-52477 CVE - 2023-52477 ELSA-2024-12606 ELSA-2024-3618

Oracle Linux: CVE-2023-52492: ELSA-2024-8856:kernel security update (MODERATE) (Multiple Advisories) Severity 4 CVSS (AV:L/AC:L/Au:M/C:N/I:N/A:C) Published 02/29/2024 Created 11/13/2024 Added 11/11/2024 Modified 01/07/2025 Description In the Linux kernel, the following vulnerability has been resolved: dmaengine: fix NULL pointer in channel unregistration function __dma_async_device_channel_register() can fail. In case of failure, chan->local is freed (with free_percpu()), and chan->local is nullified. When dma_async_device_unregister() is called (because of managed API or intentionally by DMA controller driver), channels are unconditionally unregistered, leading to this NULL pointer: [1.318693] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000d0 [...] [1.484499] Call trace: [1.486930]device_del+0x40/0x394 [1.490314]device_unregister+0x20/0x7c [1.494220]__dma_async_device_channel_unregister+0x68/0xc0 Look at dma_async_device_register() function error path, channel device unregistration is done only if chan->local is not NULL. Then add the same condition at the beginning of __dma_async_device_channel_unregister() function, to avoid NULL pointer issue whatever the API used to reach this function. Solution(s) oracle-linux-upgrade-kernel References https://attackerkb.com/topics/cve-2023-52492 CVE - 2023-52492 ELSA-2024-8856

Oracle Linux: CVE-2023-52489: ELSA-2024-2394:kernel security, bug fix, and enhancement update (IMPORTANT) (Multiple Advisories) Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 02/29/2024 Created 05/21/2024 Added 05/14/2024 Modified 01/07/2025 Description In the Linux kernel, the following vulnerability has been resolved: mm/sparsemem: fix race in accessing memory_section->usage The below race is observed on a PFN which falls into the device memory region with the system memory configuration where PFN's are such that [ZONE_NORMAL ZONE_DEVICE ZONE_NORMAL].Since normal zone start and end pfn contains the device memory PFN's as well, the compaction triggered will try on the device memory PFN's too though they end up in NOP(because pfn_to_online_page() returns NULL for ZONE_DEVICE memory sections).When from other core, the section mappings are being removed for the ZONE_DEVICE region, that the PFN in question belongs to, on which compaction is currently being operated is resulting into the kernel crash with CONFIG_SPASEMEM_VMEMAP enabled.The crash logs can be seen at [1]. compact_zone()memunmap_pages ---------------------------- __pageblock_pfn_to_page ...... (a)pfn_valid(): valid_section()//return true (b)__remove_pages()-> sparse_remove_section()-> section_deactivate(): [Free the array ms->usage and set ms->usage = NULL] pfn_section_valid() [Access ms->usage which is NULL] NOTE: From the above it can be said that the race is reduced to between the pfn_valid()/pfn_section_valid() and the section deactivate with SPASEMEM_VMEMAP enabled. The commit b943f045a9af("mm/sparse: fix kernel crash with pfn_section_valid check") tried to address the same problem by clearing the SECTION_HAS_MEM_MAP with the expectation of valid_section() returns false thus ms->usage is not accessed. Fix this issue by the below steps: a) Clear SECTION_HAS_MEM_MAP before freeing the ->usage. b) RCU protected read side critical section will either return NULL when SECTION_HAS_MEM_MAP is cleared or can successfully access ->usage. c) Free the ->usage with kfree_rcu() and set ms->usage = NULL.No attempt will be made to access ->usage after this as the SECTION_HAS_MEM_MAP is cleared thus valid_section() return false. Thanks to David/Pavan for their inputs on this patch. [1] https://lore.kernel.org/linux-mm/[email protected]/ On Snapdragon SoC, with the mentioned memory configuration of PFN's as [ZONE_NORMAL ZONE_DEVICE ZONE_NORMAL], we are able to see bunch of issues daily while testing on a device farm. For this particular issue below is the log.Though the below log is not directly pointing to the pfn_section_valid(){ ms->usage;}, when we loaded this dump on T32 lauterbach tool, it is pointing. [540.578056] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 [540.578068] Mem abort info: [540.578070] ESR = 0x0000000096000005 [540.578073] EC = 0x25: DABT (current EL), IL = 32 bits [540.578077] SET = 0, FnV = 0 [540.578080] EA = 0, S1PTW = 0 [540.578082] FSC = 0x05: level 1 translation fault [540.578085] Data abort info: [540.578086] ISV = 0, ISS = 0x00000005 [540.578088] CM = 0, WnR = 0 [540.579431] pstate: 82400005 (Nzcv daif +PAN -UAO +TCO -DIT -SSBSBTYPE=--) [540.579436] pc : __pageblock_pfn_to_page+0x6c/0x14c [540.579454] lr : compact_zone+0x994/0x1058 [540.579460] sp : ffffffc03579b510 [540.579463] x29: ffffffc03579b510 x28: 0000000000235800 x27:000000000000000c [540.579470] x26: 0000000000235c00 x25: 0000000000000068 x24:ffffffc03579b640 [540.579477] x23: 0000000000000001 x22: ffffffc03579b660 x21:0000000000000000 [540.579483] x20: 0000000000235bff x19: ffffffdebf7e3940 x18:ffffffdebf66d140 [540.579489] x17: 00000000739ba063 x16: 00000000739ba063 x15:00000000009f4bff [540.579495] x14: 0000008000000000 x13: 0000000000000000 x12:0000000000000001 [540.579501] x11: 0000000000000000 x10: 0000000000000000 x9 :ffffff897d2cd440 [540.579507] x8 : 0000000000000000 x7 : 0000000000000000 x6 :ffffffc03579b5b4 [540.579512] x5 : 0000000000027f25 x4 : ffffffc03579b5b8 x3 :0000000000000 ---truncated--- A race condition was found on a PFN in the Linux Kernel, which can fall into the device memory region with the system memory configuration. Normal zone start and end PFNs contain the device memory PFNs as well, and the compaction triggered will try on the device memory PFNs and end up in NOP. This may lead to compromised Availability. Solution(s) oracle-linux-upgrade-kernel References https://attackerkb.com/topics/cve-2023-52489 CVE - 2023-52489 ELSA-2024-2394 ELSA-2024-3138

Huawei EulerOS: CVE-2023-52484: kernel security update Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 02/29/2024 Created 07/02/2024 Added 07/01/2024 Modified 01/30/2025 Description In the Linux kernel, the following vulnerability has been resolved: iommu/arm-smmu-v3: Fix soft lockup triggered by arm_smmu_mm_invalidate_range When running an SVA case, the following soft lockup is triggered: -------------------------------------------------------------------- watchdog: BUG: soft lockup - CPU#244 stuck for 26s! pstate: 83400009 (Nzcv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--) pc : arm_smmu_cmdq_issue_cmdlist+0x178/0xa50 lr : arm_smmu_cmdq_issue_cmdlist+0x150/0xa50 sp : ffff8000d83ef290 x29: ffff8000d83ef290 x28: 000000003b9aca00 x27: 0000000000000000 x26: ffff8000d83ef3c0 x25: da86c0812194a0e8 x24: 0000000000000000 x23: 0000000000000040 x22: ffff8000d83ef340 x21: ffff0000c63980c0 x20: 0000000000000001 x19: ffff0000c6398080 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: ffff3000b4a3bbb0 x14: ffff3000b4a30888 x13: ffff3000b4a3cf60 x12: 0000000000000000 x11: 0000000000000000 x10: 0000000000000000 x9 : ffffc08120e4d6bc x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000048cfa x5 : 0000000000000000 x4 : 0000000000000001 x3 : 000000000000000a x2 : 0000000080000000 x1 : 0000000000000000 x0 : 0000000000000001 Call trace: arm_smmu_cmdq_issue_cmdlist+0x178/0xa50 __arm_smmu_tlb_inv_range+0x118/0x254 arm_smmu_tlb_inv_range_asid+0x6c/0x130 arm_smmu_mm_invalidate_range+0xa0/0xa4 __mmu_notifier_invalidate_range_end+0x88/0x120 unmap_vmas+0x194/0x1e0 unmap_region+0xb4/0x144 do_mas_align_munmap+0x290/0x490 do_mas_munmap+0xbc/0x124 __vm_munmap+0xa8/0x19c __arm64_sys_munmap+0x28/0x50 invoke_syscall+0x78/0x11c el0_svc_common.constprop.0+0x58/0x1c0 do_el0_svc+0x34/0x60 el0_svc+0x2c/0xd4 el0t_64_sync_handler+0x114/0x140 el0t_64_sync+0x1a4/0x1a8 -------------------------------------------------------------------- Note that since 6.6-rc1 the arm_smmu_mm_invalidate_range above is renamed to "arm_smmu_mm_arch_invalidate_secondary_tlbs", yet the problem remains. The commit 06ff87bae8d3 ("arm64: mm: remove unused functions and variable protoypes") fixed a similar lockup on the CPU MMU side. Yet, it can occur to SMMU too, since arm_smmu_mm_arch_invalidate_secondary_tlbs() is called typically next to MMU tlb flush function, e.g. tlb_flush_mmu_tlbonly { tlb_flush { __flush_tlb_range { // check MAX_TLBI_OPS } } mmu_notifier_arch_invalidate_secondary_tlbs { arm_smmu_mm_arch_invalidate_secondary_tlbs { // does not check MAX_TLBI_OPS } } } Clone a CMDQ_MAX_TLBI_OPS from the MAX_TLBI_OPS in tlbflush.h, since in an SVA case SMMU uses the CPU page table, so it makes sense to align with the tlbflush code. Then, replace per-page TLBI commands with a single per-asid TLBI command, if the request size hits this threshold. 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-2023-52484 CVE - 2023-52484 EulerOS-SA-2024-1873

Oracle Linux: CVE-2024-26610: ELSA-2024-3618:kernel update (MODERATE) (Multiple Advisories) Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:P/A:C) Published 02/29/2024 Created 06/07/2024 Added 06/06/2024 Modified 11/29/2024 Description In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: fix a memory corruption iwl_fw_ini_trigger_tlv::data is a pointer to a __le32, which means that if we copy to iwl_fw_ini_trigger_tlv::data + offset while offset is in bytes, we'll write past the buffer. A memory corruption flaw was found in the Linux kernel Intel Wireless WiFi Next Gen AGN module. This issue could allow a local user to crash the system. Solution(s) oracle-linux-upgrade-kernel References https://attackerkb.com/topics/cve-2024-26610 CVE - 2024-26610 ELSA-2024-3618

Amazon Linux AMI 2: CVE-2021-47061: Security patch for kernel (ALASKERNEL-5.10-2022-002) Severity 7 CVSS (AV:L/AC:L/Au:S/C:C/I:C/A:C) Published 02/29/2024 Created 08/03/2024 Added 08/02/2024 Modified 01/30/2025 Description In the Linux kernel, the following vulnerability has been resolved: KVM: Destroy I/O bus devices on unregister failure _after_ sync'ing SRCU If allocating a new instance of an I/O bus fails when unregistering a device, wait to destroy the device until after all readers are guaranteed to see the new null bus.Destroying devices before the bus is nullified could lead to use-after-free since readers expect the devices on their reference of the bus to remain valid. 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-47061 AL2/ALASKERNEL-5.10-2022-002 CVE - 2021-47061

Rocky Linux: CVE-2024-26461: krb5 (RLSA-2024-3268) Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 02/29/2024 Created 06/17/2024 Added 06/17/2024 Modified 11/18/2024 Description Kerberos 5 (aka krb5) 1.21.2 contains a memory leak vulnerability in /krb5/src/lib/gssapi/krb5/k5sealv3.c. Solution(s) rocky-upgrade-krb5-debuginfo rocky-upgrade-krb5-debugsource rocky-upgrade-krb5-devel rocky-upgrade-krb5-devel-debuginfo rocky-upgrade-krb5-libs rocky-upgrade-krb5-libs-debuginfo rocky-upgrade-krb5-pkinit rocky-upgrade-krb5-pkinit-debuginfo rocky-upgrade-krb5-server rocky-upgrade-krb5-server-debuginfo rocky-upgrade-krb5-server-ldap rocky-upgrade-krb5-server-ldap-debuginfo rocky-upgrade-krb5-workstation rocky-upgrade-krb5-workstation-debuginfo rocky-upgrade-libkadm5 rocky-upgrade-libkadm5-debuginfo References https://attackerkb.com/topics/cve-2024-26461 CVE - 2024-26461 https://errata.rockylinux.org/RLSA-2024:3268

Rocky Linux: CVE-2024-25126: pcs (RLSA-2024-2953) Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 02/29/2024 Created 06/17/2024 Added 06/17/2024 Modified 11/18/2024 Description Rack is a modular Ruby web server interface. Carefully crafted content type headers can cause Rack’s media type parser to take much longer than expected, leading to a possible denial of service vulnerability (ReDos 2nd degree polynomial). This vulnerability is patched in 3.0.9.1 and 2.2.8.1. Solution(s) rocky-upgrade-pcs rocky-upgrade-pcs-snmp References https://attackerkb.com/topics/cve-2024-25126 CVE - 2024-25126 https://errata.rockylinux.org/RLSA-2024:2953

Rocky Linux: CVE-2023-52477: kernel-rt (Multiple Advisories) Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 02/29/2024 Created 06/17/2024 Added 06/17/2024 Modified 01/30/2025 Description In the Linux kernel, the following vulnerability has been resolved: usb: hub: Guard against accesses to uninitialized BOS descriptors Many functions in drivers/usb/core/hub.c and drivers/usb/core/hub.h access fields inside udev->bos without checking if it was allocated and initialized. If usb_get_bos_descriptor() fails for whatever reason, udev->bos will be NULL and those accesses will result in a crash: BUG: kernel NULL pointer dereference, address: 0000000000000018 PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 5 PID: 17818 Comm: kworker/5:1 Tainted: G W 5.15.108-18910-gab0e1cb584e1 #1 <HASH:1f9e 1> Hardware name: Google Kindred/Kindred, BIOS Google_Kindred.12672.413.0 02/03/2021 Workqueue: usb_hub_wq hub_event RIP: 0010:hub_port_reset+0x193/0x788 Code: 89 f7 e8 20 f7 15 00 48 8b 43 08 80 b8 96 03 00 00 03 75 36 0f b7 88 92 03 00 00 81 f9 10 03 00 00 72 27 48 8b 80 a8 03 00 00 <48> 83 78 18 00 74 19 48 89 df 48 8b 75 b0 ba 02 00 00 00 4c 89 e9 RSP: 0018:ffffab740c53fcf8 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffffa1bc5f678000 RCX: 0000000000000310 RDX: fffffffffffffdff RSI: 0000000000000286 RDI: ffffa1be9655b840 RBP: ffffab740c53fd70 R08: 00001b7d5edaa20c R09: ffffffffb005e060 R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000 R13: ffffab740c53fd3e R14: 0000000000000032 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffffa1be96540000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000018 CR3: 000000022e80c005 CR4: 00000000003706e0 Call Trace: hub_event+0x73f/0x156e ? hub_activate+0x5b7/0x68f process_one_work+0x1a2/0x487 worker_thread+0x11a/0x288 kthread+0x13a/0x152 ? process_one_work+0x487/0x487 ? kthread_associate_blkcg+0x70/0x70 ret_from_fork+0x1f/0x30 Fall back to a default behavior if the BOS descriptor isn't accessible and skip all the functionalities that depend on it: LPM support checks, Super Speed capabilitiy checks, U1/U2 states setup. Solution(s) rocky-upgrade-bpftool rocky-upgrade-bpftool-debuginfo rocky-upgrade-kernel rocky-upgrade-kernel-core rocky-upgrade-kernel-cross-headers rocky-upgrade-kernel-debug rocky-upgrade-kernel-debug-core rocky-upgrade-kernel-debug-debuginfo rocky-upgrade-kernel-debug-devel rocky-upgrade-kernel-debug-modules rocky-upgrade-kernel-debug-modules-extra rocky-upgrade-kernel-debuginfo rocky-upgrade-kernel-debuginfo-common-x86_64 rocky-upgrade-kernel-devel rocky-upgrade-kernel-headers rocky-upgrade-kernel-modules rocky-upgrade-kernel-modules-extra rocky-upgrade-kernel-rt rocky-upgrade-kernel-rt-core rocky-upgrade-kernel-rt-debug rocky-upgrade-kernel-rt-debug-core rocky-upgrade-kernel-rt-debug-debuginfo rocky-upgrade-kernel-rt-debug-devel rocky-upgrade-kernel-rt-debug-kvm rocky-upgrade-kernel-rt-debug-modules rocky-upgrade-kernel-rt-debug-modules-extra rocky-upgrade-kernel-rt-debuginfo rocky-upgrade-kernel-rt-debuginfo-common-x86_64 rocky-upgrade-kernel-rt-devel rocky-upgrade-kernel-rt-kvm rocky-upgrade-kernel-rt-modules rocky-upgrade-kernel-rt-modules-extra rocky-upgrade-kernel-tools rocky-upgrade-kernel-tools-debuginfo rocky-upgrade-kernel-tools-libs rocky-upgrade-kernel-tools-libs-devel rocky-upgrade-perf rocky-upgrade-perf-debuginfo rocky-upgrade-python3-perf rocky-upgrade-python3-perf-debuginfo References https://attackerkb.com/topics/cve-2023-52477 CVE - 2023-52477 https://errata.rockylinux.org/RLSA-2024:3618 https://errata.rockylinux.org/RLSA-2024:3627

Rocky Linux: CVE-2023-52476: kernel-rt (RLSA-2024-7001) Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 02/29/2024 Created 10/03/2024 Added 10/02/2024 Modified 01/30/2025 Description In the Linux kernel, the following vulnerability has been resolved: perf/x86/lbr: Filter vsyscall addresses We found that a panic can occur when a vsyscall is made while LBR sampling is active. If the vsyscall is interrupted (NMI) for perf sampling, this call sequence can occur (most recent at top): __insn_get_emulate_prefix() insn_get_emulate_prefix() insn_get_prefixes() insn_get_opcode() decode_branch_type() get_branch_type() intel_pmu_lbr_filter() intel_pmu_handle_irq() perf_event_nmi_handler() Within __insn_get_emulate_prefix() at frame 0, a macro is called: peek_nbyte_next(insn_byte_t, insn, i) Within this macro, this dereference occurs: (insn)->next_byte Inspecting registers at this point, the value of the next_byte field is the address of the vsyscall made, for example the location of the vsyscall version of gettimeofday() at 0xffffffffff600000. The access to an address in the vsyscall region will trigger an oops due to an unhandled page fault. To fix the bug, filtering for vsyscalls can be done when determining the branch type. This patch will return a "none" branch if a kernel address if found to lie in the vsyscall region. Solution(s) rocky-upgrade-kernel-rt rocky-upgrade-kernel-rt-core rocky-upgrade-kernel-rt-debug rocky-upgrade-kernel-rt-debug-core rocky-upgrade-kernel-rt-debug-debuginfo rocky-upgrade-kernel-rt-debug-devel rocky-upgrade-kernel-rt-debug-kvm rocky-upgrade-kernel-rt-debug-modules rocky-upgrade-kernel-rt-debug-modules-extra rocky-upgrade-kernel-rt-debuginfo rocky-upgrade-kernel-rt-debuginfo-common-x86_64 rocky-upgrade-kernel-rt-devel rocky-upgrade-kernel-rt-kvm rocky-upgrade-kernel-rt-modules rocky-upgrade-kernel-rt-modules-extra References https://attackerkb.com/topics/cve-2023-52476 CVE - 2023-52476 https://errata.rockylinux.org/RLSA-2024:7001

Rocky Linux: CVE-2024-26458: krb5 (RLSA-2024-3268) Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 02/29/2024 Created 06/17/2024 Added 06/17/2024 Modified 11/18/2024 Description Kerberos 5 (aka krb5) 1.21.2 contains a memory leak in /krb5/src/lib/rpc/pmap_rmt.c. Solution(s) rocky-upgrade-krb5-debuginfo rocky-upgrade-krb5-debugsource rocky-upgrade-krb5-devel rocky-upgrade-krb5-devel-debuginfo rocky-upgrade-krb5-libs rocky-upgrade-krb5-libs-debuginfo rocky-upgrade-krb5-pkinit rocky-upgrade-krb5-pkinit-debuginfo rocky-upgrade-krb5-server rocky-upgrade-krb5-server-debuginfo rocky-upgrade-krb5-server-ldap rocky-upgrade-krb5-server-ldap-debuginfo rocky-upgrade-krb5-workstation rocky-upgrade-krb5-workstation-debuginfo rocky-upgrade-libkadm5 rocky-upgrade-libkadm5-debuginfo References https://attackerkb.com/topics/cve-2024-26458 CVE - 2024-26458 https://errata.rockylinux.org/RLSA-2024:3268

Rocky Linux: CVE-2024-26146: pcs (RLSA-2024-2953) Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 02/29/2024 Created 06/17/2024 Added 06/17/2024 Modified 11/18/2024 Description Rack is a modular Ruby web server interface. Carefully crafted headers can cause header parsing in Rack to take longer than expected resulting in a possible denial of service issue. Accept and Forwarded headers are impacted. Ruby 3.2 has mitigations for this problem, so Rack applications using Ruby 3.2 or newer are unaffected. This vulnerability is fixed in 2.0.9.4, 2.1.4.4, 2.2.8.1, and 3.0.9.1. Solution(s) rocky-upgrade-pcs rocky-upgrade-pcs-snmp References https://attackerkb.com/topics/cve-2024-26146 CVE - 2024-26146 https://errata.rockylinux.org/RLSA-2024:2953

Rocky Linux: CVE-2024-26141: pcs (RLSA-2024-2953) Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 02/29/2024 Created 06/17/2024 Added 06/17/2024 Modified 11/18/2024 Description Rack is a modular Ruby web server interface. Carefully crafted Range headers can cause a server to respond with an unexpectedly large response. Responding with such large responses could lead to a denial of service issue. Vulnerable applications will use the `Rack::File` middleware or the `Rack::Utils.byte_ranges` methods (this includes Rails applications). The vulnerability is fixed in 3.0.9.1 and 2.2.8.1. Solution(s) rocky-upgrade-pcs rocky-upgrade-pcs-snmp References https://attackerkb.com/topics/cve-2024-26141 CVE - 2024-26141 https://errata.rockylinux.org/RLSA-2024:2953

Debian: CVE-2023-52479: linux -- security update Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 02/29/2024 Created 07/31/2024 Added 07/30/2024 Modified 07/30/2024 Description In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix uaf in smb20_oplock_break_ack drop reference after use opinfo. Solution(s) debian-upgrade-linux References https://attackerkb.com/topics/cve-2023-52479 CVE - 2023-52479

Debian: CVE-2024-1939: chromium -- security update Severity 9 CVSS (AV:N/AC:M/Au:N/C:C/I:C/A:C) Published 02/29/2024 Created 03/02/2024 Added 03/01/2024 Modified 01/28/2025 Description Type Confusion in V8 in Google Chrome prior to 122.0.6261.94 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page. (Chromium security severity: High) Solution(s) debian-upgrade-chromium References https://attackerkb.com/topics/cve-2024-1939 CVE - 2024-1939 DSA-5634-1

Debian: CVE-2023-52481: linux -- security update Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 02/29/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: errata: Add Cortex-A520 speculative unprivileged load workaround Implement the workaround for ARM Cortex-A520 erratum 2966298. On an affected Cortex-A520 core, a speculatively executed unprivileged load might leak data from a privileged load via a cache side channel. The issue only exists for loads within a translation regime with the same translation (e.g. same ASID and VMID). Therefore, the issue only affects the return to EL0. The workaround is to execute a TLBI before returning to EL0 after all loads of privileged data. A non-shareable TLBI to any address is sufficient. The workaround isn't necessary if page table isolation (KPTI) is enabled, but for simplicity it will be. Page table isolation should normally be disabled for Cortex-A520 as it supports the CSV3 feature and the E0PD feature (used when KASLR is enabled). Solution(s) debian-upgrade-linux References https://attackerkb.com/topics/cve-2023-52481 CVE - 2023-52481

Debian: CVE-2023-52478: linux -- security update Severity 4 CVSS (AV:L/AC:M/Au:S/C:N/I:N/A:C) Published 02/29/2024 Created 07/31/2024 Added 07/30/2024 Modified 01/30/2025 Description In the Linux kernel, the following vulnerability has been resolved: HID: logitech-hidpp: Fix kernel crash on receiver USB disconnect hidpp_connect_event() has *four* time-of-check vs time-of-use (TOCTOU) races when it races with itself. hidpp_connect_event() primarily runs from a workqueue but it also runs on probe() and if a "device-connected" packet is received by the hw when the thread running hidpp_connect_event() from probe() is waiting on the hw, then a second thread running hidpp_connect_event() will be started from the workqueue. This opens the following races (note the below code is simplified): 1. Retrieving + printing the protocol (harmless race): if (!hidpp->protocol_major) { hidpp_root_get_protocol_version() hidpp->protocol_major = response.rap.params[0]; } We can actually see this race hit in the dmesg in the abrt output attached to rhbz#2227968: [ 3064.624215] logitech-hidpp-device 0003:046D:4071.0049: HID++ 4.5 device connected. [ 3064.658184] logitech-hidpp-device 0003:046D:4071.0049: HID++ 4.5 device connected. Testing with extra logging added has shown that after this the 2 threads take turn grabbing the hw access mutex (send_mutex) so they ping-pong through all the other TOCTOU cases managing to hit all of them: 2. Updating the name to the HIDPP name (harmless race): if (hidpp->name == hdev->name) { ... hidpp->name = new_name; } 3. Initializing the power_supply class for the battery (problematic!): hidpp_initialize_battery() { if (hidpp->battery.ps) return 0; probe_battery(); /* Blocks, threads take turns executing this */ hidpp->battery.desc.properties = devm_kmemdup(dev, hidpp_battery_props, cnt, GFP_KERNEL); hidpp->battery.ps = devm_power_supply_register(&hidpp->hid_dev->dev, &hidpp->battery.desc, cfg); } 4. Creating delayed input_device (potentially problematic): if (hidpp->delayed_input) return; hidpp->delayed_input = hidpp_allocate_input(hdev); The really big problem here is 3. Hitting the race leads to the following sequence: hidpp->battery.desc.properties = devm_kmemdup(dev, hidpp_battery_props, cnt, GFP_KERNEL); hidpp->battery.ps = devm_power_supply_register(&hidpp->hid_dev->dev, &hidpp->battery.desc, cfg); ... hidpp->battery.desc.properties = devm_kmemdup(dev, hidpp_battery_props, cnt, GFP_KERNEL); hidpp->battery.ps = devm_power_supply_register(&hidpp->hid_dev->dev, &hidpp->battery.desc, cfg); So now we have registered 2 power supplies for the same battery, which looks a bit weird from userspace's pov but this is not even the really big problem. Notice how: 1. This is all devm-maganaged 2. The hidpp->battery.desc struct is shared between the 2 power supplies 3. hidpp->battery.desc.properties points to the result from the second devm_kmemdup() This causes a use after free scenario on USB disconnect of the receiver: 1. The last registered power supply class device gets unregistered 2. The memory from the last devm_kmemdup() call gets freed, hidpp->battery.desc.properties now points to freed memory 3. The first registered power supply class device gets unregistered, this involves sending a remove uevent to userspace which invokes power_supply_uevent() to fill the uevent data 4. power_supply_uevent() uses hidpp->battery.desc.properties which now points to freed memory leading to backtraces like this one: Sep 22 20:01:35 eric kernel: BUG: unable to handle page fault for address: ffffb2140e017f08 ... Sep 22 20:01:35 eric kernel: Workqueue: usb_hub_wq hub_event Sep 22 20:01:35 eric kernel: RIP: 0010:power_supply_uevent+0xee/0x1d0 ... Sep 22 20:01:35 eric kernel:? asm_exc_page_fault+0x26/0x30 Sep 22 20:01:35 eric kernel:? power_supply_uevent+0xee/0x1d0 Sep 22 20:01:35 eric kernel:? power_supply_uevent+0x10d/0x1d0 Sep 22 20:01:35 eric kernel:dev_uevent+0x10f/0x2d0 Sep 22 20:01:35 eric kernel:kobject_uevent_env+0x291/0x680 Sep 22 20:01:35 eric kernel: ---truncated--- Solution(s) debian-upgrade-linux References https://attackerkb.com/topics/cve-2023-52478 CVE - 2023-52478

Oracle Linux: CVE-2024-26615: ELSA-2024-3618:kernel update (MODERATE) (Multiple Advisories) Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 02/29/2024 Created 06/07/2024 Added 06/06/2024 Modified 01/07/2025 Description In the Linux kernel, the following vulnerability has been resolved: net/smc: fix illegal rmb_desc access in SMC-D connection dump A crash was found when dumping SMC-D connections. It can be reproduced by following steps: - run nginx/wrk test: smc_run nginx smc_run wrk -t 16 -c 1000 -d &lt;duration&gt; -H &apos;Connection: Close&apos; &lt;URL&gt; - continuously dump SMC-D connections in parallel: watch -n 1 &apos;smcss -D&apos; BUG: kernel NULL pointer dereference, address: 0000000000000030 CPU: 2 PID: 7204 Comm: smcss Kdump: loaded Tainted: GE6.7.0+ #55 RIP: 0010:__smc_diag_dump.constprop.0+0x5e5/0x620 [smc_diag] Call Trace: &lt;TASK&gt; ? __die+0x24/0x70 ? page_fault_oops+0x66/0x150 ? exc_page_fault+0x69/0x140 ? asm_exc_page_fault+0x26/0x30 ? __smc_diag_dump.constprop.0+0x5e5/0x620 [smc_diag] ? __kmalloc_node_track_caller+0x35d/0x430 ? __alloc_skb+0x77/0x170 smc_diag_dump_proto+0xd0/0xf0 [smc_diag] smc_diag_dump+0x26/0x60 [smc_diag] netlink_dump+0x19f/0x320 __netlink_dump_start+0x1dc/0x300 smc_diag_handler_dump+0x6a/0x80 [smc_diag] ? __pfx_smc_diag_dump+0x10/0x10 [smc_diag] sock_diag_rcv_msg+0x121/0x140 ? __pfx_sock_diag_rcv_msg+0x10/0x10 netlink_rcv_skb+0x5a/0x110 sock_diag_rcv+0x28/0x40 netlink_unicast+0x22a/0x330 netlink_sendmsg+0x1f8/0x420 __sock_sendmsg+0xb0/0xc0 ____sys_sendmsg+0x24e/0x300 ? copy_msghdr_from_user+0x62/0x80 ___sys_sendmsg+0x7c/0xd0 ? __do_fault+0x34/0x160 ? do_read_fault+0x5f/0x100 ? do_fault+0xb0/0x110 ? __handle_mm_fault+0x2b0/0x6c0 __sys_sendmsg+0x4d/0x80 do_syscall_64+0x69/0x180 entry_SYSCALL_64_after_hwframe+0x6e/0x76 It is possible that the connection is in process of being established when we dump it. Assumed that the connection has been registered in a link group by smc_conn_create() but the rmb_desc has not yet been initialized by smc_buf_create(), thus causing the illegal access to conn-&gt;rmb_desc. So fix it by checking before dump. A flaw was found in the Linux kernel in which functions providing information about SMC-D connections caused a NULL pointer dereference. This flaw allows an attacker with permission to read this information to cause a denial of service. Solution(s) oracle-linux-upgrade-kernel References https://attackerkb.com/topics/cve-2024-26615 CVE - 2024-26615 ELSA-2024-3618 ELSA-2024-10939

Oracle Linux: CVE-2024-26609: ELSA-2024-2394:kernel security, bug fix, and enhancement update (IMPORTANT) (Multiple Advisories) Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 02/29/2024 Created 05/21/2024 Added 05/14/2024 Modified 01/07/2025 Description This CVE ID has been rejected or withdrawn by its CVE Numbering Authority for the following reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority. Solution(s) oracle-linux-upgrade-kernel References https://attackerkb.com/topics/cve-2024-26609 CVE - 2024-26609 ELSA-2024-2394 ELSA-2024-3138

Apache OFBiz: CVE-2024-25065: Path Traversal vulnerability. Severity 9 CVSS (AV:N/AC:L/Au:N/C:C/I:C/A:N) Published 02/28/2024 Created 01/10/2025 Added 12/23/2024 Modified 12/23/2024 Description Possible path traversal in Apache OFBiz allowing authentication bypass. Users are recommended to upgrade to version 18.12.12, that fixes the issue. Solution(s) apache-ofbiz-upgrade-latest References https://attackerkb.com/topics/cve-2024-25065 CVE - 2024-25065

Ubuntu: (CVE-2021-47041): linux vulnerability Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 02/28/2024 Created 11/21/2024 Added 11/19/2024 Modified 02/11/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) ubuntu-upgrade-linux ubuntu-upgrade-linux-aws ubuntu-upgrade-linux-aws-5-4 ubuntu-upgrade-linux-aws-fips ubuntu-upgrade-linux-azure 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-5-4 ubuntu-upgrade-linux-gcp-fips ubuntu-upgrade-linux-gkeop ubuntu-upgrade-linux-hwe-5-4 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-2021-47041 CVE - 2021-47041 https://git.kernel.org/linus/b5332a9f3f3d884a1b646ce155e664cc558c1722 https://git.kernel.org/stable/c/06beaa1a9f6e501213195e47c30416032fd2bbd5 https://git.kernel.org/stable/c/60ade0d56b06537a28884745059b3801c78e03bc https://git.kernel.org/stable/c/906c538340dde6d891df89fe7dac8eaa724e40da https://git.kernel.org/stable/c/999d606a820c36ae9b9e9611360c8b3d8d4bb777 https://git.kernel.org/stable/c/b5332a9f3f3d884a1b646ce155e664cc558c1722 https://www.cve.org/CVERecord?id=CVE-2021-47041 View more