ISHACK AI BOT

Ubuntu: (CVE-2024-27062): linux-raspi-realtime vulnerability Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 05/01/2024 Created 02/12/2025 Added 02/11/2025 Modified 02/11/2025 Description In the Linux kernel, the following vulnerability has been resolved: nouveau: lock the client object tree. It appears the client object tree has no locking unless I've missed something else. Fix races around adding/removing client objects, mostly vram bar mappings. 4562.099306] general protection fault, probably for non-canonical address 0x6677ed422bceb80c: 0000 [#1] PREEMPT SMP PTI [ 4562.099314] CPU: 2 PID: 23171 Comm: deqp-vk Not tainted 6.8.0-rc6+ #27 [ 4562.099324] Hardware name: Gigabyte Technology Co., Ltd. Z390 I AORUS PRO WIFI/Z390 I AORUS PRO WIFI-CF, BIOS F8 11/05/2021 [ 4562.099330] RIP: 0010:nvkm_object_search+0x1d/0x70 [nouveau] [ 4562.099503] Code: 90 90 90 90 90 90 90 90 90 90 90 90 90 66 0f 1f 00 0f 1f 44 00 00 48 89 f8 48 85 f6 74 39 48 8b 87 a0 00 00 00 48 85 c0 74 12 <48> 8b 48 f8 48 39 ce 73 15 48 8b 40 10 48 85 c0 75 ee 48 c7 c0 fe [ 4562.099506] RSP: 0000:ffffa94cc420bbf8 EFLAGS: 00010206 [ 4562.099512] RAX: 6677ed422bceb814 RBX: ffff98108791f400 RCX: ffff9810f26b8f58 [ 4562.099517] RDX: 0000000000000000 RSI: ffff9810f26b9158 RDI: ffff98108791f400 [ 4562.099519] RBP: ffff9810f26b9158 R08: 0000000000000000 R09: 0000000000000000 [ 4562.099521] R10: ffffa94cc420bc48 R11: 0000000000000001 R12: ffff9810f02a7cc0 [ 4562.099526] R13: 0000000000000000 R14: 00000000000000ff R15: 0000000000000007 [ 4562.099528] FS:00007f629c5017c0(0000) GS:ffff98142c700000(0000) knlGS:0000000000000000 [ 4562.099534] CS:0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 4562.099536] CR2: 00007f629a882000 CR3: 000000017019e004 CR4: 00000000003706f0 [ 4562.099541] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 4562.099542] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 4562.099544] Call Trace: [ 4562.099555]<TASK> [ 4562.099573]? die_addr+0x36/0x90 [ 4562.099583]? exc_general_protection+0x246/0x4a0 [ 4562.099593]? asm_exc_general_protection+0x26/0x30 [ 4562.099600]? nvkm_object_search+0x1d/0x70 [nouveau] [ 4562.099730]nvkm_ioctl+0xa1/0x250 [nouveau] [ 4562.099861]nvif_object_map_handle+0xc8/0x180 [nouveau] [ 4562.099986]nouveau_ttm_io_mem_reserve+0x122/0x270 [nouveau] [ 4562.100156]? dma_resv_test_signaled+0x26/0xb0 [ 4562.100163]ttm_bo_vm_fault_reserved+0x97/0x3c0 [ttm] [ 4562.100182]? __mutex_unlock_slowpath+0x2a/0x270 [ 4562.100189]nouveau_ttm_fault+0x69/0xb0 [nouveau] [ 4562.100356]__do_fault+0x32/0x150 [ 4562.100362]do_fault+0x7c/0x560 [ 4562.100369]__handle_mm_fault+0x800/0xc10 [ 4562.100382]handle_mm_fault+0x17c/0x3e0 [ 4562.100388]do_user_addr_fault+0x208/0x860 [ 4562.100395]exc_page_fault+0x7f/0x200 [ 4562.100402]asm_exc_page_fault+0x26/0x30 [ 4562.100412] RIP: 0033:0x9b9870 [ 4562.100419] Code: 85 a8 f7 ff ff 8b 8d 80 f7 ff ff 89 08 e9 18 f2 ff ff 0f 1f 84 00 00 00 00 00 44 89 32 e9 90 fa ff ff 0f 1f 84 00 00 00 00 00 <44> 89 32 e9 f8 f1 ff ff 0f 1f 84 00 00 00 00 00 66 44 89 32 e9 e7 [ 4562.100422] RSP: 002b:00007fff9ba2dc70 EFLAGS: 00010246 [ 4562.100426] RAX: 0000000000000004 RBX: 000000000dd65e10 RCX: 000000fff0000000 [ 4562.100428] RDX: 00007f629a882000 RSI: 00007f629a882000 RDI: 0000000000000066 [ 4562.100432] RBP: 00007fff9ba2e570 R08: 0000000000000000 R09: 0000000123ddf000 [ 4562.100434] R10: 0000000000000001 R11: 0000000000000246 R12: 000000007fffffff [ 4562.100436] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 [ 4562.100446]</TASK> [ 4562.100448] Modules linked in: nf_conntrack_netbios_ns nf_conntrack_broadcast nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables libcrc32c nfnetlink cmac bnep sunrpc iwlmvm intel_rapl_msr intel_rapl_common snd_sof_pci_intel_cnl x86_pkg_temp_thermal intel_powerclamp snd_sof_intel_hda_common mac80211 coretemp snd_soc_acpi_intel_match kvm_intel snd_soc_acpi snd_soc_hdac_hda snd_sof_pci snd_sof_xtensa_dsp snd_sof_intel_hda_mlink ---truncated--- Solution(s) ubuntu-upgrade-linux-raspi-realtime References https://attackerkb.com/topics/cve-2024-27062 CVE - 2024-27062 https://git.kernel.org/linus/b7cc4ff787a572edf2c55caeffaa88cd801eb135 https://git.kernel.org/stable/c/6887314f5356389fc219b8152e951ac084a10ef7 https://git.kernel.org/stable/c/96c8751844171af4b3898fee3857ee180586f589 https://git.kernel.org/stable/c/b7cc4ff787a572edf2c55caeffaa88cd801eb135 https://www.cve.org/CVERecord?id=CVE-2024-27062

Ubuntu: (Multiple Advisories) (CVE-2024-26975): Linux kernel vulnerabilities Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 05/01/2024 Created 07/02/2024 Added 07/01/2024 Modified 01/30/2025 Description In the Linux kernel, the following vulnerability has been resolved: powercap: intel_rapl: Fix a NULL pointer dereference A NULL pointer dereference is triggered when probing the MMIO RAPL driver on platforms with CPU ID not listed in intel_rapl_common CPU model list. This is because the intel_rapl_common module still probes on such platforms even if 'defaults_msr' is not set after commit 1488ac990ac8 ("powercap: intel_rapl: Allow probing without CPUID match"). Thus the MMIO RAPL rp->priv->defaults is NULL when registering to RAPL framework. Fix the problem by adding sanity check to ensure rp->priv->rapl_defaults is always valid. Solution(s) ubuntu-upgrade-linux-image-6-8-0-1004-gke ubuntu-upgrade-linux-image-6-8-0-1005-raspi ubuntu-upgrade-linux-image-6-8-0-1006-ibm ubuntu-upgrade-linux-image-6-8-0-1006-oem ubuntu-upgrade-linux-image-6-8-0-1006-oracle ubuntu-upgrade-linux-image-6-8-0-1006-oracle-64k ubuntu-upgrade-linux-image-6-8-0-1008-azure ubuntu-upgrade-linux-image-6-8-0-1008-azure-fde ubuntu-upgrade-linux-image-6-8-0-1008-gcp ubuntu-upgrade-linux-image-6-8-0-1009-aws ubuntu-upgrade-linux-image-6-8-0-35-generic ubuntu-upgrade-linux-image-6-8-0-35-generic-64k ubuntu-upgrade-linux-image-6-8-0-35-lowlatency ubuntu-upgrade-linux-image-6-8-0-35-lowlatency-64k ubuntu-upgrade-linux-image-aws ubuntu-upgrade-linux-image-azure ubuntu-upgrade-linux-image-azure-fde ubuntu-upgrade-linux-image-gcp ubuntu-upgrade-linux-image-generic ubuntu-upgrade-linux-image-generic-64k ubuntu-upgrade-linux-image-generic-64k-hwe-24-04 ubuntu-upgrade-linux-image-generic-hwe-24-04 ubuntu-upgrade-linux-image-generic-lpae ubuntu-upgrade-linux-image-gke ubuntu-upgrade-linux-image-ibm ubuntu-upgrade-linux-image-ibm-classic ubuntu-upgrade-linux-image-ibm-lts-24-04 ubuntu-upgrade-linux-image-kvm ubuntu-upgrade-linux-image-lowlatency ubuntu-upgrade-linux-image-lowlatency-64k ubuntu-upgrade-linux-image-oem-24-04 ubuntu-upgrade-linux-image-oem-24-04a ubuntu-upgrade-linux-image-oracle ubuntu-upgrade-linux-image-oracle-64k ubuntu-upgrade-linux-image-raspi ubuntu-upgrade-linux-image-virtual ubuntu-upgrade-linux-image-virtual-hwe-24-04 References https://attackerkb.com/topics/cve-2024-26975 CVE - 2024-26975 USN-6816-1 USN-6817-1 USN-6817-2 USN-6817-3 USN-6878-1

Ubuntu: (Multiple Advisories) (CVE-2024-27041): Linux kernel vulnerabilities Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 05/01/2024 Created 07/02/2024 Added 07/01/2024 Modified 07/15/2024 Description In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: fix NULL checks for adev->dm.dc in amdgpu_dm_fini() Since 'adev->dm.dc' in amdgpu_dm_fini() might turn out to be NULL before the call to dc_enable_dmub_notifications(), check beforehand to ensure there will not be a possible NULL-ptr-deref there. Also, since commit 1e88eb1b2c25 ("drm/amd/display: Drop CONFIG_DRM_AMD_DC_HDCP") there are two separate checks for NULL in 'adev->dm.dc' before dc_deinit_callbacks() and dc_dmub_srv_destroy(). Clean up by combining them all under one 'if'. Found by Linux Verification Center (linuxtesting.org) with static analysis tool SVACE. Solution(s) ubuntu-upgrade-linux-image-6-8-0-1004-gke ubuntu-upgrade-linux-image-6-8-0-1005-raspi ubuntu-upgrade-linux-image-6-8-0-1006-ibm ubuntu-upgrade-linux-image-6-8-0-1006-oem ubuntu-upgrade-linux-image-6-8-0-1006-oracle ubuntu-upgrade-linux-image-6-8-0-1006-oracle-64k ubuntu-upgrade-linux-image-6-8-0-1008-azure ubuntu-upgrade-linux-image-6-8-0-1008-azure-fde ubuntu-upgrade-linux-image-6-8-0-1008-gcp ubuntu-upgrade-linux-image-6-8-0-1009-aws ubuntu-upgrade-linux-image-6-8-0-35-generic ubuntu-upgrade-linux-image-6-8-0-35-generic-64k ubuntu-upgrade-linux-image-6-8-0-35-lowlatency ubuntu-upgrade-linux-image-6-8-0-35-lowlatency-64k ubuntu-upgrade-linux-image-aws ubuntu-upgrade-linux-image-azure ubuntu-upgrade-linux-image-azure-fde ubuntu-upgrade-linux-image-gcp ubuntu-upgrade-linux-image-generic ubuntu-upgrade-linux-image-generic-64k ubuntu-upgrade-linux-image-generic-64k-hwe-24-04 ubuntu-upgrade-linux-image-generic-hwe-24-04 ubuntu-upgrade-linux-image-generic-lpae ubuntu-upgrade-linux-image-gke ubuntu-upgrade-linux-image-ibm ubuntu-upgrade-linux-image-ibm-classic ubuntu-upgrade-linux-image-ibm-lts-24-04 ubuntu-upgrade-linux-image-kvm ubuntu-upgrade-linux-image-lowlatency ubuntu-upgrade-linux-image-lowlatency-64k ubuntu-upgrade-linux-image-oem-24-04 ubuntu-upgrade-linux-image-oem-24-04a ubuntu-upgrade-linux-image-oracle ubuntu-upgrade-linux-image-oracle-64k ubuntu-upgrade-linux-image-raspi ubuntu-upgrade-linux-image-virtual ubuntu-upgrade-linux-image-virtual-hwe-24-04 References https://attackerkb.com/topics/cve-2024-27041 CVE - 2024-27041 USN-6816-1 USN-6817-1 USN-6817-2 USN-6817-3 USN-6878-1

Ubuntu: (Multiple Advisories) (CVE-2024-27066): Linux kernel vulnerabilities Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 05/01/2024 Created 07/02/2024 Added 07/01/2024 Modified 07/15/2024 Description In the Linux kernel, the following vulnerability has been resolved: virtio: packed: fix unmap leak for indirect desc table When use_dma_api and premapped are true, then the do_unmap is false. Because the do_unmap is false, vring_unmap_extra_packed is not called by detach_buf_packed. if (unlikely(vq->do_unmap)) { curr = id; for (i = 0; i < state->num; i++) { vring_unmap_extra_packed(vq, &vq->packed.desc_extra[curr]); curr = vq->packed.desc_extra[curr].next; } } So the indirect desc table is not unmapped. This causes the unmap leak. So here, we check vq->use_dma_api instead. Synchronously, dma info is updated based on use_dma_api judgment This bug does not occur, because no driver use the premapped with indirect. Solution(s) ubuntu-upgrade-linux-image-6-8-0-1004-gke ubuntu-upgrade-linux-image-6-8-0-1005-raspi ubuntu-upgrade-linux-image-6-8-0-1006-ibm ubuntu-upgrade-linux-image-6-8-0-1006-oem ubuntu-upgrade-linux-image-6-8-0-1006-oracle ubuntu-upgrade-linux-image-6-8-0-1006-oracle-64k ubuntu-upgrade-linux-image-6-8-0-1008-azure ubuntu-upgrade-linux-image-6-8-0-1008-azure-fde ubuntu-upgrade-linux-image-6-8-0-1008-gcp ubuntu-upgrade-linux-image-6-8-0-1009-aws ubuntu-upgrade-linux-image-6-8-0-35-generic ubuntu-upgrade-linux-image-6-8-0-35-generic-64k ubuntu-upgrade-linux-image-6-8-0-35-lowlatency ubuntu-upgrade-linux-image-6-8-0-35-lowlatency-64k ubuntu-upgrade-linux-image-aws ubuntu-upgrade-linux-image-azure ubuntu-upgrade-linux-image-azure-fde ubuntu-upgrade-linux-image-gcp ubuntu-upgrade-linux-image-generic ubuntu-upgrade-linux-image-generic-64k ubuntu-upgrade-linux-image-generic-64k-hwe-24-04 ubuntu-upgrade-linux-image-generic-hwe-24-04 ubuntu-upgrade-linux-image-generic-lpae ubuntu-upgrade-linux-image-gke ubuntu-upgrade-linux-image-ibm ubuntu-upgrade-linux-image-ibm-classic ubuntu-upgrade-linux-image-ibm-lts-24-04 ubuntu-upgrade-linux-image-kvm ubuntu-upgrade-linux-image-lowlatency ubuntu-upgrade-linux-image-lowlatency-64k ubuntu-upgrade-linux-image-oem-24-04 ubuntu-upgrade-linux-image-oem-24-04a ubuntu-upgrade-linux-image-oracle ubuntu-upgrade-linux-image-oracle-64k ubuntu-upgrade-linux-image-raspi ubuntu-upgrade-linux-image-virtual ubuntu-upgrade-linux-image-virtual-hwe-24-04 References https://attackerkb.com/topics/cve-2024-27066 CVE - 2024-27066 USN-6816-1 USN-6817-1 USN-6817-2 USN-6817-3 USN-6878-1

Ubuntu: (Multiple Advisories) (CVE-2024-27068): Linux kernel vulnerabilities Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 05/01/2024 Created 07/02/2024 Added 07/01/2024 Modified 01/30/2025 Description In the Linux kernel, the following vulnerability has been resolved: thermal/drivers/mediatek/lvts_thermal: Fix a memory leak in an error handling path If devm_krealloc() fails, then 'efuse' is leaking. So free it to avoid a leak. Solution(s) ubuntu-upgrade-linux-image-6-8-0-1004-gke ubuntu-upgrade-linux-image-6-8-0-1005-raspi ubuntu-upgrade-linux-image-6-8-0-1006-ibm ubuntu-upgrade-linux-image-6-8-0-1006-oem ubuntu-upgrade-linux-image-6-8-0-1006-oracle ubuntu-upgrade-linux-image-6-8-0-1006-oracle-64k ubuntu-upgrade-linux-image-6-8-0-1008-azure ubuntu-upgrade-linux-image-6-8-0-1008-azure-fde ubuntu-upgrade-linux-image-6-8-0-1008-gcp ubuntu-upgrade-linux-image-6-8-0-1009-aws ubuntu-upgrade-linux-image-6-8-0-35-generic ubuntu-upgrade-linux-image-6-8-0-35-generic-64k ubuntu-upgrade-linux-image-6-8-0-35-lowlatency ubuntu-upgrade-linux-image-6-8-0-35-lowlatency-64k ubuntu-upgrade-linux-image-aws ubuntu-upgrade-linux-image-azure ubuntu-upgrade-linux-image-azure-fde ubuntu-upgrade-linux-image-gcp ubuntu-upgrade-linux-image-generic ubuntu-upgrade-linux-image-generic-64k ubuntu-upgrade-linux-image-generic-64k-hwe-24-04 ubuntu-upgrade-linux-image-generic-hwe-24-04 ubuntu-upgrade-linux-image-generic-lpae ubuntu-upgrade-linux-image-gke ubuntu-upgrade-linux-image-ibm ubuntu-upgrade-linux-image-ibm-classic ubuntu-upgrade-linux-image-ibm-lts-24-04 ubuntu-upgrade-linux-image-kvm ubuntu-upgrade-linux-image-lowlatency ubuntu-upgrade-linux-image-lowlatency-64k ubuntu-upgrade-linux-image-oem-24-04 ubuntu-upgrade-linux-image-oem-24-04a ubuntu-upgrade-linux-image-oracle ubuntu-upgrade-linux-image-oracle-64k ubuntu-upgrade-linux-image-raspi ubuntu-upgrade-linux-image-virtual ubuntu-upgrade-linux-image-virtual-hwe-24-04 References https://attackerkb.com/topics/cve-2024-27068 CVE - 2024-27068 USN-6816-1 USN-6817-1 USN-6817-2 USN-6817-3 USN-6878-1

Ubuntu: (Multiple Advisories) (CVE-2024-26973): Linux kernel vulnerabilities Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 05/01/2024 Created 07/02/2024 Added 07/01/2024 Modified 09/20/2024 Description In the Linux kernel, the following vulnerability has been resolved: fat: fix uninitialized field in nostale filehandles When fat_encode_fh_nostale() encodes file handle without a parent it stores only first 10 bytes of the file handle. However the length of the file handle must be a multiple of 4 so the file handle is actually 12 bytes long and the last two bytes remain uninitialized. This is not great at we potentially leak uninitialized information with the handle to userspace. Properly initialize the full handle length. Solution(s) ubuntu-upgrade-linux-image-5-15-0-1035-xilinx-zynqmp ubuntu-upgrade-linux-image-5-15-0-1048-gkeop ubuntu-upgrade-linux-image-5-15-0-1058-ibm ubuntu-upgrade-linux-image-5-15-0-1058-raspi ubuntu-upgrade-linux-image-5-15-0-1060-intel-iotg ubuntu-upgrade-linux-image-5-15-0-1060-nvidia ubuntu-upgrade-linux-image-5-15-0-1060-nvidia-lowlatency ubuntu-upgrade-linux-image-5-15-0-1062-gke ubuntu-upgrade-linux-image-5-15-0-1062-kvm ubuntu-upgrade-linux-image-5-15-0-1063-oracle ubuntu-upgrade-linux-image-5-15-0-1064-gcp ubuntu-upgrade-linux-image-5-15-0-1065-aws ubuntu-upgrade-linux-image-5-15-0-1065-gcp ubuntu-upgrade-linux-image-5-15-0-1068-azure ubuntu-upgrade-linux-image-5-15-0-1068-azure-fde ubuntu-upgrade-linux-image-5-15-0-116-generic ubuntu-upgrade-linux-image-5-15-0-116-generic-64k ubuntu-upgrade-linux-image-5-15-0-116-generic-lpae ubuntu-upgrade-linux-image-5-15-0-116-lowlatency ubuntu-upgrade-linux-image-5-15-0-116-lowlatency-64k ubuntu-upgrade-linux-image-5-4-0-1040-iot ubuntu-upgrade-linux-image-5-4-0-1047-xilinx-zynqmp ubuntu-upgrade-linux-image-5-4-0-1075-ibm ubuntu-upgrade-linux-image-5-4-0-1088-bluefield ubuntu-upgrade-linux-image-5-4-0-1095-gkeop ubuntu-upgrade-linux-image-5-4-0-1112-raspi ubuntu-upgrade-linux-image-5-4-0-1116-kvm ubuntu-upgrade-linux-image-5-4-0-1127-oracle ubuntu-upgrade-linux-image-5-4-0-1128-aws ubuntu-upgrade-linux-image-5-4-0-1132-gcp ubuntu-upgrade-linux-image-5-4-0-1133-azure ubuntu-upgrade-linux-image-5-4-0-189-generic ubuntu-upgrade-linux-image-5-4-0-189-generic-lpae ubuntu-upgrade-linux-image-5-4-0-189-lowlatency ubuntu-upgrade-linux-image-6-8-0-1004-gke ubuntu-upgrade-linux-image-6-8-0-1005-raspi ubuntu-upgrade-linux-image-6-8-0-1006-ibm ubuntu-upgrade-linux-image-6-8-0-1006-oem ubuntu-upgrade-linux-image-6-8-0-1006-oracle ubuntu-upgrade-linux-image-6-8-0-1006-oracle-64k ubuntu-upgrade-linux-image-6-8-0-1008-azure ubuntu-upgrade-linux-image-6-8-0-1008-azure-fde ubuntu-upgrade-linux-image-6-8-0-1008-gcp ubuntu-upgrade-linux-image-6-8-0-1009-aws ubuntu-upgrade-linux-image-6-8-0-35-generic ubuntu-upgrade-linux-image-6-8-0-35-generic-64k ubuntu-upgrade-linux-image-6-8-0-35-lowlatency ubuntu-upgrade-linux-image-6-8-0-35-lowlatency-64k ubuntu-upgrade-linux-image-aws ubuntu-upgrade-linux-image-aws-lts-20-04 ubuntu-upgrade-linux-image-aws-lts-22-04 ubuntu-upgrade-linux-image-azure ubuntu-upgrade-linux-image-azure-cvm ubuntu-upgrade-linux-image-azure-fde ubuntu-upgrade-linux-image-azure-fde-lts-22-04 ubuntu-upgrade-linux-image-azure-lts-20-04 ubuntu-upgrade-linux-image-azure-lts-22-04 ubuntu-upgrade-linux-image-bluefield ubuntu-upgrade-linux-image-gcp ubuntu-upgrade-linux-image-gcp-lts-20-04 ubuntu-upgrade-linux-image-gcp-lts-22-04 ubuntu-upgrade-linux-image-generic ubuntu-upgrade-linux-image-generic-64k ubuntu-upgrade-linux-image-generic-64k-hwe-20-04 ubuntu-upgrade-linux-image-generic-64k-hwe-24-04 ubuntu-upgrade-linux-image-generic-hwe-18-04 ubuntu-upgrade-linux-image-generic-hwe-20-04 ubuntu-upgrade-linux-image-generic-hwe-24-04 ubuntu-upgrade-linux-image-generic-lpae ubuntu-upgrade-linux-image-generic-lpae-hwe-20-04 ubuntu-upgrade-linux-image-gke ubuntu-upgrade-linux-image-gke-5-15 ubuntu-upgrade-linux-image-gkeop ubuntu-upgrade-linux-image-gkeop-5-15 ubuntu-upgrade-linux-image-gkeop-5-4 ubuntu-upgrade-linux-image-ibm ubuntu-upgrade-linux-image-ibm-classic ubuntu-upgrade-linux-image-ibm-lts-20-04 ubuntu-upgrade-linux-image-ibm-lts-24-04 ubuntu-upgrade-linux-image-intel ubuntu-upgrade-linux-image-intel-iotg ubuntu-upgrade-linux-image-kvm ubuntu-upgrade-linux-image-lowlatency ubuntu-upgrade-linux-image-lowlatency-64k ubuntu-upgrade-linux-image-lowlatency-64k-hwe-20-04 ubuntu-upgrade-linux-image-lowlatency-hwe-18-04 ubuntu-upgrade-linux-image-lowlatency-hwe-20-04 ubuntu-upgrade-linux-image-nvidia ubuntu-upgrade-linux-image-nvidia-lowlatency ubuntu-upgrade-linux-image-oem ubuntu-upgrade-linux-image-oem-20-04 ubuntu-upgrade-linux-image-oem-20-04b ubuntu-upgrade-linux-image-oem-20-04c ubuntu-upgrade-linux-image-oem-20-04d ubuntu-upgrade-linux-image-oem-24-04 ubuntu-upgrade-linux-image-oem-24-04a ubuntu-upgrade-linux-image-oem-osp1 ubuntu-upgrade-linux-image-oracle ubuntu-upgrade-linux-image-oracle-64k ubuntu-upgrade-linux-image-oracle-lts-20-04 ubuntu-upgrade-linux-image-oracle-lts-22-04 ubuntu-upgrade-linux-image-raspi ubuntu-upgrade-linux-image-raspi-hwe-18-04 ubuntu-upgrade-linux-image-raspi-nolpae ubuntu-upgrade-linux-image-raspi2 ubuntu-upgrade-linux-image-snapdragon-hwe-18-04 ubuntu-upgrade-linux-image-virtual ubuntu-upgrade-linux-image-virtual-hwe-18-04 ubuntu-upgrade-linux-image-virtual-hwe-20-04 ubuntu-upgrade-linux-image-virtual-hwe-24-04 ubuntu-upgrade-linux-image-xilinx-zynqmp References https://attackerkb.com/topics/cve-2024-26973 CVE - 2024-26973 USN-6816-1 USN-6817-1 USN-6817-2 USN-6817-3 USN-6878-1 USN-6896-1 USN-6896-2 USN-6896-3 USN-6896-4 USN-6896-5 USN-6898-1 USN-6898-2 USN-6898-3 USN-6898-4 USN-6917-1 USN-6919-1 USN-6927-1 USN-7019-1 View more

Oracle Linux: CVE-2024-26933: ELSA-2024-3618:kernel update (MODERATE) (Multiple Advisories) Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 05/01/2024 Created 06/07/2024 Added 06/06/2024 Modified 11/29/2024 Description In the Linux kernel, the following vulnerability has been resolved: USB: core: Fix deadlock in port &quot;disable&quot; sysfs attribute The show and store callback routines for the &quot;disable&quot; sysfs attribute file in port.c acquire the device lock for the port&apos;s parent hub device.This can cause problems if another process has locked the hub to remove it or change its configuration: Removing the hub or changing its configuration requires the hub interface to be removed, which requires the port device to be removed, and device_del() waits until all outstanding sysfs attribute callbacks for the ports have returned.The lock can&apos;t be released until then. But the disable_show() or disable_store() routine can&apos;t return until after it has acquired the lock. The resulting deadlock can be avoided by calling sysfs_break_active_protection().This will cause the sysfs core not to wait for the attribute&apos;s callback routine to return, allowing the removal to proceed.The disadvantage is that after making this call, there is no guarantee that the hub structure won&apos;t be deallocated at any moment.To prevent this, we have to acquire a reference to it first by calling hub_get(). Solution(s) oracle-linux-upgrade-kernel References https://attackerkb.com/topics/cve-2024-26933 CVE - 2024-26933 ELSA-2024-3618

Oracle Linux: CVE-2024-27059: ELSA-2024-3618:kernel update (MODERATE) (Multiple Advisories) Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 05/01/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: usb-storage: Prevent divide-by-0 error in isd200_ata_command The isd200 sub-driver in usb-storage uses the HEADS and SECTORS values in the ATA ID information to calculate cylinder and head values when creating a CDB for READ or WRITE commands.The calculation involves division and modulus operations, which will cause a crash if either of these values is 0.While this never happens with a genuine device, it could happen with a flawed or subversive emulation, as reported by the syzbot fuzzer. Protect against this possibility by refusing to bind to the device if either the ATA_ID_HEADS or ATA_ID_SECTORS value in the device&apos;s ID information is 0.This requires isd200_Initialization() to return a negative error code when initialization fails; currently it always returns 0 (even when there is an error). Solution(s) oracle-linux-upgrade-kernel oracle-linux-upgrade-kernel-uek References https://attackerkb.com/topics/cve-2024-27059 CVE - 2024-27059 ELSA-2024-3618 ELSA-2024-12851

Oracle Linux: CVE-2024-27056: ELSA-2024-3618:kernel update (MODERATE) (Multiple Advisories) Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 05/01/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: mvm: ensure offloading TID queue exists The resume code path assumes that the TX queue for the offloading TID has been configured. At resume time it then tries to sync the write pointer as it may have been updated by the firmware. In the unusual event that no packets have been send on TID 0, the queue will not have been allocated and this causes a crash. Fix this by ensuring the queue exist at suspend time. Solution(s) oracle-linux-upgrade-kernel References https://attackerkb.com/topics/cve-2024-27056 CVE - 2024-27056 ELSA-2024-3618

Red Hat: CVE-2024-26930: kernel: scsi: qla2xxx: Fix double free of the ha-&gt;vp_map pointer (Multiple Advisories) Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 05/01/2024 Created 09/14/2024 Added 09/13/2024 Modified 12/05/2024 Description In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Fix double free of the ha->vp_map pointer Coverity scan reported potential risk of double free of the pointer ha->vp_map.ha->vp_map was freed in qla2x00_mem_alloc(), and again freed in function qla2x00_mem_free(ha). Assign NULL to vp_map and kfree take care of NULL. Solution(s) redhat-upgrade-kernel redhat-upgrade-kernel-rt References CVE-2024-26930 RHSA-2024:5066 RHSA-2024:5067 RHSA-2024:6997

Huawei EulerOS: CVE-2024-27388: kernel security update Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 05/01/2024 Created 07/17/2024 Added 07/17/2024 Modified 01/28/2025 Description In the Linux kernel, the following vulnerability has been resolved: SUNRPC: fix some memleaks in gssx_dec_option_array The creds and oa->data need to be freed in the error-handling paths after their allocation. So this patch add these deallocations in the corresponding paths. 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-2024-27388 CVE - 2024-27388 EulerOS-SA-2024-1964

Huawei EulerOS: CVE-2024-27043: kernel security update Severity 7 CVSS (AV:L/AC:L/Au:S/C:C/I:C/A:C) Published 05/01/2024 Created 07/17/2024 Added 07/17/2024 Modified 01/30/2025 Description In the Linux kernel, the following vulnerability has been resolved: media: edia: dvbdev: fix a use-after-free In dvb_register_device, *pdvbdev is set equal to dvbdev, which is freed in several error-handling paths. However, *pdvbdev is not set to NULL after dvbdev's deallocation, causing use-after-frees in many places, for example, in the following call chain: budget_register |-> dvb_dmxdev_init |-> dvb_register_device |-> dvb_dmxdev_release |-> dvb_unregister_device |-> dvb_remove_device |-> dvb_device_put |-> kref_put When calling dvb_unregister_device, dmxdev->dvbdev (i.e. *pdvbdev in dvb_register_device) could point to memory that had been freed in dvb_register_device. Thereafter, this pointer is transferred to kref_put and triggering a use-after-free. 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-2024-27043 CVE - 2024-27043 EulerOS-SA-2024-1964

Red Hat: CVE-2024-27079: kernel: iommu/vt-d: Fix NULL domain on device release (Multiple Advisories) Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 05/01/2024 Created 12/06/2024 Added 12/05/2024 Modified 12/05/2024 Description In the Linux kernel, the following vulnerability has been resolved: iommu/vt-d: Fix NULL domain on device release In the kdump kernel, the IOMMU operates in deferred_attach mode. In this mode, info->domain may not yet be assigned by the time the release_device function is called. It leads to the following crash in the crash kernel: BUG: kernel NULL pointer dereference, address: 000000000000003c ... RIP: 0010:do_raw_spin_lock+0xa/0xa0 ... _raw_spin_lock_irqsave+0x1b/0x30 intel_iommu_release_device+0x96/0x170 iommu_deinit_device+0x39/0xf0 __iommu_group_remove_device+0xa0/0xd0 iommu_bus_notifier+0x55/0xb0 notifier_call_chain+0x5a/0xd0 blocking_notifier_call_chain+0x41/0x60 bus_notify+0x34/0x50 device_del+0x269/0x3d0 pci_remove_bus_device+0x77/0x100 p2sb_bar+0xae/0x1d0 ... i801_probe+0x423/0x740 Use the release_domain mechanism to fix it. The scalable mode context entry which is not part of release domain should be cleared in release_device(). Solution(s) redhat-upgrade-kernel redhat-upgrade-kernel-rt References CVE-2024-27079 RHSA-2024:9315

Huawei EulerOS: CVE-2024-27020: kernel security update Severity 7 CVSS (AV:L/AC:M/Au:S/C:C/I:C/A:C) Published 05/01/2024 Created 07/17/2024 Added 07/17/2024 Modified 01/28/2025 Description In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: Fix potential data-race in __nft_expr_type_get() nft_unregister_expr() can concurrent with __nft_expr_type_get(), and there is not any protection when iterate over nf_tables_expressions list in __nft_expr_type_get(). Therefore, there is potential data-race of nf_tables_expressions list entry. Use list_for_each_entry_rcu() to iterate over nf_tables_expressions list in __nft_expr_type_get(), and use rcu_read_lock() in the caller nft_expr_type_get() to protect the entire type query process. 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-2024-27020 CVE - 2024-27020 EulerOS-SA-2024-1964

Huawei EulerOS: CVE-2024-27014: kernel security update Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 05/01/2024 Created 07/17/2024 Added 07/17/2024 Modified 01/30/2025 Description In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Prevent deadlock while disabling aRFS When disabling aRFS under the `priv->state_lock`, any scheduled aRFS works are canceled using the `cancel_work_sync` function, which waits for the work to end if it has already started. However, while waiting for the work handler, the handler will try to acquire the `state_lock` which is already acquired. The worker acquires the lock to delete the rules if the state is down, which is not the worker's responsibility since disabling aRFS deletes the rules. Add an aRFS state variable, which indicates whether the aRFS is enabled and prevent adding rules when the aRFS is disabled. Kernel log: ====================================================== WARNING: possible circular locking dependency detected 6.7.0-rc4_net_next_mlx5_5483eb2 #1 Tainted: GI ------------------------------------------------------ ethtool/386089 is trying to acquire lock: ffff88810f21ce68 ((work_completion)(&rule->arfs_work)){+.+.}-{0:0}, at: __flush_work+0x74/0x4e0 but task is already holding lock: ffff8884a1808cc0 (&priv->state_lock){+.+.}-{3:3}, at: mlx5e_ethtool_set_channels+0x53/0x200 [mlx5_core] which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (&priv->state_lock){+.+.}-{3:3}: __mutex_lock+0x80/0xc90 arfs_handle_work+0x4b/0x3b0 [mlx5_core] process_one_work+0x1dc/0x4a0 worker_thread+0x1bf/0x3c0 kthread+0xd7/0x100 ret_from_fork+0x2d/0x50 ret_from_fork_asm+0x11/0x20 -> #0 ((work_completion)(&rule->arfs_work)){+.+.}-{0:0}: __lock_acquire+0x17b4/0x2c80 lock_acquire+0xd0/0x2b0 __flush_work+0x7a/0x4e0 __cancel_work_timer+0x131/0x1c0 arfs_del_rules+0x143/0x1e0 [mlx5_core] mlx5e_arfs_disable+0x1b/0x30 [mlx5_core] mlx5e_ethtool_set_channels+0xcb/0x200 [mlx5_core] ethnl_set_channels+0x28f/0x3b0 ethnl_default_set_doit+0xec/0x240 genl_family_rcv_msg_doit+0xd0/0x120 genl_rcv_msg+0x188/0x2c0 netlink_rcv_skb+0x54/0x100 genl_rcv+0x24/0x40 netlink_unicast+0x1a1/0x270 netlink_sendmsg+0x214/0x460 __sock_sendmsg+0x38/0x60 __sys_sendto+0x113/0x170 __x64_sys_sendto+0x20/0x30 do_syscall_64+0x40/0xe0 entry_SYSCALL_64_after_hwframe+0x46/0x4e other info that might help us debug this: Possible unsafe locking scenario: CPU0CPU1 -------- lock(&priv->state_lock); lock((work_completion)(&rule->arfs_work)); lock(&priv->state_lock); lock((work_completion)(&rule->arfs_work)); *** DEADLOCK *** 3 locks held by ethtool/386089: #0: ffffffff82ea7210 (cb_lock){++++}-{3:3}, at: genl_rcv+0x15/0x40 #1: ffffffff82e94c88 (rtnl_mutex){+.+.}-{3:3}, at: ethnl_default_set_doit+0xd3/0x240 #2: ffff8884a1808cc0 (&priv->state_lock){+.+.}-{3:3}, at: mlx5e_ethtool_set_channels+0x53/0x200 [mlx5_core] stack backtrace: CPU: 15 PID: 386089 Comm: ethtool Tainted: GI6.7.0-rc4_net_next_mlx5_5483eb2 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x60/0xa0 check_noncircular+0x144/0x160 __lock_acquire+0x17b4/0x2c80 lock_acquire+0xd0/0x2b0 ? __flush_work+0x74/0x4e0 ? save_trace+0x3e/0x360 ? __flush_work+0x74/0x4e0 __flush_work+0x7a/0x4e0 ? __flush_work+0x74/0x4e0 ? __lock_acquire+0xa78/0x2c80 ? lock_acquire+0xd0/0x2b0 ? mark_held_locks+0x49/0x70 __cancel_work_timer+0x131/0x1c0 ? mark_held_locks+0x49/0x70 arfs_del_rules+0x143/0x1e0 [mlx5_core] mlx5e_arfs_disable+0x1b/0x30 [mlx5_core] mlx5e_ethtool_set_channels+0xcb/0x200 [mlx5_core] ethnl_set_channels+0x28f/0x3b0 ethnl_default_set_doit+0xec/0x240 genl_family_rcv_msg_doit+0xd0/0x120 genl_rcv_msg+0x188/0x2c0 ? ethn ---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-2024-27014 CVE - 2024-27014 EulerOS-SA-2024-1964

Red Hat: CVE-2024-27015: kernel: netfilter: flowtable: incorrect pppoe tuple (Multiple Advisories) Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 05/01/2024 Created 12/06/2024 Added 12/05/2024 Modified 12/05/2024 Description In the Linux kernel, the following vulnerability has been resolved: netfilter: flowtable: incorrect pppoe tuple pppoe traffic reaching ingress path does not match the flowtable entry because the pppoe header is expected to be at the network header offset. This bug causes a mismatch in the flow table lookup, so pppoe packets enter the classical forwarding path. Solution(s) redhat-upgrade-kernel redhat-upgrade-kernel-rt References CVE-2024-27015 RHSA-2024:9315

Red Hat: CVE-2024-26961: kernel: mac802154: fix llsec key resources release in mac802154_llsec_key_del (Multiple Advisories) Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 05/01/2024 Created 08/13/2024 Added 08/12/2024 Modified 02/10/2025 Description In the Linux kernel, the following vulnerability has been resolved: mac802154: fix llsec key resources release in mac802154_llsec_key_del mac802154_llsec_key_del() can free resources of a key directly without following the RCU rules for waiting before the end of a grace period. This may lead to use-after-free in case llsec_lookup_key() is traversing the list of keys in parallel with a key deletion: refcount_t: addition on 0; use-after-free. WARNING: CPU: 4 PID: 16000 at lib/refcount.c:25 refcount_warn_saturate+0x162/0x2a0 Modules linked in: CPU: 4 PID: 16000 Comm: wpan-ping Not tainted 6.7.0 #19 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014 RIP: 0010:refcount_warn_saturate+0x162/0x2a0 Call Trace: <TASK> llsec_lookup_key.isra.0+0x890/0x9e0 mac802154_llsec_encrypt+0x30c/0x9c0 ieee802154_subif_start_xmit+0x24/0x1e0 dev_hard_start_xmit+0x13e/0x690 sch_direct_xmit+0x2ae/0xbc0 __dev_queue_xmit+0x11dd/0x3c20 dgram_sendmsg+0x90b/0xd60 __sys_sendto+0x466/0x4c0 __x64_sys_sendto+0xe0/0x1c0 do_syscall_64+0x45/0xf0 entry_SYSCALL_64_after_hwframe+0x6e/0x76 Also, ieee802154_llsec_key_entry structures are not freed by mac802154_llsec_key_del(): unreferenced object 0xffff8880613b6980 (size 64): comm "iwpan", pid 2176, jiffies 4294761134 (age 60.475s) hex dump (first 32 bytes): 78 0d 8f 18 80 88 ff ff 22 01 00 00 00 00 ad dex......."....... 00 00 00 00 00 00 00 00 03 00 cd ab 00 00 00 00................ backtrace: [<ffffffff81dcfa62>] __kmem_cache_alloc_node+0x1e2/0x2d0 [<ffffffff81c43865>] kmalloc_trace+0x25/0xc0 [<ffffffff88968b09>] mac802154_llsec_key_add+0xac9/0xcf0 [<ffffffff8896e41a>] ieee802154_add_llsec_key+0x5a/0x80 [<ffffffff8892adc6>] nl802154_add_llsec_key+0x426/0x5b0 [<ffffffff86ff293e>] genl_family_rcv_msg_doit+0x1fe/0x2f0 [<ffffffff86ff46d1>] genl_rcv_msg+0x531/0x7d0 [<ffffffff86fee7a9>] netlink_rcv_skb+0x169/0x440 [<ffffffff86ff1d88>] genl_rcv+0x28/0x40 [<ffffffff86fec15c>] netlink_unicast+0x53c/0x820 [<ffffffff86fecd8b>] netlink_sendmsg+0x93b/0xe60 [<ffffffff86b91b35>] ____sys_sendmsg+0xac5/0xca0 [<ffffffff86b9c3dd>] ___sys_sendmsg+0x11d/0x1c0 [<ffffffff86b9c65a>] __sys_sendmsg+0xfa/0x1d0 [<ffffffff88eadbf5>] do_syscall_64+0x45/0xf0 [<ffffffff890000ea>] entry_SYSCALL_64_after_hwframe+0x6e/0x76 Handle the proper resource release in the RCU callback function mac802154_llsec_key_del_rcu(). Note that if llsec_lookup_key() finds a key, it gets a refcount via llsec_key_get() and locally copies key id from key_entry (which is a list element). So it's safe to call llsec_key_put() and free the list entry after the RCU grace period elapses. Found by Linux Verification Center (linuxtesting.org). Solution(s) redhat-upgrade-kernel redhat-upgrade-kernel-rt References CVE-2024-26961 RHSA-2024:10262 RHSA-2024:5101 RHSA-2024:5102 RHSA-2024:8613 RHSA-2024:8614 RHSA-2024:8617 View more

Red Hat: CVE-2024-26960: kernel: mm: swap: fix race between free_swap_and_cache() and swapoff() (Multiple Advisories) Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 05/01/2024 Created 08/13/2024 Added 08/12/2024 Modified 12/05/2024 Description In the Linux kernel, the following vulnerability has been resolved: mm: swap: fix race between free_swap_and_cache() and swapoff() There was previously a theoretical window where swapoff() could run and teardown a swap_info_struct while a call to free_swap_and_cache() was running in another thread.This could cause, amongst other bad possibilities, swap_page_trans_huge_swapped() (called by free_swap_and_cache()) to access the freed memory for swap_map. This is a theoretical problem and I haven't been able to provoke it from a test case.But there has been agreement based on code review that this is possible (see link below). Fix it by using get_swap_device()/put_swap_device(), which will stall swapoff().There was an extra check in _swap_info_get() to confirm that the swap entry was not free.This isn't present in get_swap_device() because it doesn't make sense in general due to the race between getting the reference and swapoff.So I've added an equivalent check directly in free_swap_and_cache(). Details of how to provoke one possible issue (thanks to David Hildenbrand for deriving this): --8<----- __swap_entry_free() might be the last user and result in "count == SWAP_HAS_CACHE". swapoff->try_to_unuse() will stop as soon as soon as si->inuse_pages==0. So the question is: could someone reclaim the folio and turn si->inuse_pages==0, before we completed swap_page_trans_huge_swapped(). Imagine the following: 2 MiB folio in the swapcache. Only 2 subpages are still references by swap entries. Process 1 still references subpage 0 via swap entry. Process 2 still references subpage 1 via swap entry. Process 1 quits. Calls free_swap_and_cache(). -> count == SWAP_HAS_CACHE [then, preempted in the hypervisor etc.] Process 2 quits. Calls free_swap_and_cache(). -> count == SWAP_HAS_CACHE Process 2 goes ahead, passes swap_page_trans_huge_swapped(), and calls __try_to_reclaim_swap(). __try_to_reclaim_swap()->folio_free_swap()->delete_from_swap_cache()-> put_swap_folio()->free_swap_slot()->swapcache_free_entries()-> swap_entry_free()->swap_range_free()-> ... WRITE_ONCE(si->inuse_pages, si->inuse_pages - nr_entries); What stops swapoff to succeed after process 2 reclaimed the swap cache but before process1 finished its call to swap_page_trans_huge_swapped()? --8<----- Solution(s) redhat-upgrade-kernel redhat-upgrade-kernel-rt References CVE-2024-26960 RHSA-2024:5101 RHSA-2024:5102 RHSA-2024:9315

Huawei EulerOS: CVE-2024-26934: kernel security update Severity 7 CVSS (AV:L/AC:L/Au:S/C:C/I:C/A:C) Published 05/01/2024 Created 07/17/2024 Added 07/17/2024 Modified 01/30/2025 Description In the Linux kernel, the following vulnerability has been resolved: USB: core: Fix deadlock in usb_deauthorize_interface() Among the attribute file callback routines in drivers/usb/core/sysfs.c, the interface_authorized_store() function is the only one which acquires a device lock on an ancestor device: It calls usb_deauthorize_interface(), which locks the interface's parent USB device. The will lead to deadlock if another process already owns that lock and tries to remove the interface, whether through a configuration change or because the device has been disconnected.As part of the removal procedure, device_del() waits for all ongoing sysfs attribute callbacks to complete.But usb_deauthorize_interface() can't complete until the device lock has been released, and the lock won't be released until the removal has finished. The mechanism provided by sysfs to prevent this kind of deadlock is to use the sysfs_break_active_protection() function, which tells sysfs not to wait for the attribute callback. Reported-and-tested by: Yue Sun <[email protected]> Reported by: xingwei lee <[email protected]> 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-2024-26934 CVE - 2024-26934 EulerOS-SA-2024-1964

Huawei EulerOS: CVE-2024-27075: kernel security update Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 05/01/2024 Created 07/17/2024 Added 07/17/2024 Modified 07/17/2024 Description In the Linux kernel, the following vulnerability has been resolved: media: dvb-frontends: avoid stack overflow warnings with clang A previous patch worked around a KASAN issue in stv0367, now a similar problem showed up with clang: drivers/media/dvb-frontends/stv0367.c:1222:12: error: stack frame size (3624) exceeds limit (2048) in 'stv0367ter_set_frontend' [-Werror,-Wframe-larger-than] 1214 | static int stv0367ter_set_frontend(struct dvb_frontend *fe) Rework the stv0367_writereg() function to be simpler and mark both register access functions as noinline_for_stack so the temporary i2c_msg structures do not get duplicated on the stack when KASAN_STACK is enabled. 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-2024-27075 CVE - 2024-27075 EulerOS-SA-2024-1964

Red Hat: CVE-2023-52651: kernel: wifi: ath10k: fix NULL pointer dereference in ath10k_wmi_tlv_op_pull_mgmt_tx_compl_ev() (Multiple Advisories) Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 05/01/2024 Created 09/14/2024 Added 09/13/2024 Modified 12/05/2024 Description Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority. Solution(s) redhat-upgrade-kernel redhat-upgrade-kernel-rt References CVE-2023-52651 RHSA-2024:5363 RHSA-2024:5364 RHSA-2024:5365

Red Hat: CVE-2024-26951: kernel: wireguard: netlink: check for dangling peer via is_dead instead of empty list (Multiple Advisories) Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 05/01/2024 Created 12/06/2024 Added 12/05/2024 Modified 12/05/2024 Description In the Linux kernel, the following vulnerability has been resolved: wireguard: netlink: check for dangling peer via is_dead instead of empty list If all peers are removed via wg_peer_remove_all(), rather than setting peer_list to empty, the peer is added to a temporary list with a head on the stack of wg_peer_remove_all(). If a netlink dump is resumed and the cursored peer is one that has been removed via wg_peer_remove_all(), it will iterate from that peer and then attempt to dump freed peers. Fix this by instead checking peer->is_dead, which was explictly created for this purpose. Also move up the device_update_lock lockdep assertion, since reading is_dead relies on that. It can be reproduced by a small script like: echo "Setting config..." ip link add dev wg0 type wireguard wg setconf wg0 /big-config ( while true; do echo "Showing config..." wg showconf wg0 > /dev/null done ) & sleep 4 wg setconf wg0 <(printf "[Peer]\nPublicKey=$(wg genkey)\n") Resulting in: BUG: KASAN: slab-use-after-free in __lock_acquire+0x182a/0x1b20 Read of size 8 at addr ffff88811956ec70 by task wg/59 CPU: 2 PID: 59 Comm: wg Not tainted 6.8.0-rc2-debug+ #5 Call Trace: <TASK> dump_stack_lvl+0x47/0x70 print_address_description.constprop.0+0x2c/0x380 print_report+0xab/0x250 kasan_report+0xba/0xf0 __lock_acquire+0x182a/0x1b20 lock_acquire+0x191/0x4b0 down_read+0x80/0x440 get_peer+0x140/0xcb0 wg_get_device_dump+0x471/0x1130 Solution(s) redhat-upgrade-kernel redhat-upgrade-kernel-rt References CVE-2024-26951 RHSA-2024:9315

Huawei EulerOS: CVE-2024-27073: kernel security update Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 05/01/2024 Created 07/17/2024 Added 07/17/2024 Modified 07/17/2024 Description In the Linux kernel, the following vulnerability has been resolved: media: ttpci: fix two memleaks in budget_av_attach When saa7146_register_device and saa7146_vv_init fails, budget_av_attach should free the resources it allocates, like the error-handling of ttpci_budget_init does. Besides, there are two fixme comment refers to such deallocations. 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-2024-27073 CVE - 2024-27073 EulerOS-SA-2024-1964

Red Hat: CVE-2024-27017: kernel: netfilter: nft_set_pipapo: walk over current view on netlink dump (Multiple Advisories) Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 05/01/2024 Created 11/07/2024 Added 11/06/2024 Modified 12/05/2024 Description In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_set_pipapo: walk over current view on netlink dump The generation mask can be updated while netlink dump is in progress. The pipapo set backend walk iterator cannot rely on it to infer what view of the datastructure is to be used. Add notation to specify if user wants to read/update the set. Based on patch from Florian Westphal. Solution(s) redhat-upgrade-kernel redhat-upgrade-kernel-rt References CVE-2024-27017 RHSA-2024:8856 RHSA-2024:8870 RHSA-2024:9315

Amazon Linux AMI: CVE-2024-27020: Security patch for kernel (ALAS-2024-1942) Severity 7 CVSS (AV:L/AC:M/Au:S/C:C/I:C/A:C) Published 05/01/2024 Created 08/03/2024 Added 08/01/2024 Modified 01/28/2025 Description In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: Fix potential data-race in __nft_expr_type_get() nft_unregister_expr() can concurrent with __nft_expr_type_get(), and there is not any protection when iterate over nf_tables_expressions list in __nft_expr_type_get(). Therefore, there is potential data-race of nf_tables_expressions list entry. Use list_for_each_entry_rcu() to iterate over nf_tables_expressions list in __nft_expr_type_get(), and use rcu_read_lock() in the caller nft_expr_type_get() to protect the entire type query process. Solution(s) amazon-linux-upgrade-kernel References ALAS-2024-1942 CVE-2024-27020