ISHACK AI BOT

Ubuntu: (CVE-2023-52636): linux-raspi-realtime vulnerability Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 04/02/2024 Created 02/12/2025 Added 02/11/2025 Modified 02/11/2025 Description In the Linux kernel, the following vulnerability has been resolved: libceph: just wait for more data to be available on the socket A short read may occur while reading the message footer from the socket.Later, when the socket is ready for another read, the messenger invokes all read_partial_*() handlers, including read_partial_sparse_msg_data().The expectation is that read_partial_sparse_msg_data() would bail, allowing the messenger to invoke read_partial() for the footer and pick up where it left off. However read_partial_sparse_msg_data() violates that and ends up calling into the state machine in the OSD client.The sparse-read state machine assumes that it's a new op and interprets some piece of the footer as the sparse-read header and returns bogus extents/data length, etc. To determine whether read_partial_sparse_msg_data() should bail, let's reuse cursor->total_resid.Because once it reaches to zero that means all the extents and data have been successfully received in last read, else it could break out when partially reading any of the extents and data.And then osd_sparse_read() could continue where it left off. [ idryomov: changelog ] Solution(s) ubuntu-upgrade-linux-raspi-realtime References https://attackerkb.com/topics/cve-2023-52636 CVE - 2023-52636 https://git.kernel.org/linus/8e46a2d068c92a905d01cbb018b00d66991585ab https://git.kernel.org/stable/c/8e46a2d068c92a905d01cbb018b00d66991585ab https://git.kernel.org/stable/c/bd9442e553ab8bf74b8be3b3c0a43bf4af4dc9b8 https://git.kernel.org/stable/c/da9c33a70f095d5d55c36d0bfeba969e31de08ae https://www.cve.org/CVERecord?id=CVE-2023-52636

Huawei EulerOS: CVE-2024-26679: kernel security update Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 04/02/2024 Created 07/17/2024 Added 07/17/2024 Modified 01/13/2025 Description In the Linux kernel, the following vulnerability has been resolved: inet: read sk->sk_family once in inet_recv_error() inet_recv_error() is called without holding the socket lock. IPv6 socket could mutate to IPv4 with IPV6_ADDRFORM socket option and trigger a KCSAN warning. 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-26679 CVE - 2024-26679 EulerOS-SA-2024-1964

Huawei EulerOS: CVE-2024-26671: kernel security update Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 04/02/2024 Created 07/17/2024 Added 07/17/2024 Modified 01/13/2025 Description In the Linux kernel, the following vulnerability has been resolved: blk-mq: fix IO hang from sbitmap wakeup race In blk_mq_mark_tag_wait(), __add_wait_queue() may be re-ordered with the following blk_mq_get_driver_tag() in case of getting driver tag failure. Then in __sbitmap_queue_wake_up(), waitqueue_active() may not observe the added waiter in blk_mq_mark_tag_wait() and wake up nothing, meantime blk_mq_mark_tag_wait() can't get driver tag successfully. This issue can be reproduced by running the following test in loop, and fio hang can be observed in < 30min when running it on my test VM in laptop. modprobe -r scsi_debug modprobe scsi_debug delay=0 dev_size_mb=4096 max_queue=1 host_max_queue=1 submit_queues=4 dev=`ls -d /sys/bus/pseudo/drivers/scsi_debug/adapter*/host*/target*/*/block/* | head -1 | xargs basename` fio --filename=/dev/"$dev" --direct=1 --rw=randrw --bs=4k --iodepth=1 \ --runtime=100 --numjobs=40 --time_based --name=test \ --ioengine=libaio Fix the issue by adding one explicit barrier in blk_mq_mark_tag_wait(), which is just fine in case of running out of tag. 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-26671 CVE - 2024-26671 EulerOS-SA-2024-1964

Huawei EulerOS: CVE-2024-26663: kernel security update Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 04/02/2024 Created 07/17/2024 Added 07/17/2024 Modified 01/28/2025 Description In the Linux kernel, the following vulnerability has been resolved: tipc: Check the bearer type before calling tipc_udp_nl_bearer_add() syzbot reported the following general protection fault [1]: general protection fault, probably for non-canonical address 0xdffffc0000000010: 0000 [#1] PREEMPT SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000080-0x0000000000000087] ... RIP: 0010:tipc_udp_is_known_peer+0x9c/0x250 net/tipc/udp_media.c:291 ... Call Trace: <TASK> tipc_udp_nl_bearer_add+0x212/0x2f0 net/tipc/udp_media.c:646 tipc_nl_bearer_add+0x21e/0x360 net/tipc/bearer.c:1089 genl_family_rcv_msg_doit+0x1fc/0x2e0 net/netlink/genetlink.c:972 genl_family_rcv_msg net/netlink/genetlink.c:1052 [inline] genl_rcv_msg+0x561/0x800 net/netlink/genetlink.c:1067 netlink_rcv_skb+0x16b/0x440 net/netlink/af_netlink.c:2544 genl_rcv+0x28/0x40 net/netlink/genetlink.c:1076 netlink_unicast_kernel net/netlink/af_netlink.c:1341 [inline] netlink_unicast+0x53b/0x810 net/netlink/af_netlink.c:1367 netlink_sendmsg+0x8b7/0xd70 net/netlink/af_netlink.c:1909 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0xd5/0x180 net/socket.c:745 ____sys_sendmsg+0x6ac/0x940 net/socket.c:2584 ___sys_sendmsg+0x135/0x1d0 net/socket.c:2638 __sys_sendmsg+0x117/0x1e0 net/socket.c:2667 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x40/0x110 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b The cause of this issue is that when tipc_nl_bearer_add() is called with the TIPC_NLA_BEARER_UDP_OPTS attribute, tipc_udp_nl_bearer_add() is called even if the bearer is not UDP. tipc_udp_is_known_peer() called by tipc_udp_nl_bearer_add() assumes that the media_ptr field of the tipc_bearer has an udp_bearer type object, so the function goes crazy for non-UDP bearers. This patch fixes the issue by checking the bearer type before calling tipc_udp_nl_bearer_add() in tipc_nl_bearer_add(). 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-26663 CVE - 2024-26663 EulerOS-SA-2024-1964

Huawei EulerOS: CVE-2024-26669: kernel security update Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 04/02/2024 Created 07/17/2024 Added 07/17/2024 Modified 07/17/2024 Description In the Linux kernel, the following vulnerability has been resolved: net/sched: flower: Fix chain template offload When a qdisc is deleted from a net device the stack instructs the underlying driver to remove its flow offload callback from the associated filter block using the 'FLOW_BLOCK_UNBIND' command. The stack then continues to replay the removal of the filters in the block for this driver by iterating over the chains in the block and invoking the 'reoffload' operation of the classifier being used. In turn, the classifier in its 'reoffload' operation prepares and emits a 'FLOW_CLS_DESTROY' command for each filter. However, the stack does not do the same for chain templates and the underlying driver never receives a 'FLOW_CLS_TMPLT_DESTROY' command when a qdisc is deleted. This results in a memory leak [1] which can be reproduced using [2]. Fix by introducing a 'tmplt_reoffload' operation and have the stack invoke it with the appropriate arguments as part of the replay. Implement the operation in the sole classifier that supports chain templates (flower) by emitting the 'FLOW_CLS_TMPLT_{CREATE,DESTROY}' command based on whether a flow offload callback is being bound to a filter block or being unbound from one. As far as I can tell, the issue happens since cited commit which reordered tcf_block_offload_unbind() before tcf_block_flush_all_chains() in __tcf_block_put(). The order cannot be reversed as the filter block is expected to be freed after flushing all the chains. [1] unreferenced object 0xffff888107e28800 (size 2048): comm "tc", pid 1079, jiffies 4294958525 (age 3074.287s) hex dump (first 32 bytes): b1 a6 7c 11 81 88 ff ff e0 5b b3 10 81 88 ff ff..|......[...... 01 00 00 00 00 00 00 00 e0 aa b0 84 ff ff ff ff................ backtrace: [<ffffffff81c06a68>] __kmem_cache_alloc_node+0x1e8/0x320 [<ffffffff81ab374e>] __kmalloc+0x4e/0x90 [<ffffffff832aec6d>] mlxsw_sp_acl_ruleset_get+0x34d/0x7a0 [<ffffffff832bc195>] mlxsw_sp_flower_tmplt_create+0x145/0x180 [<ffffffff832b2e1a>] mlxsw_sp_flow_block_cb+0x1ea/0x280 [<ffffffff83a10613>] tc_setup_cb_call+0x183/0x340 [<ffffffff83a9f85a>] fl_tmplt_create+0x3da/0x4c0 [<ffffffff83a22435>] tc_ctl_chain+0xa15/0x1170 [<ffffffff838a863c>] rtnetlink_rcv_msg+0x3cc/0xed0 [<ffffffff83ac87f0>] netlink_rcv_skb+0x170/0x440 [<ffffffff83ac6270>] netlink_unicast+0x540/0x820 [<ffffffff83ac6e28>] netlink_sendmsg+0x8d8/0xda0 [<ffffffff83793def>] ____sys_sendmsg+0x30f/0xa80 [<ffffffff8379d29a>] ___sys_sendmsg+0x13a/0x1e0 [<ffffffff8379d50c>] __sys_sendmsg+0x11c/0x1f0 [<ffffffff843b9ce0>] do_syscall_64+0x40/0xe0 unreferenced object 0xffff88816d2c0400 (size 1024): comm "tc", pid 1079, jiffies 4294958525 (age 3074.287s) hex dump (first 32 bytes): 40 00 00 00 00 00 00 00 57 f6 38 be 00 00 00 [email protected]..... 10 04 2c 6d 81 88 ff ff 10 04 2c 6d 81 88 ff ff..,m......,m.... backtrace: [<ffffffff81c06a68>] __kmem_cache_alloc_node+0x1e8/0x320 [<ffffffff81ab36c1>] __kmalloc_node+0x51/0x90 [<ffffffff81a8ed96>] kvmalloc_node+0xa6/0x1f0 [<ffffffff82827d03>] bucket_table_alloc.isra.0+0x83/0x460 [<ffffffff82828d2b>] rhashtable_init+0x43b/0x7c0 [<ffffffff832aed48>] mlxsw_sp_acl_ruleset_get+0x428/0x7a0 [<ffffffff832bc195>] mlxsw_sp_flower_tmplt_create+0x145/0x180 [<ffffffff832b2e1a>] mlxsw_sp_flow_block_cb+0x1ea/0x280 [<ffffffff83a10613>] tc_setup_cb_call+0x183/0x340 [<ffffffff83a9f85a>] fl_tmplt_create+0x3da/0x4c0 [<ffffffff83a22435>] tc_ctl_chain+0xa15/0x1170 [<ffffffff838a863c>] rtnetlink_rcv_msg+0x3cc/0xed0 [<ffffffff83ac87f0>] netlink_rcv_skb+0x170/0x440 [<ffffffff83ac6270>] netlink_unicast+0x540/0x820 [<ffffffff83ac6e28>] netlink_sendmsg+0x8d8/0xda0 [<ffffffff83793def>] ____sys_sendmsg+0x30f/0xa80 [2] # tc qdisc add dev swp1 clsact # tc chain add dev swp1 ingress proto ip chain 1 flower dst_ip 0.0.0.0/32 # tc qdisc del dev ---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-26669 CVE - 2024-26669 EulerOS-SA-2024-1964

Red Hat: CVE-2023-52632: kernel: drm/amdkfd: lock dependency warning with srcu (Multiple Advisories) Severity 4 CVSS (AV:L/AC:L/Au:M/C:N/I:N/A:C) Published 04/02/2024 Created 12/06/2024 Added 12/05/2024 Modified 12/05/2024 Description In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Fix lock dependency warning with srcu ====================================================== WARNING: possible circular locking dependency detected 6.5.0-kfd-yangp #2289 Not tainted ------------------------------------------------------ kworker/0:2/996 is trying to acquire lock: (srcu){.+.+}-{0:0}, at: __synchronize_srcu+0x5/0x1a0 but task is already holding lock: ((work_completion)(&svms->deferred_list_work)){+.+.}-{0:0}, at: process_one_work+0x211/0x560 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #3 ((work_completion)(&svms->deferred_list_work)){+.+.}-{0:0}: __flush_work+0x88/0x4f0 svm_range_list_lock_and_flush_work+0x3d/0x110 [amdgpu] svm_range_set_attr+0xd6/0x14c0 [amdgpu] kfd_ioctl+0x1d1/0x630 [amdgpu] __x64_sys_ioctl+0x88/0xc0 -> #2 (&info->lock#2){+.+.}-{3:3}: __mutex_lock+0x99/0xc70 amdgpu_amdkfd_gpuvm_restore_process_bos+0x54/0x740 [amdgpu] restore_process_helper+0x22/0x80 [amdgpu] restore_process_worker+0x2d/0xa0 [amdgpu] process_one_work+0x29b/0x560 worker_thread+0x3d/0x3d0 -> #1 ((work_completion)(&(&process->restore_work)->work)){+.+.}-{0:0}: __flush_work+0x88/0x4f0 __cancel_work_timer+0x12c/0x1c0 kfd_process_notifier_release_internal+0x37/0x1f0 [amdgpu] __mmu_notifier_release+0xad/0x240 exit_mmap+0x6a/0x3a0 mmput+0x6a/0x120 do_exit+0x322/0xb90 do_group_exit+0x37/0xa0 __x64_sys_exit_group+0x18/0x20 do_syscall_64+0x38/0x80 -> #0 (srcu){.+.+}-{0:0}: __lock_acquire+0x1521/0x2510 lock_sync+0x5f/0x90 __synchronize_srcu+0x4f/0x1a0 __mmu_notifier_release+0x128/0x240 exit_mmap+0x6a/0x3a0 mmput+0x6a/0x120 svm_range_deferred_list_work+0x19f/0x350 [amdgpu] process_one_work+0x29b/0x560 worker_thread+0x3d/0x3d0 other info that might help us debug this: Chain exists of: srcu --> &info->lock#2 --> (work_completion)(&svms->deferred_list_work) Possible unsafe locking scenario: CPU0CPU1 -------- lock((work_completion)(&svms->deferred_list_work)); lock(&info->lock#2); lock((work_completion)(&svms->deferred_list_work)); sync(srcu); Solution(s) redhat-upgrade-kernel redhat-upgrade-kernel-rt References CVE-2023-52632 RHSA-2024:9315

Red Hat: CVE-2023-52634: kernel: drm/amd/display: Fix disable_otg_wa logic (Multiple Advisories) Severity 4 CVSS (AV:L/AC:L/Au:M/C:N/I:N/A:C) Published 04/02/2024 Created 12/06/2024 Added 12/05/2024 Modified 12/05/2024 Description In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix disable_otg_wa logic [Why] When switching to another HDMI mode, we are unnecesarilly disabling/enabling FIFO causing both HPO and DIG registers to be set at the same time when only HPO is supposed to be set. This can lead to a system hang the next time we change refresh rates as there are cases when we don't disable OTG/FIFO but FIFO is enabled when it isn't supposed to be. [How] Removing the enable/disable FIFO entirely. Solution(s) redhat-upgrade-kernel redhat-upgrade-kernel-rt References CVE-2023-52634 RHSA-2024:9315

SUSE: CVE-2024-26680: SUSE Linux Security Advisory Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 04/02/2024 Created 05/06/2024 Added 05/06/2024 Modified 05/16/2024 Description In the Linux kernel, the following vulnerability has been resolved: net: atlantic: Fix DMA mapping for PTP hwts ring Function aq_ring_hwts_rx_alloc() maps extra AQ_CFG_RXDS_DEF bytes for PTP HWTS ring but then generic aq_ring_free() does not take this into account. Create and use a specific function to free HWTS ring to fix this issue. Trace: [215.351607] ------------[ cut here ]------------ [215.351612] DMA-API: atlantic 0000:4b:00.0: device driver frees DMA memory with different size [device address=0x00000000fbdd0000] [map size=34816 bytes] [unmap size=32768 bytes] [215.351635] WARNING: CPU: 33 PID: 10759 at kernel/dma/debug.c:988 check_unmap+0xa6f/0x2360 ... [215.581176] Call Trace: [215.583632]<TASK> [215.585745]? show_trace_log_lvl+0x1c4/0x2df [215.590114]? show_trace_log_lvl+0x1c4/0x2df [215.594497]? debug_dma_free_coherent+0x196/0x210 [215.599305]? check_unmap+0xa6f/0x2360 [215.603147]? __warn+0xca/0x1d0 [215.606391]? check_unmap+0xa6f/0x2360 [215.610237]? report_bug+0x1ef/0x370 [215.613921]? handle_bug+0x3c/0x70 [215.617423]? exc_invalid_op+0x14/0x50 [215.621269]? asm_exc_invalid_op+0x16/0x20 [215.625480]? check_unmap+0xa6f/0x2360 [215.629331]? mark_lock.part.0+0xca/0xa40 [215.633445]debug_dma_free_coherent+0x196/0x210 [215.638079]? __pfx_debug_dma_free_coherent+0x10/0x10 [215.643242]? slab_free_freelist_hook+0x11d/0x1d0 [215.648060]dma_free_attrs+0x6d/0x130 [215.651834]aq_ring_free+0x193/0x290 [atlantic] [215.656487]aq_ptp_ring_free+0x67/0x110 [atlantic] ... [216.127540] ---[ end trace 6467e5964dd2640b ]--- [216.132160] DMA-API: Mapped at: [216.132162]debug_dma_alloc_coherent+0x66/0x2f0 [216.132165]dma_alloc_attrs+0xf5/0x1b0 [216.132168]aq_ring_hwts_rx_alloc+0x150/0x1f0 [atlantic] [216.132193]aq_ptp_ring_alloc+0x1bb/0x540 [atlantic] [216.132213]aq_nic_init+0x4a1/0x760 [atlantic] 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-26680 CVE - 2024-26680

Red Hat: CVE-2024-26675: kernel: ppp_async: limit MRU to 64K (Multiple Advisories) Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 04/02/2024 Created 07/03/2024 Added 07/03/2024 Modified 12/05/2024 Description In the Linux kernel, the following vulnerability has been resolved: ppp_async: limit MRU to 64K syzbot triggered a warning [1] in __alloc_pages(): WARN_ON_ONCE_GFP(order > MAX_PAGE_ORDER, gfp) Willem fixed a similar issue in commit c0a2a1b0d631 ("ppp: limit MRU to 64K") Adopt the same sanity check for ppp_async_ioctl(PPPIOCSMRU) [1]: WARNING: CPU: 1 PID: 11 at mm/page_alloc.c:4543 __alloc_pages+0x308/0x698 mm/page_alloc.c:4543 Modules linked in: CPU: 1 PID: 11 Comm: kworker/u4:0 Not tainted 6.8.0-rc2-syzkaller-g41bccc98fb79 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023 Workqueue: events_unbound flush_to_ldisc pstate: 204000c5 (nzCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : __alloc_pages+0x308/0x698 mm/page_alloc.c:4543 lr : __alloc_pages+0xc8/0x698 mm/page_alloc.c:4537 sp : ffff800093967580 x29: ffff800093967660 x28: ffff8000939675a0 x27: dfff800000000000 x26: ffff70001272ceb4 x25: 0000000000000000 x24: ffff8000939675c0 x23: 0000000000000000 x22: 0000000000060820 x21: 1ffff0001272ceb8 x20: ffff8000939675e0 x19: 0000000000000010 x18: ffff800093967120 x17: ffff800083bded5c x16: ffff80008ac97500 x15: 0000000000000005 x14: 1ffff0001272cebc x13: 0000000000000000 x12: 0000000000000000 x11: ffff70001272cec1 x10: 1ffff0001272cec0 x9 : 0000000000000001 x8 : ffff800091c91000 x7 : 0000000000000000 x6 : 000000000000003f x5 : 00000000ffffffff x4 : 0000000000000000 x3 : 0000000000000020 x2 : 0000000000000008 x1 : 0000000000000000 x0 : ffff8000939675e0 Call trace: __alloc_pages+0x308/0x698 mm/page_alloc.c:4543 __alloc_pages_node include/linux/gfp.h:238 [inline] alloc_pages_node include/linux/gfp.h:261 [inline] __kmalloc_large_node+0xbc/0x1fc mm/slub.c:3926 __do_kmalloc_node mm/slub.c:3969 [inline] __kmalloc_node_track_caller+0x418/0x620 mm/slub.c:4001 kmalloc_reserve+0x17c/0x23c net/core/skbuff.c:590 __alloc_skb+0x1c8/0x3d8 net/core/skbuff.c:651 __netdev_alloc_skb+0xb8/0x3e8 net/core/skbuff.c:715 netdev_alloc_skb include/linux/skbuff.h:3235 [inline] dev_alloc_skb include/linux/skbuff.h:3248 [inline] ppp_async_input drivers/net/ppp/ppp_async.c:863 [inline] ppp_asynctty_receive+0x588/0x186c drivers/net/ppp/ppp_async.c:341 tty_ldisc_receive_buf+0x12c/0x15c drivers/tty/tty_buffer.c:390 tty_port_default_receive_buf+0x74/0xac drivers/tty/tty_port.c:37 receive_buf drivers/tty/tty_buffer.c:444 [inline] flush_to_ldisc+0x284/0x6e4 drivers/tty/tty_buffer.c:494 process_one_work+0x694/0x1204 kernel/workqueue.c:2633 process_scheduled_works kernel/workqueue.c:2706 [inline] worker_thread+0x938/0xef4 kernel/workqueue.c:2787 kthread+0x288/0x310 kernel/kthread.c:388 ret_from_fork+0x10/0x20 arch/arm64/kernel/entry.S:860 Solution(s) redhat-upgrade-kernel redhat-upgrade-kernel-rt References CVE-2024-26675 RHSA-2024:4211 RHSA-2024:4352 RHSA-2024:9315

Debian: CVE-2023-52632: linux -- security update Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 04/02/2024 Created 07/31/2024 Added 07/30/2024 Modified 07/30/2024 Description In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Fix lock dependency warning with srcu ====================================================== WARNING: possible circular locking dependency detected 6.5.0-kfd-yangp #2289 Not tainted ------------------------------------------------------ kworker/0:2/996 is trying to acquire lock: (srcu){.+.+}-{0:0}, at: __synchronize_srcu+0x5/0x1a0 but task is already holding lock: ((work_completion)(&svms->deferred_list_work)){+.+.}-{0:0}, at: process_one_work+0x211/0x560 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #3 ((work_completion)(&svms->deferred_list_work)){+.+.}-{0:0}: __flush_work+0x88/0x4f0 svm_range_list_lock_and_flush_work+0x3d/0x110 [amdgpu] svm_range_set_attr+0xd6/0x14c0 [amdgpu] kfd_ioctl+0x1d1/0x630 [amdgpu] __x64_sys_ioctl+0x88/0xc0 -> #2 (&info->lock#2){+.+.}-{3:3}: __mutex_lock+0x99/0xc70 amdgpu_amdkfd_gpuvm_restore_process_bos+0x54/0x740 [amdgpu] restore_process_helper+0x22/0x80 [amdgpu] restore_process_worker+0x2d/0xa0 [amdgpu] process_one_work+0x29b/0x560 worker_thread+0x3d/0x3d0 -> #1 ((work_completion)(&(&process->restore_work)->work)){+.+.}-{0:0}: __flush_work+0x88/0x4f0 __cancel_work_timer+0x12c/0x1c0 kfd_process_notifier_release_internal+0x37/0x1f0 [amdgpu] __mmu_notifier_release+0xad/0x240 exit_mmap+0x6a/0x3a0 mmput+0x6a/0x120 do_exit+0x322/0xb90 do_group_exit+0x37/0xa0 __x64_sys_exit_group+0x18/0x20 do_syscall_64+0x38/0x80 -> #0 (srcu){.+.+}-{0:0}: __lock_acquire+0x1521/0x2510 lock_sync+0x5f/0x90 __synchronize_srcu+0x4f/0x1a0 __mmu_notifier_release+0x128/0x240 exit_mmap+0x6a/0x3a0 mmput+0x6a/0x120 svm_range_deferred_list_work+0x19f/0x350 [amdgpu] process_one_work+0x29b/0x560 worker_thread+0x3d/0x3d0 other info that might help us debug this: Chain exists of: srcu --> &info->lock#2 --> (work_completion)(&svms->deferred_list_work) Possible unsafe locking scenario: CPU0CPU1 -------- lock((work_completion)(&svms->deferred_list_work)); lock(&info->lock#2); lock((work_completion)(&svms->deferred_list_work)); sync(srcu); Solution(s) debian-upgrade-linux References https://attackerkb.com/topics/cve-2023-52632 CVE - 2023-52632

Huawei EulerOS: CVE-2024-26665: kernel security update Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 04/02/2024 Created 10/09/2024 Added 10/08/2024 Modified 10/08/2024 Description In the Linux kernel, the following vulnerability has been resolved: tunnels: fix out of bounds access when building IPv6 PMTU error If the ICMPv6 error is built from a non-linear skb we get the following splat, BUG: KASAN: slab-out-of-bounds in do_csum+0x220/0x240 Read of size 4 at addr ffff88811d402c80 by task netperf/820 CPU: 0 PID: 820 Comm: netperf Not tainted 6.8.0-rc1+ #543 ... kasan_report+0xd8/0x110 do_csum+0x220/0x240 csum_partial+0xc/0x20 skb_tunnel_check_pmtu+0xeb9/0x3280 vxlan_xmit_one+0x14c2/0x4080 vxlan_xmit+0xf61/0x5c00 dev_hard_start_xmit+0xfb/0x510 __dev_queue_xmit+0x7cd/0x32a0 br_dev_queue_push_xmit+0x39d/0x6a0 Use skb_checksum instead of csum_partial who cannot deal with non-linear SKBs. Solution(s) huawei-euleros-2_0_sp12-upgrade-bpftool huawei-euleros-2_0_sp12-upgrade-kernel huawei-euleros-2_0_sp12-upgrade-kernel-abi-stablelists huawei-euleros-2_0_sp12-upgrade-kernel-tools huawei-euleros-2_0_sp12-upgrade-kernel-tools-libs huawei-euleros-2_0_sp12-upgrade-python3-perf References https://attackerkb.com/topics/cve-2024-26665 CVE - 2024-26665 EulerOS-SA-2024-2240

Huawei EulerOS: CVE-2024-26669: kernel security update Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 04/02/2024 Created 10/09/2024 Added 10/08/2024 Modified 10/08/2024 Description In the Linux kernel, the following vulnerability has been resolved: net/sched: flower: Fix chain template offload When a qdisc is deleted from a net device the stack instructs the underlying driver to remove its flow offload callback from the associated filter block using the 'FLOW_BLOCK_UNBIND' command. The stack then continues to replay the removal of the filters in the block for this driver by iterating over the chains in the block and invoking the 'reoffload' operation of the classifier being used. In turn, the classifier in its 'reoffload' operation prepares and emits a 'FLOW_CLS_DESTROY' command for each filter. However, the stack does not do the same for chain templates and the underlying driver never receives a 'FLOW_CLS_TMPLT_DESTROY' command when a qdisc is deleted. This results in a memory leak [1] which can be reproduced using [2]. Fix by introducing a 'tmplt_reoffload' operation and have the stack invoke it with the appropriate arguments as part of the replay. Implement the operation in the sole classifier that supports chain templates (flower) by emitting the 'FLOW_CLS_TMPLT_{CREATE,DESTROY}' command based on whether a flow offload callback is being bound to a filter block or being unbound from one. As far as I can tell, the issue happens since cited commit which reordered tcf_block_offload_unbind() before tcf_block_flush_all_chains() in __tcf_block_put(). The order cannot be reversed as the filter block is expected to be freed after flushing all the chains. [1] unreferenced object 0xffff888107e28800 (size 2048): comm "tc", pid 1079, jiffies 4294958525 (age 3074.287s) hex dump (first 32 bytes): b1 a6 7c 11 81 88 ff ff e0 5b b3 10 81 88 ff ff..|......[...... 01 00 00 00 00 00 00 00 e0 aa b0 84 ff ff ff ff................ backtrace: [<ffffffff81c06a68>] __kmem_cache_alloc_node+0x1e8/0x320 [<ffffffff81ab374e>] __kmalloc+0x4e/0x90 [<ffffffff832aec6d>] mlxsw_sp_acl_ruleset_get+0x34d/0x7a0 [<ffffffff832bc195>] mlxsw_sp_flower_tmplt_create+0x145/0x180 [<ffffffff832b2e1a>] mlxsw_sp_flow_block_cb+0x1ea/0x280 [<ffffffff83a10613>] tc_setup_cb_call+0x183/0x340 [<ffffffff83a9f85a>] fl_tmplt_create+0x3da/0x4c0 [<ffffffff83a22435>] tc_ctl_chain+0xa15/0x1170 [<ffffffff838a863c>] rtnetlink_rcv_msg+0x3cc/0xed0 [<ffffffff83ac87f0>] netlink_rcv_skb+0x170/0x440 [<ffffffff83ac6270>] netlink_unicast+0x540/0x820 [<ffffffff83ac6e28>] netlink_sendmsg+0x8d8/0xda0 [<ffffffff83793def>] ____sys_sendmsg+0x30f/0xa80 [<ffffffff8379d29a>] ___sys_sendmsg+0x13a/0x1e0 [<ffffffff8379d50c>] __sys_sendmsg+0x11c/0x1f0 [<ffffffff843b9ce0>] do_syscall_64+0x40/0xe0 unreferenced object 0xffff88816d2c0400 (size 1024): comm "tc", pid 1079, jiffies 4294958525 (age 3074.287s) hex dump (first 32 bytes): 40 00 00 00 00 00 00 00 57 f6 38 be 00 00 00 [email protected]..... 10 04 2c 6d 81 88 ff ff 10 04 2c 6d 81 88 ff ff..,m......,m.... backtrace: [<ffffffff81c06a68>] __kmem_cache_alloc_node+0x1e8/0x320 [<ffffffff81ab36c1>] __kmalloc_node+0x51/0x90 [<ffffffff81a8ed96>] kvmalloc_node+0xa6/0x1f0 [<ffffffff82827d03>] bucket_table_alloc.isra.0+0x83/0x460 [<ffffffff82828d2b>] rhashtable_init+0x43b/0x7c0 [<ffffffff832aed48>] mlxsw_sp_acl_ruleset_get+0x428/0x7a0 [<ffffffff832bc195>] mlxsw_sp_flower_tmplt_create+0x145/0x180 [<ffffffff832b2e1a>] mlxsw_sp_flow_block_cb+0x1ea/0x280 [<ffffffff83a10613>] tc_setup_cb_call+0x183/0x340 [<ffffffff83a9f85a>] fl_tmplt_create+0x3da/0x4c0 [<ffffffff83a22435>] tc_ctl_chain+0xa15/0x1170 [<ffffffff838a863c>] rtnetlink_rcv_msg+0x3cc/0xed0 [<ffffffff83ac87f0>] netlink_rcv_skb+0x170/0x440 [<ffffffff83ac6270>] netlink_unicast+0x540/0x820 [<ffffffff83ac6e28>] netlink_sendmsg+0x8d8/0xda0 [<ffffffff83793def>] ____sys_sendmsg+0x30f/0xa80 [2] # tc qdisc add dev swp1 clsact # tc chain add dev swp1 ingress proto ip chain 1 flower dst_ip 0.0.0.0/32 # tc qdisc del dev ---truncated--- Solution(s) huawei-euleros-2_0_sp12-upgrade-bpftool huawei-euleros-2_0_sp12-upgrade-kernel huawei-euleros-2_0_sp12-upgrade-kernel-abi-stablelists huawei-euleros-2_0_sp12-upgrade-kernel-tools huawei-euleros-2_0_sp12-upgrade-kernel-tools-libs huawei-euleros-2_0_sp12-upgrade-python3-perf References https://attackerkb.com/topics/cve-2024-26669 CVE - 2024-26669 EulerOS-SA-2024-2240

Huawei EulerOS: CVE-2024-26668: kernel security update Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 04/02/2024 Created 10/09/2024 Added 10/08/2024 Modified 10/08/2024 Description In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_limit: reject configurations that cause integer overflow Reject bogus configs where internal token counter wraps around. This only occurs with very very large requests, such as 17gbyte/s. Its better to reject this rather than having incorrect ratelimit. Solution(s) huawei-euleros-2_0_sp12-upgrade-bpftool huawei-euleros-2_0_sp12-upgrade-kernel huawei-euleros-2_0_sp12-upgrade-kernel-abi-stablelists huawei-euleros-2_0_sp12-upgrade-kernel-tools huawei-euleros-2_0_sp12-upgrade-kernel-tools-libs huawei-euleros-2_0_sp12-upgrade-python3-perf References https://attackerkb.com/topics/cve-2024-26668 CVE - 2024-26668 EulerOS-SA-2024-2240

Huawei EulerOS: CVE-2024-26663: kernel security update Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 04/02/2024 Created 10/09/2024 Added 10/08/2024 Modified 01/28/2025 Description In the Linux kernel, the following vulnerability has been resolved: tipc: Check the bearer type before calling tipc_udp_nl_bearer_add() syzbot reported the following general protection fault [1]: general protection fault, probably for non-canonical address 0xdffffc0000000010: 0000 [#1] PREEMPT SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000080-0x0000000000000087] ... RIP: 0010:tipc_udp_is_known_peer+0x9c/0x250 net/tipc/udp_media.c:291 ... Call Trace: <TASK> tipc_udp_nl_bearer_add+0x212/0x2f0 net/tipc/udp_media.c:646 tipc_nl_bearer_add+0x21e/0x360 net/tipc/bearer.c:1089 genl_family_rcv_msg_doit+0x1fc/0x2e0 net/netlink/genetlink.c:972 genl_family_rcv_msg net/netlink/genetlink.c:1052 [inline] genl_rcv_msg+0x561/0x800 net/netlink/genetlink.c:1067 netlink_rcv_skb+0x16b/0x440 net/netlink/af_netlink.c:2544 genl_rcv+0x28/0x40 net/netlink/genetlink.c:1076 netlink_unicast_kernel net/netlink/af_netlink.c:1341 [inline] netlink_unicast+0x53b/0x810 net/netlink/af_netlink.c:1367 netlink_sendmsg+0x8b7/0xd70 net/netlink/af_netlink.c:1909 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0xd5/0x180 net/socket.c:745 ____sys_sendmsg+0x6ac/0x940 net/socket.c:2584 ___sys_sendmsg+0x135/0x1d0 net/socket.c:2638 __sys_sendmsg+0x117/0x1e0 net/socket.c:2667 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x40/0x110 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b The cause of this issue is that when tipc_nl_bearer_add() is called with the TIPC_NLA_BEARER_UDP_OPTS attribute, tipc_udp_nl_bearer_add() is called even if the bearer is not UDP. tipc_udp_is_known_peer() called by tipc_udp_nl_bearer_add() assumes that the media_ptr field of the tipc_bearer has an udp_bearer type object, so the function goes crazy for non-UDP bearers. This patch fixes the issue by checking the bearer type before calling tipc_udp_nl_bearer_add() in tipc_nl_bearer_add(). Solution(s) huawei-euleros-2_0_sp12-upgrade-bpftool huawei-euleros-2_0_sp12-upgrade-kernel huawei-euleros-2_0_sp12-upgrade-kernel-abi-stablelists huawei-euleros-2_0_sp12-upgrade-kernel-tools huawei-euleros-2_0_sp12-upgrade-kernel-tools-libs huawei-euleros-2_0_sp12-upgrade-python3-perf References https://attackerkb.com/topics/cve-2024-26663 CVE - 2024-26663 EulerOS-SA-2024-2240

Huawei EulerOS: CVE-2024-26671: kernel security update Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 04/02/2024 Created 10/09/2024 Added 10/08/2024 Modified 10/08/2024 Description In the Linux kernel, the following vulnerability has been resolved: blk-mq: fix IO hang from sbitmap wakeup race In blk_mq_mark_tag_wait(), __add_wait_queue() may be re-ordered with the following blk_mq_get_driver_tag() in case of getting driver tag failure. Then in __sbitmap_queue_wake_up(), waitqueue_active() may not observe the added waiter in blk_mq_mark_tag_wait() and wake up nothing, meantime blk_mq_mark_tag_wait() can't get driver tag successfully. This issue can be reproduced by running the following test in loop, and fio hang can be observed in < 30min when running it on my test VM in laptop. modprobe -r scsi_debug modprobe scsi_debug delay=0 dev_size_mb=4096 max_queue=1 host_max_queue=1 submit_queues=4 dev=`ls -d /sys/bus/pseudo/drivers/scsi_debug/adapter*/host*/target*/*/block/* | head -1 | xargs basename` fio --filename=/dev/"$dev" --direct=1 --rw=randrw --bs=4k --iodepth=1 \ --runtime=100 --numjobs=40 --time_based --name=test \ --ioengine=libaio Fix the issue by adding one explicit barrier in blk_mq_mark_tag_wait(), which is just fine in case of running out of tag. Solution(s) huawei-euleros-2_0_sp12-upgrade-bpftool huawei-euleros-2_0_sp12-upgrade-kernel huawei-euleros-2_0_sp12-upgrade-kernel-abi-stablelists huawei-euleros-2_0_sp12-upgrade-kernel-tools huawei-euleros-2_0_sp12-upgrade-kernel-tools-libs huawei-euleros-2_0_sp12-upgrade-python3-perf References https://attackerkb.com/topics/cve-2024-26671 CVE - 2024-26671 EulerOS-SA-2024-2240

Huawei EulerOS: CVE-2024-26673: kernel security update Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 04/02/2024 Created 10/09/2024 Added 10/08/2024 Modified 10/08/2024 Description In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_ct: sanitize layer 3 and 4 protocol number in custom expectations - Disallow families other than NFPROTO_{IPV4,IPV6,INET}. - Disallow layer 4 protocol with no ports, since destination port is a mandatory attribute for this object. Solution(s) huawei-euleros-2_0_sp12-upgrade-bpftool huawei-euleros-2_0_sp12-upgrade-kernel huawei-euleros-2_0_sp12-upgrade-kernel-abi-stablelists huawei-euleros-2_0_sp12-upgrade-kernel-tools huawei-euleros-2_0_sp12-upgrade-kernel-tools-libs huawei-euleros-2_0_sp12-upgrade-python3-perf References https://attackerkb.com/topics/cve-2024-26673 CVE - 2024-26673 EulerOS-SA-2024-2240

Huawei EulerOS: CVE-2024-26679: kernel security update Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 04/02/2024 Created 10/09/2024 Added 10/08/2024 Modified 10/08/2024 Description In the Linux kernel, the following vulnerability has been resolved: inet: read sk->sk_family once in inet_recv_error() inet_recv_error() is called without holding the socket lock. IPv6 socket could mutate to IPv4 with IPV6_ADDRFORM socket option and trigger a KCSAN warning. Solution(s) huawei-euleros-2_0_sp12-upgrade-bpftool huawei-euleros-2_0_sp12-upgrade-kernel huawei-euleros-2_0_sp12-upgrade-kernel-abi-stablelists huawei-euleros-2_0_sp12-upgrade-kernel-tools huawei-euleros-2_0_sp12-upgrade-kernel-tools-libs huawei-euleros-2_0_sp12-upgrade-python3-perf References https://attackerkb.com/topics/cve-2024-26679 CVE - 2024-26679 EulerOS-SA-2024-2240

Debian: CVE-2024-26679: linux -- security update Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 04/02/2024 Created 05/08/2024 Added 05/08/2024 Modified 07/03/2024 Description In the Linux kernel, the following vulnerability has been resolved: inet: read sk->sk_family once in inet_recv_error() inet_recv_error() is called without holding the socket lock. IPv6 socket could mutate to IPv4 with IPV6_ADDRFORM socket option and trigger a KCSAN warning. Solution(s) debian-upgrade-linux References https://attackerkb.com/topics/cve-2024-26679 CVE - 2024-26679 DSA-5681-1

Huawei EulerOS: CVE-2024-26680: kernel security update Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 04/02/2024 Created 10/09/2024 Added 10/08/2024 Modified 10/08/2024 Description In the Linux kernel, the following vulnerability has been resolved: net: atlantic: Fix DMA mapping for PTP hwts ring Function aq_ring_hwts_rx_alloc() maps extra AQ_CFG_RXDS_DEF bytes for PTP HWTS ring but then generic aq_ring_free() does not take this into account. Create and use a specific function to free HWTS ring to fix this issue. Trace: [215.351607] ------------[ cut here ]------------ [215.351612] DMA-API: atlantic 0000:4b:00.0: device driver frees DMA memory with different size [device address=0x00000000fbdd0000] [map size=34816 bytes] [unmap size=32768 bytes] [215.351635] WARNING: CPU: 33 PID: 10759 at kernel/dma/debug.c:988 check_unmap+0xa6f/0x2360 ... [215.581176] Call Trace: [215.583632]<TASK> [215.585745]? show_trace_log_lvl+0x1c4/0x2df [215.590114]? show_trace_log_lvl+0x1c4/0x2df [215.594497]? debug_dma_free_coherent+0x196/0x210 [215.599305]? check_unmap+0xa6f/0x2360 [215.603147]? __warn+0xca/0x1d0 [215.606391]? check_unmap+0xa6f/0x2360 [215.610237]? report_bug+0x1ef/0x370 [215.613921]? handle_bug+0x3c/0x70 [215.617423]? exc_invalid_op+0x14/0x50 [215.621269]? asm_exc_invalid_op+0x16/0x20 [215.625480]? check_unmap+0xa6f/0x2360 [215.629331]? mark_lock.part.0+0xca/0xa40 [215.633445]debug_dma_free_coherent+0x196/0x210 [215.638079]? __pfx_debug_dma_free_coherent+0x10/0x10 [215.643242]? slab_free_freelist_hook+0x11d/0x1d0 [215.648060]dma_free_attrs+0x6d/0x130 [215.651834]aq_ring_free+0x193/0x290 [atlantic] [215.656487]aq_ptp_ring_free+0x67/0x110 [atlantic] ... [216.127540] ---[ end trace 6467e5964dd2640b ]--- [216.132160] DMA-API: Mapped at: [216.132162]debug_dma_alloc_coherent+0x66/0x2f0 [216.132165]dma_alloc_attrs+0xf5/0x1b0 [216.132168]aq_ring_hwts_rx_alloc+0x150/0x1f0 [atlantic] [216.132193]aq_ptp_ring_alloc+0x1bb/0x540 [atlantic] [216.132213]aq_nic_init+0x4a1/0x760 [atlantic] Solution(s) huawei-euleros-2_0_sp12-upgrade-bpftool huawei-euleros-2_0_sp12-upgrade-kernel huawei-euleros-2_0_sp12-upgrade-kernel-abi-stablelists huawei-euleros-2_0_sp12-upgrade-kernel-tools huawei-euleros-2_0_sp12-upgrade-kernel-tools-libs huawei-euleros-2_0_sp12-upgrade-python3-perf References https://attackerkb.com/topics/cve-2024-26680 CVE - 2024-26680 EulerOS-SA-2024-2240

Oracle Linux: CVE-2024-26656: ELSA-2024-4211:kernel security and bug fix update (IMPORTANT) (Multiple Advisories) Severity 4 CVSS (AV:L/AC:H/Au:S/C:N/I:N/A:C) Published 04/02/2024 Created 07/04/2024 Added 07/03/2024 Modified 01/07/2025 Description In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix use-after-free bug The bug can be triggered by sending a single amdgpu_gem_userptr_ioctl to the AMDGPU DRM driver on any ASICs with an invalid address and size. The bug was reported by Joonkyo Jung &lt;[email protected]&gt;. For example the following code: static void Syzkaller1(int fd) { struct drm_amdgpu_gem_userptr arg; int ret; arg.addr = 0xffffffffffff0000; arg.size = 0x80000000; /*2 Gb*/ arg.flags = 0x7; ret = drmIoctl(fd, 0xc1186451/*amdgpu_gem_userptr_ioctl*/, &amp;arg); } Due to the address and size are not valid there is a failure in amdgpu_hmm_register-&gt;mmu_interval_notifier_insert-&gt;__mmu_interval_notifier_insert-&gt; check_shl_overflow, but we even the amdgpu_hmm_register failure we still call amdgpu_hmm_unregister intoamdgpu_gem_object_free which causes access to a bad address. The following stack is below when the issue is reproduced when Kazan is enabled: [+0.000014] Hardware name: ASUS System Product Name/ROG STRIX B550-F GAMING (WI-FI), BIOS 1401 12/03/2020 [+0.000009] RIP: 0010:mmu_interval_notifier_remove+0x327/0x340 [+0.000017] Code: ff ff 49 89 44 24 08 48 b8 00 01 00 00 00 00 ad de 4c 89 f7 49 89 47 40 48 83 c0 22 49 89 47 48 e8 ce d1 2d 01 e9 32 ff ff ff &lt;0f&gt; 0b e9 16 ff ff ff 4c 89 ef e8 fa 14 b3 ff e9 36 ff ff ff e8 80 [+0.000014] RSP: 0018:ffffc90002657988 EFLAGS: 00010246 [+0.000013] RAX: 0000000000000000 RBX: 1ffff920004caf35 RCX: ffffffff8160565b [+0.000011] RDX: dffffc0000000000 RSI: 0000000000000004 RDI: ffff8881a9f78260 [+0.000010] RBP: ffffc90002657a70 R08: 0000000000000001 R09: fffff520004caf25 [+0.000010] R10: 0000000000000003 R11: ffffffff8161d1d6 R12: ffff88810e988c00 [+0.000010] R13: ffff888126fb5a00 R14: ffff88810e988c0c R15: ffff8881a9f78260 [+0.000011] FS:00007ff9ec848540(0000) GS:ffff8883cc880000(0000) knlGS:0000000000000000 [+0.000012] CS:0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [+0.000010] CR2: 000055b3f7e14328 CR3: 00000001b5770000 CR4: 0000000000350ef0 [+0.000010] Call Trace: [+0.000006]&lt;TASK&gt; [+0.000007]? show_regs+0x6a/0x80 [+0.000018]? __warn+0xa5/0x1b0 [+0.000019]? mmu_interval_notifier_remove+0x327/0x340 [+0.000018]? report_bug+0x24a/0x290 [+0.000022]? handle_bug+0x46/0x90 [+0.000015]? exc_invalid_op+0x19/0x50 [+0.000016]? asm_exc_invalid_op+0x1b/0x20 [+0.000017]? kasan_save_stack+0x26/0x50 [+0.000017]? mmu_interval_notifier_remove+0x23b/0x340 [+0.000019]? mmu_interval_notifier_remove+0x327/0x340 [+0.000019]? mmu_interval_notifier_remove+0x23b/0x340 [+0.000020]? __pfx_mmu_interval_notifier_remove+0x10/0x10 [+0.000017]? kasan_save_alloc_info+0x1e/0x30 [+0.000018]? srso_return_thunk+0x5/0x5f [+0.000014]? __kasan_kmalloc+0xb1/0xc0 [+0.000018]? srso_return_thunk+0x5/0x5f [+0.000013]? __kasan_check_read+0x11/0x20 [+0.000020]amdgpu_hmm_unregister+0x34/0x50 [amdgpu] [+0.004695]amdgpu_gem_object_free+0x66/0xa0 [amdgpu] [+0.004534]? __pfx_amdgpu_gem_object_free+0x10/0x10 [amdgpu] [+0.004291]? do_syscall_64+0x5f/0xe0 [+0.000023]? srso_return_thunk+0x5/0x5f [+0.000017]drm_gem_object_free+0x3b/0x50 [drm] [+0.000489]amdgpu_gem_userptr_ioctl+0x306/0x500 [amdgpu] [+0.004295]? __pfx_amdgpu_gem_userptr_ioctl+0x10/0x10 [amdgpu] [+0.004270]? srso_return_thunk+0x5/0x5f [+0.000014]? __this_cpu_preempt_check+0x13/0x20 [+0.000015]? srso_return_thunk+0x5/0x5f [+0.000013]? sysvec_apic_timer_interrupt+0x57/0xc0 [+0.000020]? srso_return_thunk+0x5/0x5f [+0.000014]? asm_sysvec_apic_timer_interrupt+0x1b/0x20 [+0.000022]? drm_ioctl_kernel+0x17b/0x1f0 [drm] [+0.000496]? __pfx_amdgpu_gem_userptr_ioctl+0x10/0x10 [amdgpu] [+0.004272]? drm_ioctl_kernel+0x190/0x1f0 [drm] [+0.000492]drm_ioctl_kernel+0x140/0x1f0 [drm] [+0.000497]? __pfx_amdgpu_gem_userptr_ioctl+0x10/0x10 [amdgpu] [+0.004297]? __pfx_drm_ioctl_kernel+0x10/0x10 [d ---truncated--- A failure flaw was found in the Linux kernel’s AMDGPU driver in how a user sends ioctl with an invalid address and size when using the AMD GPU. This flaw allows a local user to crash the system. Solution(s) oracle-linux-upgrade-kernel References https://attackerkb.com/topics/cve-2024-26656 CVE - 2024-26656 ELSA-2024-4211

Oracle Linux: CVE-2024-26669: ELSA-2024-5101:kernel security update (IMPORTANT) (Multiple Advisories) Severity 6 CVSS (AV:L/AC:L/Au:S/C:C/I:N/A:C) Published 04/02/2024 Created 08/20/2024 Added 08/16/2024 Modified 11/29/2024 Description In the Linux kernel, the following vulnerability has been resolved: net/sched: flower: Fix chain template offload When a qdisc is deleted from a net device the stack instructs the underlying driver to remove its flow offload callback from the associated filter block using the &apos;FLOW_BLOCK_UNBIND&apos; command. The stack then continues to replay the removal of the filters in the block for this driver by iterating over the chains in the block and invoking the &apos;reoffload&apos; operation of the classifier being used. In turn, the classifier in its &apos;reoffload&apos; operation prepares and emits a &apos;FLOW_CLS_DESTROY&apos; command for each filter. However, the stack does not do the same for chain templates and the underlying driver never receives a &apos;FLOW_CLS_TMPLT_DESTROY&apos; command when a qdisc is deleted. This results in a memory leak [1] which can be reproduced using [2]. Fix by introducing a &apos;tmplt_reoffload&apos; operation and have the stack invoke it with the appropriate arguments as part of the replay. Implement the operation in the sole classifier that supports chain templates (flower) by emitting the &apos;FLOW_CLS_TMPLT_{CREATE,DESTROY}&apos; command based on whether a flow offload callback is being bound to a filter block or being unbound from one. As far as I can tell, the issue happens since cited commit which reordered tcf_block_offload_unbind() before tcf_block_flush_all_chains() in __tcf_block_put(). The order cannot be reversed as the filter block is expected to be freed after flushing all the chains. [1] unreferenced object 0xffff888107e28800 (size 2048): comm &quot;tc&quot;, pid 1079, jiffies 4294958525 (age 3074.287s) hex dump (first 32 bytes): b1 a6 7c 11 81 88 ff ff e0 5b b3 10 81 88 ff ff..|......[...... 01 00 00 00 00 00 00 00 e0 aa b0 84 ff ff ff ff................ backtrace: [&lt;ffffffff81c06a68&gt;] __kmem_cache_alloc_node+0x1e8/0x320 [&lt;ffffffff81ab374e&gt;] __kmalloc+0x4e/0x90 [&lt;ffffffff832aec6d&gt;] mlxsw_sp_acl_ruleset_get+0x34d/0x7a0 [&lt;ffffffff832bc195&gt;] mlxsw_sp_flower_tmplt_create+0x145/0x180 [&lt;ffffffff832b2e1a&gt;] mlxsw_sp_flow_block_cb+0x1ea/0x280 [&lt;ffffffff83a10613&gt;] tc_setup_cb_call+0x183/0x340 [&lt;ffffffff83a9f85a&gt;] fl_tmplt_create+0x3da/0x4c0 [&lt;ffffffff83a22435&gt;] tc_ctl_chain+0xa15/0x1170 [&lt;ffffffff838a863c&gt;] rtnetlink_rcv_msg+0x3cc/0xed0 [&lt;ffffffff83ac87f0&gt;] netlink_rcv_skb+0x170/0x440 [&lt;ffffffff83ac6270&gt;] netlink_unicast+0x540/0x820 [&lt;ffffffff83ac6e28&gt;] netlink_sendmsg+0x8d8/0xda0 [&lt;ffffffff83793def&gt;] ____sys_sendmsg+0x30f/0xa80 [&lt;ffffffff8379d29a&gt;] ___sys_sendmsg+0x13a/0x1e0 [&lt;ffffffff8379d50c&gt;] __sys_sendmsg+0x11c/0x1f0 [&lt;ffffffff843b9ce0&gt;] do_syscall_64+0x40/0xe0 unreferenced object 0xffff88816d2c0400 (size 1024): comm &quot;tc&quot;, pid 1079, jiffies 4294958525 (age 3074.287s) hex dump (first 32 bytes): 40 00 00 00 00 00 00 00 57 f6 38 be 00 00 00 [email protected]..... 10 04 2c 6d 81 88 ff ff 10 04 2c 6d 81 88 ff ff..,m......,m.... backtrace: [&lt;ffffffff81c06a68&gt;] __kmem_cache_alloc_node+0x1e8/0x320 [&lt;ffffffff81ab36c1&gt;] __kmalloc_node+0x51/0x90 [&lt;ffffffff81a8ed96&gt;] kvmalloc_node+0xa6/0x1f0 [&lt;ffffffff82827d03&gt;] bucket_table_alloc.isra.0+0x83/0x460 [&lt;ffffffff82828d2b&gt;] rhashtable_init+0x43b/0x7c0 [&lt;ffffffff832aed48&gt;] mlxsw_sp_acl_ruleset_get+0x428/0x7a0 [&lt;ffffffff832bc195&gt;] mlxsw_sp_flower_tmplt_create+0x145/0x180 [&lt;ffffffff832b2e1a&gt;] mlxsw_sp_flow_block_cb+0x1ea/0x280 [&lt;ffffffff83a10613&gt;] tc_setup_cb_call+0x183/0x340 [&lt;ffffffff83a9f85a&gt;] fl_tmplt_create+0x3da/0x4c0 [&lt;ffffffff83a22435&gt;] tc_ctl_chain+0xa15/0x1170 [&lt;ffffffff838a863c&gt;] rtnetlink_rcv_msg+0x3cc/0xed0 [&lt;ffffffff83ac87f0&gt;] netlink_rcv_skb+0x170/0x440 [&lt;ffffffff83ac6270&gt;] netlink_unicast+0x540/0x820 [&lt;ffffffff83ac6e28&gt;] netlink_sendmsg+0x8d8/0xda0 [&lt;ffffffff83793def&gt;] ____sys_sendmsg+0x30f/0xa80 [2] # tc qdisc add dev swp1 clsact # tc chain add dev swp1 ingress proto ip chain 1 flower dst_ip 0.0.0.0/32 # tc qdisc del dev ---truncated--- Solution(s) oracle-linux-upgrade-kernel References https://attackerkb.com/topics/cve-2024-26669 CVE - 2024-26669 ELSA-2024-5101

Huawei EulerOS: CVE-2024-26659: kernel security update Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 04/02/2024 Created 10/09/2024 Added 10/08/2024 Modified 10/08/2024 Description In the Linux kernel, the following vulnerability has been resolved: xhci: handle isoc Babble and Buffer Overrun events properly xHCI 4.9 explicitly forbids assuming that the xHC has released its ownership of a multi-TRB TD when it reports an error on one of the early TRBs. Yet the driver makes such assumption and releases the TD, allowing the remaining TRBs to be freed or overwritten by new TDs. The xHC should also report completion of the final TRB due to its IOC flag being set by us, regardless of prior errors. This event cannot be recognized if the TD has already been freed earlier, resulting in "Transfer event TRB DMA ptr not part of current TD" error message. Fix this by reusing the logic for processing isoc Transaction Errors. This also handles hosts which fail to report the final completion. Fix transfer length reporting on Babble errors. They may be caused by device malfunction, no guarantee that the buffer has been filled. Solution(s) huawei-euleros-2_0_sp12-upgrade-bpftool huawei-euleros-2_0_sp12-upgrade-kernel huawei-euleros-2_0_sp12-upgrade-kernel-abi-stablelists huawei-euleros-2_0_sp12-upgrade-kernel-tools huawei-euleros-2_0_sp12-upgrade-kernel-tools-libs huawei-euleros-2_0_sp12-upgrade-python3-perf References https://attackerkb.com/topics/cve-2024-26659 CVE - 2024-26659 EulerOS-SA-2024-2240

Oracle Linux: CVE-2024-26675: ELSA-2024-12606: Unbreakable Enterprise kernel security update (IMPORTANT) (Multiple Advisories) Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 04/02/2024 Created 07/04/2024 Added 07/03/2024 Modified 01/23/2025 Description In the Linux kernel, the following vulnerability has been resolved: ppp_async: limit MRU to 64K syzbot triggered a warning [1] in __alloc_pages(): WARN_ON_ONCE_GFP(order &gt; MAX_PAGE_ORDER, gfp) Willem fixed a similar issue in commit c0a2a1b0d631 (&quot;ppp: limit MRU to 64K&quot;) Adopt the same sanity check for ppp_async_ioctl(PPPIOCSMRU) [1]: WARNING: CPU: 1 PID: 11 at mm/page_alloc.c:4543 __alloc_pages+0x308/0x698 mm/page_alloc.c:4543 Modules linked in: CPU: 1 PID: 11 Comm: kworker/u4:0 Not tainted 6.8.0-rc2-syzkaller-g41bccc98fb79 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023 Workqueue: events_unbound flush_to_ldisc pstate: 204000c5 (nzCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : __alloc_pages+0x308/0x698 mm/page_alloc.c:4543 lr : __alloc_pages+0xc8/0x698 mm/page_alloc.c:4537 sp : ffff800093967580 x29: ffff800093967660 x28: ffff8000939675a0 x27: dfff800000000000 x26: ffff70001272ceb4 x25: 0000000000000000 x24: ffff8000939675c0 x23: 0000000000000000 x22: 0000000000060820 x21: 1ffff0001272ceb8 x20: ffff8000939675e0 x19: 0000000000000010 x18: ffff800093967120 x17: ffff800083bded5c x16: ffff80008ac97500 x15: 0000000000000005 x14: 1ffff0001272cebc x13: 0000000000000000 x12: 0000000000000000 x11: ffff70001272cec1 x10: 1ffff0001272cec0 x9 : 0000000000000001 x8 : ffff800091c91000 x7 : 0000000000000000 x6 : 000000000000003f x5 : 00000000ffffffff x4 : 0000000000000000 x3 : 0000000000000020 x2 : 0000000000000008 x1 : 0000000000000000 x0 : ffff8000939675e0 Call trace: __alloc_pages+0x308/0x698 mm/page_alloc.c:4543 __alloc_pages_node include/linux/gfp.h:238 [inline] alloc_pages_node include/linux/gfp.h:261 [inline] __kmalloc_large_node+0xbc/0x1fc mm/slub.c:3926 __do_kmalloc_node mm/slub.c:3969 [inline] __kmalloc_node_track_caller+0x418/0x620 mm/slub.c:4001 kmalloc_reserve+0x17c/0x23c net/core/skbuff.c:590 __alloc_skb+0x1c8/0x3d8 net/core/skbuff.c:651 __netdev_alloc_skb+0xb8/0x3e8 net/core/skbuff.c:715 netdev_alloc_skb include/linux/skbuff.h:3235 [inline] dev_alloc_skb include/linux/skbuff.h:3248 [inline] ppp_async_input drivers/net/ppp/ppp_async.c:863 [inline] ppp_asynctty_receive+0x588/0x186c drivers/net/ppp/ppp_async.c:341 tty_ldisc_receive_buf+0x12c/0x15c drivers/tty/tty_buffer.c:390 tty_port_default_receive_buf+0x74/0xac drivers/tty/tty_port.c:37 receive_buf drivers/tty/tty_buffer.c:444 [inline] flush_to_ldisc+0x284/0x6e4 drivers/tty/tty_buffer.c:494 process_one_work+0x694/0x1204 kernel/workqueue.c:2633 process_scheduled_works kernel/workqueue.c:2706 [inline] worker_thread+0x938/0xef4 kernel/workqueue.c:2787 kthread+0x288/0x310 kernel/kthread.c:388 ret_from_fork+0x10/0x20 arch/arm64/kernel/entry.S:860 Solution(s) oracle-linux-upgrade-kernel oracle-linux-upgrade-kernel-uek References https://attackerkb.com/topics/cve-2024-26675 CVE - 2024-26675 ELSA-2024-12606 ELSA-2024-4211

Amazon Linux 2023: CVE-2024-26681: Important priority package update for kernel Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 04/02/2024 Created 02/14/2025 Added 02/14/2025 Modified 02/14/2025 Description In the Linux kernel, the following vulnerability has been resolved: netdevsim: avoid potential loop in nsim_dev_trap_report_work() Many syzbot reports include the following trace [1] If nsim_dev_trap_report_work() can not grab the mutex, it should rearm itself at least one jiffie later. [1] Sending NMI from CPU 1 to CPUs 0: NMI backtrace for cpu 0 CPU: 0 PID: 32383 Comm: kworker/0:2 Not tainted 6.8.0-rc2-syzkaller-00031-g861c0981648f #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023 Workqueue: events nsim_dev_trap_report_work RIP: 0010:bytes_is_nonzero mm/kasan/generic.c:89 [inline] RIP: 0010:memory_is_nonzero mm/kasan/generic.c:104 [inline] RIP: 0010:memory_is_poisoned_n mm/kasan/generic.c:129 [inline] RIP: 0010:memory_is_poisoned mm/kasan/generic.c:161 [inline] RIP: 0010:check_region_inline mm/kasan/generic.c:180 [inline] RIP: 0010:kasan_check_range+0x101/0x190 mm/kasan/generic.c:189 Code: 07 49 39 d1 75 0a 45 3a 11 b8 01 00 00 00 7c 0b 44 89 c2 e8 21 ed ff ff 83 f0 01 5b 5d 41 5c c3 48 85 d2 74 4f 48 01 ea eb 09 &lt;48&gt; 83 c0 01 48 39 d0 74 41 80 38 00 74 f2 eb b6 41 bc 08 00 00 00 RSP: 0018:ffffc90012dcf998 EFLAGS: 00000046 RAX: fffffbfff258af1e RBX: fffffbfff258af1f RCX: ffffffff8168eda3 RDX: fffffbfff258af1f RSI: 0000000000000004 RDI: ffffffff92c578f0 RBP: fffffbfff258af1e R08: 0000000000000000 R09: fffffbfff258af1e R10: ffffffff92c578f3 R11: ffffffff8acbcbc0 R12: 0000000000000002 R13: ffff88806db38400 R14: 1ffff920025b9f42 R15: ffffffff92c578e8 FS:0000000000000000(0000) GS:ffff8880b9800000(0000) knlGS:0000000000000000 CS:0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000c00994e078 CR3: 000000002c250000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: &lt;NMI&gt; &lt;/NMI&gt; &lt;TASK&gt; instrument_atomic_read include/linux/instrumented.h:68 [inline] atomic_read include/linux/atomic/atomic-instrumented.h:32 [inline] queued_spin_is_locked include/asm-generic/qspinlock.h:57 [inline] debug_spin_unlock kernel/locking/spinlock_debug.c:101 [inline] do_raw_spin_unlock+0x53/0x230 kernel/locking/spinlock_debug.c:141 __raw_spin_unlock_irqrestore include/linux/spinlock_api_smp.h:150 [inline] _raw_spin_unlock_irqrestore+0x22/0x70 kernel/locking/spinlock.c:194 debug_object_activate+0x349/0x540 lib/debugobjects.c:726 debug_work_activate kernel/workqueue.c:578 [inline] insert_work+0x30/0x230 kernel/workqueue.c:1650 __queue_work+0x62e/0x11d0 kernel/workqueue.c:1802 __queue_delayed_work+0x1bf/0x270 kernel/workqueue.c:1953 queue_delayed_work_on+0x106/0x130 kernel/workqueue.c:1989 queue_delayed_work include/linux/workqueue.h:563 [inline] schedule_delayed_work include/linux/workqueue.h:677 [inline] nsim_dev_trap_report_work+0x9c0/0xc80 drivers/net/netdevsim/dev.c:842 process_one_work+0x886/0x15d0 kernel/workqueue.c:2633 process_scheduled_works kernel/workqueue.c:2706 [inline] worker_thread+0x8b9/0x1290 kernel/workqueue.c:2787 kthread+0x2c6/0x3a0 kernel/kthread.c:388 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:242 &lt;/TASK&gt; Solution(s) amazon-linux-2023-upgrade-bpftool amazon-linux-2023-upgrade-bpftool-debuginfo amazon-linux-2023-upgrade-kernel amazon-linux-2023-upgrade-kernel-debuginfo amazon-linux-2023-upgrade-kernel-debuginfo-common-aarch64 amazon-linux-2023-upgrade-kernel-debuginfo-common-x86-64 amazon-linux-2023-upgrade-kernel-devel amazon-linux-2023-upgrade-kernel-headers amazon-linux-2023-upgrade-kernel-libbpf amazon-linux-2023-upgrade-kernel-libbpf-devel amazon-linux-2023-upgrade-kernel-libbpf-static amazon-linux-2023-upgrade-kernel-livepatch-6-1-79-99-164 amazon-linux-2023-upgrade-kernel-modules-extra amazon-linux-2023-upgrade-kernel-modules-extra-common amazon-linux-2023-upgrade-kernel-tools amazon-linux-2023-upgrade-kernel-tools-debuginfo amazon-linux-2023-upgrade-kernel-tools-devel amazon-linux-2023-upgrade-perf amazon-linux-2023-upgrade-perf-debuginfo amazon-linux-2023-upgrade-python3-perf amazon-linux-2023-upgrade-python3-perf-debuginfo References https://attackerkb.com/topics/cve-2024-26681 CVE - 2024-26681 https://alas.aws.amazon.com/AL2023/ALAS-2024-549.html

SUSE: CVE-2024-26660: SUSE Linux Security Advisory Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 04/02/2024 Created 05/06/2024 Added 05/06/2024 Modified 05/16/2024 Description In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Implement bounds check for stream encoder creation in DCN301 'stream_enc_regs' array is an array of dcn10_stream_enc_registers structures. The array is initialized with four elements, corresponding to the four calls to stream_enc_regs() in the array initializer. This means that valid indices for this array are 0, 1, 2, and 3. The error message 'stream_enc_regs' 4 <= 5 below, is indicating that there is an attempt to access this array with an index of 5, which is out of bounds. This could lead to undefined behavior Here, eng_id is used as an index to access the stream_enc_regs array. If eng_id is 5, this would result in an out-of-bounds access on the stream_enc_regs array. Thus fixing Buffer overflow error in dcn301_stream_encoder_create reported by Smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/resource/dcn301/dcn301_resource.c:1011 dcn301_stream_encoder_create() error: buffer overflow 'stream_enc_regs' 4 <= 5 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-26660 CVE - 2024-26660