ISHACK AI BOT

Oracle Linux: CVE-2024-27062: ELSA-2024-8856:kernel security update (MODERATE) (Multiple Advisories) Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 05/01/2024 Created 11/13/2024 Added 11/11/2024 Modified 01/07/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) oracle-linux-upgrade-kernel References https://attackerkb.com/topics/cve-2024-27062 CVE - 2024-27062 ELSA-2024-8856

Oracle Linux: CVE-2024-26987: ELSA-2024-12815: Unbreakable Enterprise kernel security update (IMPORTANT) (Multiple Advisories) Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 05/01/2024 Created 11/23/2024 Added 11/21/2024 Modified 01/23/2025 Description In the Linux kernel, the following vulnerability has been resolved: mm/memory-failure: fix deadlock when hugetlb_optimize_vmemmap is enabled When I did hard offline test with hugetlb pages, below deadlock occurs: ====================================================== WARNING: possible circular locking dependency detected 6.8.0-11409-gf6cef5f8c37f #1 Not tainted ------------------------------------------------------ bash/46904 is trying to acquire lock: ffffffffabe68910 (cpu_hotplug_lock){++++}-{0:0}, at: static_key_slow_dec+0x16/0x60 but task is already holding lock: ffffffffabf92ea8 (pcp_batch_high_lock){+.+.}-{3:3}, at: zone_pcp_disable+0x16/0x40 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (pcp_batch_high_lock){+.+.}-{3:3}: __mutex_lock+0x6c/0x770 page_alloc_cpu_online+0x3c/0x70 cpuhp_invoke_callback+0x397/0x5f0 __cpuhp_invoke_callback_range+0x71/0xe0 _cpu_up+0xeb/0x210 cpu_up+0x91/0xe0 cpuhp_bringup_mask+0x49/0xb0 bringup_nonboot_cpus+0xb7/0xe0 smp_init+0x25/0xa0 kernel_init_freeable+0x15f/0x3e0 kernel_init+0x15/0x1b0 ret_from_fork+0x2f/0x50 ret_from_fork_asm+0x1a/0x30 -> #0 (cpu_hotplug_lock){++++}-{0:0}: __lock_acquire+0x1298/0x1cd0 lock_acquire+0xc0/0x2b0 cpus_read_lock+0x2a/0xc0 static_key_slow_dec+0x16/0x60 __hugetlb_vmemmap_restore_folio+0x1b9/0x200 dissolve_free_huge_page+0x211/0x260 __page_handle_poison+0x45/0xc0 memory_failure+0x65e/0xc70 hard_offline_page_store+0x55/0xa0 kernfs_fop_write_iter+0x12c/0x1d0 vfs_write+0x387/0x550 ksys_write+0x64/0xe0 do_syscall_64+0xca/0x1e0 entry_SYSCALL_64_after_hwframe+0x6d/0x75 other info that might help us debug this: Possible unsafe locking scenario: CPU0CPU1 -------- lock(pcp_batch_high_lock); lock(cpu_hotplug_lock); lock(pcp_batch_high_lock); rlock(cpu_hotplug_lock); *** DEADLOCK *** 5 locks held by bash/46904: #0: ffff98f6c3bb23f0 (sb_writers#5){.+.+}-{0:0}, at: ksys_write+0x64/0xe0 #1: ffff98f6c328e488 (&of->mutex){+.+.}-{3:3}, at: kernfs_fop_write_iter+0xf8/0x1d0 #2: ffff98ef83b31890 (kn->active#113){.+.+}-{0:0}, at: kernfs_fop_write_iter+0x100/0x1d0 #3: ffffffffabf9db48 (mf_mutex){+.+.}-{3:3}, at: memory_failure+0x44/0xc70 #4: ffffffffabf92ea8 (pcp_batch_high_lock){+.+.}-{3:3}, at: zone_pcp_disable+0x16/0x40 stack backtrace: CPU: 10 PID: 46904 Comm: bash Kdump: loaded Not tainted 6.8.0-11409-gf6cef5f8c37f #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x68/0xa0 check_noncircular+0x129/0x140 __lock_acquire+0x1298/0x1cd0 lock_acquire+0xc0/0x2b0 cpus_read_lock+0x2a/0xc0 static_key_slow_dec+0x16/0x60 __hugetlb_vmemmap_restore_folio+0x1b9/0x200 dissolve_free_huge_page+0x211/0x260 __page_handle_poison+0x45/0xc0 memory_failure+0x65e/0xc70 hard_offline_page_store+0x55/0xa0 kernfs_fop_write_iter+0x12c/0x1d0 vfs_write+0x387/0x550 ksys_write+0x64/0xe0 do_syscall_64+0xca/0x1e0 entry_SYSCALL_64_after_hwframe+0x6d/0x75 RIP: 0033:0x7fc862314887 Code: 10 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 51 c3 48 83 ec 28 48 89 54 24 18 48 89 74 24 RSP: 002b:00007fff19311268 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 000000000000000c RCX: 00007fc862314887 RDX: 000000000000000c RSI: 000056405645fe10 RDI: 0000000000000001 RBP: 000056405645fe10 R08: 00007fc8623d1460 R09: 000000007fffffff R10: 0000000000000000 R11: 0000000000000246 R12: 000000000000000c R13: 00007fc86241b780 R14: 00007fc862417600 R15: 00007fc862416a00 In short, below scene breaks the ---truncated--- Solution(s) oracle-linux-upgrade-kernel-uek References https://attackerkb.com/topics/cve-2024-26987 CVE - 2024-26987 ELSA-2024-12815

Oracle Linux: CVE-2024-26993: 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 12/06/2024 Description In the Linux kernel, the following vulnerability has been resolved: fs: sysfs: Fix reference leak in sysfs_break_active_protection() The sysfs_break_active_protection() routine has an obvious reference leak in its error path.If the call to kernfs_find_and_get() fails then kn will be NULL, so the companion sysfs_unbreak_active_protection() routine won't get called (and would only cause an access violation by trying to dereference kn->parent if it was called).As a result, the reference to kobj acquired at the start of the function will never be released. Fix the leak by adding an explicit kobject_put() call when kn is NULL. Solution(s) oracle-linux-upgrade-kernel References https://attackerkb.com/topics/cve-2024-26993 CVE - 2024-26993 ELSA-2024-3618 ELSA-2024-3619

Red Hat: CVE-2024-26987: kernel: mm/memory-failure: fix deadlock when hugetlb_optimize_vmemmap is enabled (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: mm/memory-failure: fix deadlock when hugetlb_optimize_vmemmap is enabled When I did hard offline test with hugetlb pages, below deadlock occurs: ====================================================== WARNING: possible circular locking dependency detected 6.8.0-11409-gf6cef5f8c37f #1 Not tainted ------------------------------------------------------ bash/46904 is trying to acquire lock: ffffffffabe68910 (cpu_hotplug_lock){++++}-{0:0}, at: static_key_slow_dec+0x16/0x60 but task is already holding lock: ffffffffabf92ea8 (pcp_batch_high_lock){+.+.}-{3:3}, at: zone_pcp_disable+0x16/0x40 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (pcp_batch_high_lock){+.+.}-{3:3}: __mutex_lock+0x6c/0x770 page_alloc_cpu_online+0x3c/0x70 cpuhp_invoke_callback+0x397/0x5f0 __cpuhp_invoke_callback_range+0x71/0xe0 _cpu_up+0xeb/0x210 cpu_up+0x91/0xe0 cpuhp_bringup_mask+0x49/0xb0 bringup_nonboot_cpus+0xb7/0xe0 smp_init+0x25/0xa0 kernel_init_freeable+0x15f/0x3e0 kernel_init+0x15/0x1b0 ret_from_fork+0x2f/0x50 ret_from_fork_asm+0x1a/0x30 -> #0 (cpu_hotplug_lock){++++}-{0:0}: __lock_acquire+0x1298/0x1cd0 lock_acquire+0xc0/0x2b0 cpus_read_lock+0x2a/0xc0 static_key_slow_dec+0x16/0x60 __hugetlb_vmemmap_restore_folio+0x1b9/0x200 dissolve_free_huge_page+0x211/0x260 __page_handle_poison+0x45/0xc0 memory_failure+0x65e/0xc70 hard_offline_page_store+0x55/0xa0 kernfs_fop_write_iter+0x12c/0x1d0 vfs_write+0x387/0x550 ksys_write+0x64/0xe0 do_syscall_64+0xca/0x1e0 entry_SYSCALL_64_after_hwframe+0x6d/0x75 other info that might help us debug this: Possible unsafe locking scenario: CPU0CPU1 -------- lock(pcp_batch_high_lock); lock(cpu_hotplug_lock); lock(pcp_batch_high_lock); rlock(cpu_hotplug_lock); *** DEADLOCK *** 5 locks held by bash/46904: #0: ffff98f6c3bb23f0 (sb_writers#5){.+.+}-{0:0}, at: ksys_write+0x64/0xe0 #1: ffff98f6c328e488 (&of->mutex){+.+.}-{3:3}, at: kernfs_fop_write_iter+0xf8/0x1d0 #2: ffff98ef83b31890 (kn->active#113){.+.+}-{0:0}, at: kernfs_fop_write_iter+0x100/0x1d0 #3: ffffffffabf9db48 (mf_mutex){+.+.}-{3:3}, at: memory_failure+0x44/0xc70 #4: ffffffffabf92ea8 (pcp_batch_high_lock){+.+.}-{3:3}, at: zone_pcp_disable+0x16/0x40 stack backtrace: CPU: 10 PID: 46904 Comm: bash Kdump: loaded Not tainted 6.8.0-11409-gf6cef5f8c37f #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x68/0xa0 check_noncircular+0x129/0x140 __lock_acquire+0x1298/0x1cd0 lock_acquire+0xc0/0x2b0 cpus_read_lock+0x2a/0xc0 static_key_slow_dec+0x16/0x60 __hugetlb_vmemmap_restore_folio+0x1b9/0x200 dissolve_free_huge_page+0x211/0x260 __page_handle_poison+0x45/0xc0 memory_failure+0x65e/0xc70 hard_offline_page_store+0x55/0xa0 kernfs_fop_write_iter+0x12c/0x1d0 vfs_write+0x387/0x550 ksys_write+0x64/0xe0 do_syscall_64+0xca/0x1e0 entry_SYSCALL_64_after_hwframe+0x6d/0x75 RIP: 0033:0x7fc862314887 Code: 10 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 51 c3 48 83 ec 28 48 89 54 24 18 48 89 74 24 RSP: 002b:00007fff19311268 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 000000000000000c RCX: 00007fc862314887 RDX: 000000000000000c RSI: 000056405645fe10 RDI: 0000000000000001 RBP: 000056405645fe10 R08: 00007fc8623d1460 R09: 000000007fffffff R10: 0000000000000000 R11: 0000000000000246 R12: 000000000000000c R13: 00007fc86241b780 R14: 00007fc862417600 R15: 00007fc862416a00 In short, below scene breaks the ---truncated--- Solution(s) redhat-upgrade-kernel redhat-upgrade-kernel-rt References CVE-2024-26987 RHSA-2024:9315

Ubuntu: (Multiple Advisories) (CVE-2024-27008): Linux kernel vulnerabilities Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 05/01/2024 Created 07/12/2024 Added 07/12/2024 Modified 09/20/2024 Description In the Linux kernel, the following vulnerability has been resolved: drm: nv04: Fix out of bounds access When Output Resource (dcb->or) value is assigned in fabricate_dcb_output(), there may be out of bounds access to dac_users array in case dcb->or is zero because ffs(dcb->or) is used as index there. The 'or' argument of fabricate_dcb_output() must be interpreted as a number of bit to set, not value. Utilize macros from 'enum nouveau_or' in calls instead of hardcoding. Found by Linux Verification Center (linuxtesting.org) with SVACE. 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-1006-gke ubuntu-upgrade-linux-image-6-8-0-1007-intel ubuntu-upgrade-linux-image-6-8-0-1007-raspi ubuntu-upgrade-linux-image-6-8-0-1008-ibm ubuntu-upgrade-linux-image-6-8-0-1008-oem ubuntu-upgrade-linux-image-6-8-0-1008-oracle ubuntu-upgrade-linux-image-6-8-0-1008-oracle-64k ubuntu-upgrade-linux-image-6-8-0-1009-nvidia ubuntu-upgrade-linux-image-6-8-0-1009-nvidia-64k ubuntu-upgrade-linux-image-6-8-0-1010-azure ubuntu-upgrade-linux-image-6-8-0-1010-azure-fde ubuntu-upgrade-linux-image-6-8-0-1010-gcp ubuntu-upgrade-linux-image-6-8-0-1011-aws ubuntu-upgrade-linux-image-6-8-0-38-generic ubuntu-upgrade-linux-image-6-8-0-38-generic-64k ubuntu-upgrade-linux-image-6-8-0-38-lowlatency ubuntu-upgrade-linux-image-6-8-0-38-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-64k 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-27008 CVE - 2024-27008 USN-6893-1 USN-6893-2 USN-6893-3 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-6918-1 USN-6919-1 USN-6927-1 USN-7019-1 View more

SUSE: CVE-2024-27056: SUSE Linux Security Advisory Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 05/01/2024 Created 05/15/2024 Added 05/15/2024 Modified 08/28/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) 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-2024-27056 CVE - 2024-27056

SUSE: CVE-2024-27078: SUSE Linux Security Advisory Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 05/01/2024 Created 05/15/2024 Added 05/15/2024 Modified 01/28/2025 Description In the Linux kernel, the following vulnerability has been resolved: media: v4l2-tpg: fix some memleaks in tpg_alloc In tpg_alloc, resources should be deallocated in each and every error-handling paths, since they are allocated in for statements. Otherwise there would be memleaks because tpg_free is called only when tpg_alloc return 0. 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-base suse-upgrade-kernel-azure-devel suse-upgrade-kernel-azure-extra suse-upgrade-kernel-azure-livepatch-devel suse-upgrade-kernel-azure-optional suse-upgrade-kernel-azure-vdso suse-upgrade-kernel-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-man 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-2024-27078 CVE - 2024-27078

SUSE: CVE-2024-27080: SUSE Linux Security Advisory Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 05/01/2024 Created 06/24/2024 Added 06/24/2024 Modified 08/28/2024 Description In the Linux kernel, the following vulnerability has been resolved: btrfs: fix race when detecting delalloc ranges during fiemap For fiemap we recently stopped locking the target extent range for the whole duration of the fiemap call, in order to avoid a deadlock in a scenario where the fiemap buffer happens to be a memory mapped range of the same file. This use case is very unlikely to be useful in practice but it may be triggered by fuzz testing (syzbot, etc). This however introduced a race that makes us miss delalloc ranges for file regions that are currently holes, so the caller of fiemap will not be aware that there's data for some file regions. This can be quite serious for some use cases - for example in coreutils versions before 9.0, the cp program used fiemap to detect holes and data in the source file, copying only regions with data (extents or delalloc) from the source file to the destination file in order to preserve holes (see the documentation for its --sparse command line option). This means that if cp was used with a source file that had delalloc in a hole, the destination file could end up without that data, which is effectively a data loss issue, if it happened to hit the race described below. The race happens like this: 1) Fiemap is called, without the FIEMAP_FLAG_SYNC flag, for a file that has delalloc in the file range [64M, 65M[, which is currently a hole; 2) Fiemap locks the inode in shared mode, then starts iterating the inode's subvolume tree searching for file extent items, without having the whole fiemap target range locked in the inode's io tree - the change introduced recently by commit b0ad381fa769 ("btrfs: fix deadlock with fiemap and extent locking"). It only locks ranges in the io tree when it finds a hole or prealloc extent since that commit; 3) Note that fiemap clones each leaf before using it, and this is to avoid deadlocks when locking a file range in the inode's io tree and the fiemap buffer is memory mapped to some file, because writing to the page with btrfs_page_mkwrite() will wait on any ordered extent for the page's range and the ordered extent needs to lock the range and may need to modify the same leaf, therefore leading to a deadlock on the leaf; 4) While iterating the file extent items in the cloned leaf before finding the hole in the range [64M, 65M[, the delalloc in that range is flushed and its ordered extent completes - meaning the corresponding file extent item is in the inode's subvolume tree, but not present in the cloned leaf that fiemap is iterating over; 5) When fiemap finds the hole in the [64M, 65M[ range by seeing the gap in the cloned leaf (or a file extent item with disk_bytenr == 0 in case the NO_HOLES feature is not enabled), it will lock that file range in the inode's io tree and then search for delalloc by checking for the EXTENT_DELALLOC bit in the io tree for that range and ordered extents (with btrfs_find_delalloc_in_range()). But it finds nothing since the delalloc in that range was already flushed and the ordered extent completed and is gone - as a result fiemap will not report that there's delalloc or an extent for the range [64M, 65M[, so user space will be mislead into thinking that there's a hole in that range. This could actually be sporadically triggered with test case generic/094 from fstests, which reports a missing extent/delalloc range like this: generic/094 2s ... - output mismatch (see /home/fdmanana/git/hub/xfstests/results//generic/094.out.bad) --- tests/generic/094.out 2020-06-10 19:29:03.830519425 +0100 +++ /home/fdmanana/git/hub/xfstests/results//generic/094.out.bad 2024-02-28 11:00:00.381071525 +0000 @@ -1,3 +1,9 @@ QA output created by 094 fiemap run with sync fiemap run without sync +ERROR: couldn't find extent at 7 +map is 'HHDDHPPDPHPH' +logical: [ 5.. 6] phys: ---truncated--- 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-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-2024-27080 CVE - 2024-27080

Amazon Linux AMI 2: CVE-2024-26950: Security patch for kernel (Multiple Advisories) Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 05/01/2024 Created 08/14/2024 Added 08/14/2024 Modified 08/14/2024 Description In the Linux kernel, the following vulnerability has been resolved: wireguard: netlink: access device through ctx instead of peer The previous commit fixed a bug that led to a NULL peer->device being dereferenced. It's actually easier and faster performance-wise to instead get the device from ctx->wg. This semantically makes more sense too, since ctx->wg->peer_allowedips.seq is compared with ctx->allowedips_seq, basing them both in ctx. This also acts as a defence in depth provision against freed peers. 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-livepatch-5-10-215-203-850 amazon-linux-ami-2-upgrade-kernel-livepatch-5-15-156-102-160 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-2024-26950 AL2/ALASKERNEL-5.10-2024-068 AL2/ALASKERNEL-5.15-2024-049 CVE - 2024-26950

Amazon Linux AMI 2: CVE-2024-26958: Security patch for kernel (Multiple Advisories) Severity 7 CVSS (AV:L/AC:L/Au:S/C:C/I:C/A:C) Published 05/01/2024 Created 08/14/2024 Added 08/14/2024 Modified 01/30/2025 Description In the Linux kernel, the following vulnerability has been resolved: nfs: fix UAF in direct writes In production we have been hitting the following warning consistently ------------[ cut here ]------------ refcount_t: underflow; use-after-free. WARNING: CPU: 17 PID: 1800359 at lib/refcount.c:28 refcount_warn_saturate+0x9c/0xe0 Workqueue: nfsiod nfs_direct_write_schedule_work [nfs] RIP: 0010:refcount_warn_saturate+0x9c/0xe0 PKRU: 55555554 Call Trace: <TASK> ? __warn+0x9f/0x130 ? refcount_warn_saturate+0x9c/0xe0 ? report_bug+0xcc/0x150 ? handle_bug+0x3d/0x70 ? exc_invalid_op+0x16/0x40 ? asm_exc_invalid_op+0x16/0x20 ? refcount_warn_saturate+0x9c/0xe0 nfs_direct_write_schedule_work+0x237/0x250 [nfs] process_one_work+0x12f/0x4a0 worker_thread+0x14e/0x3b0 ? ZSTD_getCParams_internal+0x220/0x220 kthread+0xdc/0x120 ? __btf_name_valid+0xa0/0xa0 ret_from_fork+0x1f/0x30 This is because we're completing the nfs_direct_request twice in a row. The source of this is when we have our commit requests to submit, we process them and send them off, and then in the completion path for the commit requests we have if (nfs_commit_end(cinfo.mds)) nfs_direct_write_complete(dreq); However since we're submitting asynchronous requests we sometimes have one that completes before we submit the next one, so we end up calling complete on the nfs_direct_request twice. The only other place we use nfs_generic_commit_list() is in __nfs_commit_inode, which wraps this call in a nfs_commit_begin(); nfs_commit_end(); Which is a common pattern for this style of completion handling, one that is also repeated in the direct code with get_dreq()/put_dreq() calls around where we process events as well as in the completion paths. Fix this by using the same pattern for the commit requests. Before with my 200 node rocksdb stress running this warning would pop every 10ish minutes.With my patch the stress test has been running for several hours without popping. 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-livepatch-5-10-215-203-850 amazon-linux-ami-2-upgrade-kernel-livepatch-5-15-156-102-160 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-2024-26958 AL2/ALASKERNEL-5.10-2024-068 AL2/ALASKERNEL-5.15-2024-049 CVE - 2024-26958

Amazon Linux AMI 2: CVE-2024-26960: Security patch for kernel (Multiple Advisories) Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 05/01/2024 Created 08/14/2024 Added 08/14/2024 Modified 08/14/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) 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-livepatch-5-10-215-203-850 amazon-linux-ami-2-upgrade-kernel-livepatch-5-15-156-102-160 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-2024-26960 AL2/ALASKERNEL-5.10-2024-068 AL2/ALASKERNEL-5.15-2024-049 CVE - 2024-26960

Amazon Linux AMI 2: CVE-2024-26964: Security patch for kernel (ALASKERNEL-5.15-2024-049) Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 05/01/2024 Created 08/14/2024 Added 08/14/2024 Modified 01/28/2025 Description In the Linux kernel, the following vulnerability has been resolved: usb: xhci: Add error handling in xhci_map_urb_for_dma Currently xhci_map_urb_for_dma() creates a temporary buffer and copies the SG list to the new linear buffer. But if the kzalloc_node() fails, then the following sg_pcopy_to_buffer() can lead to crash since it tries to memcpy to NULL pointer. So return -ENOMEM if kzalloc returns null pointer. 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-livepatch-5-15-156-102-160 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-2024-26964 AL2/ALASKERNEL-5.15-2024-049 CVE - 2024-26964

Amazon Linux AMI 2: CVE-2024-26973: Security patch for kernel (ALAS-2024-2615) Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 05/01/2024 Created 12/13/2024 Added 12/12/2024 Modified 12/12/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) 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-livepatch-4-14-345-262-561 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-2024-26973 AL2/ALAS-2024-2615 CVE - 2024-26973

SUSE: CVE-2024-27388: SUSE Linux Security Advisory Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 05/01/2024 Created 05/15/2024 Added 05/15/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) 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-base suse-upgrade-kernel-azure-devel suse-upgrade-kernel-azure-extra suse-upgrade-kernel-azure-livepatch-devel suse-upgrade-kernel-azure-optional suse-upgrade-kernel-azure-vdso suse-upgrade-kernel-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-man 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-2024-27388 CVE - 2024-27388

SUSE: CVE-2024-27027: SUSE Linux Security Advisory Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 05/01/2024 Created 06/24/2024 Added 06/24/2024 Modified 08/28/2024 Description In the Linux kernel, the following vulnerability has been resolved: dpll: fix dpll_xa_ref_*_del() for multiple registrations Currently, if there are multiple registrations of the same pin on the same dpll device, following warnings are observed: WARNING: CPU: 5 PID: 2212 at drivers/dpll/dpll_core.c:143 dpll_xa_ref_pin_del.isra.0+0x21e/0x230 WARNING: CPU: 5 PID: 2212 at drivers/dpll/dpll_core.c:223 __dpll_pin_unregister+0x2b3/0x2c0 The problem is, that in both dpll_xa_ref_dpll_del() and dpll_xa_ref_pin_del() registration is only removed from list in case the reference count drops to zero. That is wrong, the registration has to be removed always. To fix this, remove the registration from the list and free it unconditionally, instead of doing it only when the ref reference counter reaches zero. 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-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-2024-27027 CVE - 2024-27027

Oracle Linux: CVE-2024-26929: ELSA-2024-6997:kernel security update (IMPORTANT) (Multiple Advisories) Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 05/01/2024 Created 11/13/2024 Added 10/16/2024 Modified 01/07/2025 Description In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Fix double free of fcport The server was crashing after LOGO because fcport was getting freed twice. -----------[ cut here ]----------- kernel BUG at mm/slub.c:371! invalid opcode: 0000 1 SMP PTI CPU: 35 PID: 4610 Comm: bash Kdump: loaded Tainted: G OE --------- - - 4.18.0-425.3.1.el8.x86_64 #1 Hardware name: HPE ProLiant DL360 Gen10/ProLiant DL360 Gen10, BIOS U32 09/03/2021 RIP: 0010:set_freepointer.part.57+0x0/0x10 RSP: 0018:ffffb07107027d90 EFLAGS: 00010246 RAX: ffff9cb7e3150000 RBX: ffff9cb7e332b9c0 RCX: ffff9cb7e3150400 RDX: 0000000000001f37 RSI: 0000000000000000 RDI: ffff9cb7c0005500 RBP: fffff693448c5400 R08: 0000000080000000 R09: 0000000000000009 R10: 0000000000000000 R11: 0000000000132af0 R12: ffff9cb7c0005500 R13: ffff9cb7e3150000 R14: ffffffffc06990e0 R15: ffff9cb7ea85ea58 FS: 00007ff6b79c2740(0000) GS:ffff9cb8f7ec0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000055b426b7d700 CR3: 0000000169c18002 CR4: 00000000007706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: kfree+0x238/0x250 qla2x00_els_dcmd_sp_free+0x20/0x230 [qla2xxx] ? qla24xx_els_dcmd_iocb+0x607/0x690 [qla2xxx] qla2x00_issue_logo+0x28c/0x2a0 [qla2xxx] ? qla2x00_issue_logo+0x28c/0x2a0 [qla2xxx] ? kernfs_fop_write+0x11e/0x1a0 Remove one of the free calls and add check for valid fcport. Also use function qla2x00_free_fcport() instead of kfree(). Solution(s) oracle-linux-upgrade-kernel References https://attackerkb.com/topics/cve-2024-26929 CVE - 2024-26929 ELSA-2024-6997

Rocky Linux: CVE-2024-26993: kernel-rt (Multiple Advisories) Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 05/01/2024 Created 06/17/2024 Added 06/17/2024 Modified 01/30/2025 Description In the Linux kernel, the following vulnerability has been resolved: fs: sysfs: Fix reference leak in sysfs_break_active_protection() The sysfs_break_active_protection() routine has an obvious reference leak in its error path.If the call to kernfs_find_and_get() fails then kn will be NULL, so the companion sysfs_unbreak_active_protection() routine won't get called (and would only cause an access violation by trying to dereference kn->parent if it was called).As a result, the reference to kobj acquired at the start of the function will never be released. Fix the leak by adding an explicit kobject_put() call when kn is NULL. 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-devel-matched rocky-upgrade-kernel-debug-modules rocky-upgrade-kernel-debug-modules-core rocky-upgrade-kernel-debug-modules-extra rocky-upgrade-kernel-debug-uki-virt rocky-upgrade-kernel-debuginfo rocky-upgrade-kernel-debuginfo-common-x86_64 rocky-upgrade-kernel-devel rocky-upgrade-kernel-devel-matched rocky-upgrade-kernel-headers rocky-upgrade-kernel-modules rocky-upgrade-kernel-modules-core 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-core 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-core 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-kernel-uki-virt rocky-upgrade-kernel-zfcpdump rocky-upgrade-kernel-zfcpdump-core rocky-upgrade-kernel-zfcpdump-debuginfo rocky-upgrade-kernel-zfcpdump-devel rocky-upgrade-kernel-zfcpdump-devel-matched rocky-upgrade-kernel-zfcpdump-modules rocky-upgrade-kernel-zfcpdump-modules-core rocky-upgrade-kernel-zfcpdump-modules-extra rocky-upgrade-libperf rocky-upgrade-libperf-debuginfo rocky-upgrade-perf rocky-upgrade-perf-debuginfo rocky-upgrade-python3-perf rocky-upgrade-python3-perf-debuginfo rocky-upgrade-rtla rocky-upgrade-rv References https://attackerkb.com/topics/cve-2024-26993 CVE - 2024-26993 https://errata.rockylinux.org/RLSA-2024:3618 https://errata.rockylinux.org/RLSA-2024:3619 https://errata.rockylinux.org/RLSA-2024:3627

Rocky Linux: CVE-2024-27014: kernel-rt (Multiple Advisories) Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 05/01/2024 Created 06/17/2024 Added 06/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) 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-2024-27014 CVE - 2024-27014 https://errata.rockylinux.org/RLSA-2024:3618 https://errata.rockylinux.org/RLSA-2024:3627

Rocky Linux: CVE-2024-27048: kernel-rt (Multiple Advisories) Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 05/01/2024 Created 06/17/2024 Added 06/17/2024 Modified 01/28/2025 Description In the Linux kernel, the following vulnerability has been resolved: wifi: brcm80211: handle pmk_op allocation failure The kzalloc() in brcmf_pmksa_v3_op() will return null if the physical memory has run out. As a result, if we dereference the null value, the null pointer dereference bug will happen. Return -ENOMEM from brcmf_pmksa_v3_op() if kzalloc() fails for pmk_op. 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-2024-27048 CVE - 2024-27048 https://errata.rockylinux.org/RLSA-2024:3618 https://errata.rockylinux.org/RLSA-2024:3627

Rocky Linux: CVE-2024-27025: kernel-rt (Multiple Advisories) Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 05/01/2024 Created 08/23/2024 Added 08/22/2024 Modified 01/28/2025 Description In the Linux kernel, the following vulnerability has been resolved: nbd: null check for nla_nest_start nla_nest_start() may fail and return NULL. Insert a check and set errno based on other call sites within the same source code. 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-2024-27025 CVE - 2024-27025 https://errata.rockylinux.org/RLSA-2024:5101 https://errata.rockylinux.org/RLSA-2024:5102

Oracle Linux: CVE-2024-27019: ELSA-2024-5101:kernel security update (IMPORTANT) (Multiple Advisories) Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 05/01/2024 Created 08/20/2024 Added 08/16/2024 Modified 12/06/2024 Description In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: Fix potential data-race in __nft_obj_type_get() nft_unregister_obj() can concurrent with __nft_obj_type_get(), and there is not any protection when iterate over nf_tables_objects list in __nft_obj_type_get(). Therefore, there is potential data-race of nf_tables_objects list entry. Use list_for_each_entry_rcu() to iterate over nf_tables_objects list in __nft_obj_type_get(), and use rcu_read_lock() in the caller nft_obj_type_get() to protect the entire type query process. Solution(s) oracle-linux-upgrade-kernel References https://attackerkb.com/topics/cve-2024-27019 CVE - 2024-27019 ELSA-2024-5101 ELSA-2024-5928

Rocky Linux: CVE-2024-27065: kernel (Multiple Advisories) Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 05/01/2024 Created 08/23/2024 Added 08/22/2024 Modified 11/18/2024 Description In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: do not compare internal table flags on updates Restore skipping transaction if table update does not modify flags. 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-devel-matched rocky-upgrade-kernel-debug-modules rocky-upgrade-kernel-debug-modules-core rocky-upgrade-kernel-debug-modules-extra rocky-upgrade-kernel-debug-uki-virt rocky-upgrade-kernel-debuginfo rocky-upgrade-kernel-debuginfo-common-x86_64 rocky-upgrade-kernel-devel rocky-upgrade-kernel-devel-matched rocky-upgrade-kernel-headers rocky-upgrade-kernel-modules rocky-upgrade-kernel-modules-core 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-core 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-core 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-kernel-uki-virt rocky-upgrade-kernel-zfcpdump rocky-upgrade-kernel-zfcpdump-core rocky-upgrade-kernel-zfcpdump-debuginfo rocky-upgrade-kernel-zfcpdump-devel rocky-upgrade-kernel-zfcpdump-devel-matched rocky-upgrade-kernel-zfcpdump-modules rocky-upgrade-kernel-zfcpdump-modules-core rocky-upgrade-kernel-zfcpdump-modules-extra rocky-upgrade-libperf rocky-upgrade-libperf-debuginfo rocky-upgrade-perf rocky-upgrade-perf-debuginfo rocky-upgrade-python3-perf rocky-upgrade-python3-perf-debuginfo rocky-upgrade-rtla rocky-upgrade-rv References https://attackerkb.com/topics/cve-2024-27065 CVE - 2024-27065 https://errata.rockylinux.org/RLSA-2024:5101 https://errata.rockylinux.org/RLSA-2024:5102 https://errata.rockylinux.org/RLSA-2024:5363

Debian: CVE-2024-26976: linux -- security update Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 05/01/2024 Created 05/08/2024 Added 05/08/2024 Modified 07/03/2024 Description In the Linux kernel, the following vulnerability has been resolved: KVM: Always flush async #PF workqueue when vCPU is being destroyed Always flush the per-vCPU async #PF workqueue when a vCPU is clearing its completion queue, e.g. when a VM and all its vCPUs is being destroyed. KVM must ensure that none of its workqueue callbacks is running when the last reference to the KVM _module_ is put.Gifting a reference to the associated VM prevents the workqueue callback from dereferencing freed vCPU/VM memory, but does not prevent the KVM module from being unloaded before the callback completes. Drop the misguided VM refcount gifting, as calling kvm_put_kvm() from async_pf_execute() if kvm_put_kvm() flushes the async #PF workqueue will result in deadlock.async_pf_execute() can't return until kvm_put_kvm() finishes, and kvm_put_kvm() can't return until async_pf_execute() finishes: WARNING: CPU: 8 PID: 251 at virt/kvm/kvm_main.c:1435 kvm_put_kvm+0x2d/0x320 [kvm] Modules linked in: vhost_net vhost vhost_iotlb tap kvm_intel kvm irqbypass CPU: 8 PID: 251 Comm: kworker/8:1 Tainted: GW6.6.0-rc1-e7af8d17224a-x86/gmem-vm #119 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 Workqueue: events async_pf_execute [kvm] RIP: 0010:kvm_put_kvm+0x2d/0x320 [kvm] Call Trace: <TASK> async_pf_execute+0x198/0x260 [kvm] process_one_work+0x145/0x2d0 worker_thread+0x27e/0x3a0 kthread+0xba/0xe0 ret_from_fork+0x2d/0x50 ret_from_fork_asm+0x11/0x20 </TASK> ---[ end trace 0000000000000000 ]--- INFO: task kworker/8:1:251 blocked for more than 120 seconds. Tainted: GW6.6.0-rc1-e7af8d17224a-x86/gmem-vm #119 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:kworker/8:1 state:D stack:0 pid:251 ppid:2flags:0x00004000 Workqueue: events async_pf_execute [kvm] Call Trace: <TASK> __schedule+0x33f/0xa40 schedule+0x53/0xc0 schedule_timeout+0x12a/0x140 __wait_for_common+0x8d/0x1d0 __flush_work.isra.0+0x19f/0x2c0 kvm_clear_async_pf_completion_queue+0x129/0x190 [kvm] kvm_arch_destroy_vm+0x78/0x1b0 [kvm] kvm_put_kvm+0x1c1/0x320 [kvm] async_pf_execute+0x198/0x260 [kvm] process_one_work+0x145/0x2d0 worker_thread+0x27e/0x3a0 kthread+0xba/0xe0 ret_from_fork+0x2d/0x50 ret_from_fork_asm+0x11/0x20 </TASK> If kvm_clear_async_pf_completion_queue() actually flushes the workqueue, then there's no need to gift async_pf_execute() a reference because all invocations of async_pf_execute() will be forced to complete before the vCPU and its VM are destroyed/freed.And that in turn fixes the module unloading bug as __fput() won't do module_put() on the last vCPU reference until the vCPU has been freed, e.g. if closing the vCPU file also puts the last reference to the KVM module. Note that kvm_check_async_pf_completion() may also take the work item off the completion queue and so also needs to flush the work queue, as the work will not be seen by kvm_clear_async_pf_completion_queue().Waiting on the workqueue could theoretically delay a vCPU due to waiting for the work to complete, but that's a very, very small chance, and likely a very small delay.kvm_arch_async_page_present_queued() unconditionally makes a new request, i.e. will effectively delay entering the guest, so the remaining work is really just: trace_kvm_async_pf_completed(addr, cr2_or_gpa); __kvm_vcpu_wake_up(vcpu); mmput(mm); and mmput() can't drop the last reference to the page tables if the vCPU is still alive, i.e. the vCPU won't get stuck tearing down page tables. Add a helper to do the flushing, specifically to deal with "wakeup all" work items, as they aren't actually work items, i.e. are never placed in a workqueue.Trying to flush a bogus workqueue entry rightly makes __flush_work() complain (kudos to whoever added that sanity check). Note, commit 5f6de5cbebee ("KVM: Prevent module exit until al ---truncated--- Solution(s) debian-upgrade-linux References https://attackerkb.com/topics/cve-2024-26976 CVE - 2024-26976 DSA-5681-1

Debian: CVE-2024-26989: linux -- security update Severity 7 CVSS (AV:L/AC:L/Au:S/C:C/I:C/A:C) Published 05/01/2024 Created 05/08/2024 Added 05/08/2024 Modified 01/30/2025 Description In the Linux kernel, the following vulnerability has been resolved: arm64: hibernate: Fix level3 translation fault in swsusp_save() On arm64 machines, swsusp_save() faults if it attempts to access MEMBLOCK_NOMAP memory ranges. This can be reproduced in QEMU using UEFI when booting with rodata=off debug_pagealloc=off and CONFIG_KFENCE=n: Unable to handle kernel paging request at virtual address ffffff8000000000 Mem abort info: ESR = 0x0000000096000007 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x07: level 3 translation fault Data abort info: ISV = 0, ISS = 0x00000007, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 swapper pgtable: 4k pages, 39-bit VAs, pgdp=00000000eeb0b000 [ffffff8000000000] pgd=180000217fff9803, p4d=180000217fff9803, pud=180000217fff9803, pmd=180000217fff8803, pte=0000000000000000 Internal error: Oops: 0000000096000007 [#1] SMP Internal error: Oops: 0000000096000007 [#1] SMP Modules linked in: xt_multiport ipt_REJECT nf_reject_ipv4 xt_conntrack nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 libcrc32c iptable_filter bpfilter rfkill at803x snd_hda_codec_hdmi snd_hda_intel snd_intel_dspcfg dwmac_generic stmmac_platform snd_hda_codec stmmac joydev pcs_xpcs snd_hda_core phylink ppdev lp parport ramoops reed_solomon ip_tables x_tables nls_iso8859_1 vfat multipath linear amdgpu amdxcp drm_exec gpu_sched drm_buddy hid_generic usbhid hid radeon video drm_suballoc_helper drm_ttm_helper ttm i2c_algo_bit drm_display_helper cec drm_kms_helper drm CPU: 0 PID: 3663 Comm: systemd-sleep Not tainted 6.6.2+ #76 Source Version: 4e22ed63a0a48e7a7cff9b98b7806d8d4add7dc0 Hardware name: Greatwall GW-XXXXXX-XXX/GW-XXXXXX-XXX, BIOS KunLun BIOS V4.0 01/19/2021 pstate: 600003c5 (nZCv DAIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : swsusp_save+0x280/0x538 lr : swsusp_save+0x280/0x538 sp : ffffffa034a3fa40 x29: ffffffa034a3fa40 x28: ffffff8000001000 x27: 0000000000000000 x26: ffffff8001400000 x25: ffffffc08113e248 x24: 0000000000000000 x23: 0000000000080000 x22: ffffffc08113e280 x21: 00000000000c69f2 x20: ffffff8000000000 x19: ffffffc081ae2500 x18: 0000000000000000 x17: 6666662074736420 x16: 3030303030303030 x15: 3038666666666666 x14: 0000000000000b69 x13: ffffff9f89088530 x12: 00000000ffffffea x11: 00000000ffff7fff x10: 00000000ffff7fff x9 : ffffffc08193f0d0 x8 : 00000000000bffe8 x7 : c0000000ffff7fff x6 : 0000000000000001 x5 : ffffffa0fff09dc8 x4 : 0000000000000000 x3 : 0000000000000027 x2 : 0000000000000000 x1 : 0000000000000000 x0 : 000000000000004e Call trace: swsusp_save+0x280/0x538 swsusp_arch_suspend+0x148/0x190 hibernation_snapshot+0x240/0x39c hibernate+0xc4/0x378 state_store+0xf0/0x10c kobj_attr_store+0x14/0x24 The reason is swsusp_save() -> copy_data_pages() -> page_is_saveable() -> kernel_page_present() assuming that a page is always present when can_set_direct_map() is false (all of rodata_full, debug_pagealloc_enabled() and arm64_kfence_can_set_direct_map() false), irrespective of the MEMBLOCK_NOMAP ranges. Such MEMBLOCK_NOMAP regions should not be saved during hibernation. This problem was introduced by changes to the pfn_valid() logic in commit a7d9f306ba70 ("arm64: drop pfn_valid_within() and simplify pfn_valid()"). Similar to other architectures, drop the !can_set_direct_map() check in kernel_page_present() so that page_is_savable() skips such pages. [[email protected]: rework commit message] Solution(s) debian-upgrade-linux References https://attackerkb.com/topics/cve-2024-26989 CVE - 2024-26989 DSA-5680-1

Rocky Linux: CVE-2023-52653: kernel-rt (Multiple Advisories) Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 05/01/2024 Created 08/23/2024 Added 08/22/2024 Modified 11/18/2024 Description In the Linux kernel, the following vulnerability has been resolved: SUNRPC: fix a memleak in gss_import_v2_context The ctx->mech_used.data allocated by kmemdup is not freed in neither gss_import_v2_context nor it only caller gss_krb5_import_sec_context, which frees ctx on error. Thus, this patch reform the last call of gss_import_v2_context to the gss_krb5_import_ctx_v2, preventing the memleak while keepping the return formation. 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-52653 CVE - 2023-52653 https://errata.rockylinux.org/RLSA-2024:5101 https://errata.rockylinux.org/RLSA-2024:5102