ISHACK AI BOT

Debian: CVE-2024-47735: linux, linux-6.1 -- security update Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 10/21/2024 Created 11/12/2024 Added 11/11/2024 Modified 01/28/2025 Description In the Linux kernel, the following vulnerability has been resolved: RDMA/hns: Fix spin_unlock_irqrestore() called with IRQs enabled Fix missuse of spin_lock_irq()/spin_unlock_irq() when spin_lock_irqsave()/spin_lock_irqrestore() was hold. This was discovered through the lock debugging, and the corresponding log is as follows: raw_local_irq_restore() called with IRQs enabled WARNING: CPU: 96 PID: 2074 at kernel/locking/irqflag-debug.c:10 warn_bogus_irq_restore+0x30/0x40 ... Call trace: warn_bogus_irq_restore+0x30/0x40 _raw_spin_unlock_irqrestore+0x84/0xc8 add_qp_to_list+0x11c/0x148 [hns_roce_hw_v2] hns_roce_create_qp_common.constprop.0+0x240/0x780 [hns_roce_hw_v2] hns_roce_create_qp+0x98/0x160 [hns_roce_hw_v2] create_qp+0x138/0x258 ib_create_qp_kernel+0x50/0xe8 create_mad_qp+0xa8/0x128 ib_mad_port_open+0x218/0x448 ib_mad_init_device+0x70/0x1f8 add_client_context+0xfc/0x220 enable_device_and_get+0xd0/0x140 ib_register_device.part.0+0xf4/0x1c8 ib_register_device+0x34/0x50 hns_roce_register_device+0x174/0x3d0 [hns_roce_hw_v2] hns_roce_init+0xfc/0x2c0 [hns_roce_hw_v2] __hns_roce_hw_v2_init_instance+0x7c/0x1d0 [hns_roce_hw_v2] hns_roce_hw_v2_init_instance+0x9c/0x180 [hns_roce_hw_v2] Solution(s) debian-upgrade-linux debian-upgrade-linux-6-1 References https://attackerkb.com/topics/cve-2024-47735 CVE - 2024-47735 DLA-4008-1

Huawei EulerOS: CVE-2024-49861: kernel security update Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 10/21/2024 Created 02/12/2025 Added 02/11/2025 Modified 02/11/2025 Description In the Linux kernel, the following vulnerability has been resolved: bpf: Fix helper writes to read-only maps Lonial found an issue that despite user- and BPF-side frozen BPF map (like in case of .rodata), it was still possible to write into it from a BPF program side through specific helpers having ARG_PTR_TO_{LONG,INT} as arguments. In check_func_arg() when the argument is as mentioned, the meta->raw_mode is never set. Later, check_helper_mem_access(), under the case of PTR_TO_MAP_VALUE as register base type, it assumes BPF_READ for the subsequent call to check_map_access_type() and given the BPF map is read-only it succeeds. The helpers really need to be annotated as ARG_PTR_TO_{LONG,INT} | MEM_UNINIT when results are written into them as opposed to read out of them. The latter indicates that it's okay to pass a pointer to uninitialized memory as the memory is written to anyway. However, ARG_PTR_TO_{LONG,INT} is a special case of ARG_PTR_TO_FIXED_SIZE_MEM just with additional alignment requirement. So it is better to just get rid of the ARG_PTR_TO_{LONG,INT} special cases altogether and reuse the fixed size memory types. For this, add MEM_ALIGNED to additionally ensure alignment given these helpers write directly into the args via *<ptr> = val. The .arg*_size has been initialized reflecting the actual sizeof(*<ptr>). MEM_ALIGNED can only be used in combination with MEM_FIXED_SIZE annotated argument types, since in !MEM_FIXED_SIZE cases the verifier does not know the buffer size a priori and therefore cannot blindly write *<ptr> = val. Solution(s) huawei-euleros-2_0_sp11-upgrade-bpftool huawei-euleros-2_0_sp11-upgrade-kernel huawei-euleros-2_0_sp11-upgrade-kernel-abi-stablelists huawei-euleros-2_0_sp11-upgrade-kernel-tools huawei-euleros-2_0_sp11-upgrade-kernel-tools-libs huawei-euleros-2_0_sp11-upgrade-python3-perf References https://attackerkb.com/topics/cve-2024-49861 CVE - 2024-49861 EulerOS-SA-2025-1159

Huawei EulerOS: CVE-2022-49014: kernel security update Severity 7 CVSS (AV:L/AC:L/Au:S/C:C/I:C/A:C) Published 10/21/2024 Created 01/16/2025 Added 01/15/2025 Modified 01/28/2025 Description In the Linux kernel, the following vulnerability has been resolved: net: tun: Fix use-after-free in tun_detach() syzbot reported use-after-free in tun_detach() [1].This causes call trace like below: ================================================================== BUG: KASAN: use-after-free in notifier_call_chain+0x1ee/0x200 kernel/notifier.c:75 Read of size 8 at addr ffff88807324e2a8 by task syz-executor.0/3673 CPU: 0 PID: 3673 Comm: syz-executor.0 Not tainted 6.1.0-rc5-syzkaller-00044-gcc675d22e422 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xd1/0x138 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:284 [inline] print_report+0x15e/0x461 mm/kasan/report.c:395 kasan_report+0xbf/0x1f0 mm/kasan/report.c:495 notifier_call_chain+0x1ee/0x200 kernel/notifier.c:75 call_netdevice_notifiers_info+0x86/0x130 net/core/dev.c:1942 call_netdevice_notifiers_extack net/core/dev.c:1983 [inline] call_netdevice_notifiers net/core/dev.c:1997 [inline] netdev_wait_allrefs_any net/core/dev.c:10237 [inline] netdev_run_todo+0xbc6/0x1100 net/core/dev.c:10351 tun_detach drivers/net/tun.c:704 [inline] tun_chr_close+0xe4/0x190 drivers/net/tun.c:3467 __fput+0x27c/0xa90 fs/file_table.c:320 task_work_run+0x16f/0x270 kernel/task_work.c:179 exit_task_work include/linux/task_work.h:38 [inline] do_exit+0xb3d/0x2a30 kernel/exit.c:820 do_group_exit+0xd4/0x2a0 kernel/exit.c:950 get_signal+0x21b1/0x2440 kernel/signal.c:2858 arch_do_signal_or_restart+0x86/0x2300 arch/x86/kernel/signal.c:869 exit_to_user_mode_loop kernel/entry/common.c:168 [inline] exit_to_user_mode_prepare+0x15f/0x250 kernel/entry/common.c:203 __syscall_exit_to_user_mode_work kernel/entry/common.c:285 [inline] syscall_exit_to_user_mode+0x1d/0x50 kernel/entry/common.c:296 do_syscall_64+0x46/0xb0 arch/x86/entry/common.c:86 entry_SYSCALL_64_after_hwframe+0x63/0xcd The cause of the issue is that sock_put() from __tun_detach() drops last reference count for struct net, and then notifier_call_chain() from netdev_state_change() accesses that struct net. This patch fixes the issue by calling sock_put() from tun_detach() after all necessary accesses for the struct net has done. 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-2022-49014 CVE - 2022-49014 EulerOS-SA-2025-1057

OneDev Unauthenticated Arbitrary File Read Disclosed 10/19/2024 Created 01/07/2025 Description This module exploits an unauthenticated arbitrary file read vulnerability (CVE-2024-45309), which affects OneDev versions <= 11.0.8. To exploit this vulnerability, a valid OneDev project name is required. If anonymous access is enabled on the OneDev server, any visitor can view existing projects without authentication. However, when anonymous access is disabled, an attacker who lacks prior knowledge of existing project names can use a brute-force approach. By providing a user-supplied wordlist, the module may be able to guess a valid project name and subsequently exploit the vulnerability. Author(s) vultza Siebene Development Source Code History

Microsoft Edge Chromium: CVE-2024-43587 Severity 9 CVSS (AV:N/AC:M/Au:N/C:C/I:C/A:C) Published 10/18/2024 Created 10/18/2024 Added 10/18/2024 Modified 01/28/2025 Description Microsoft Edge (Chromium-based) Remote Code Execution Vulnerability Solution(s) microsoft-edge-upgrade-latest References https://attackerkb.com/topics/cve-2024-43587 CVE - 2024-43587 https://msrc.microsoft.com/update-guide/vulnerability/CVE-2024-43587

Microsoft Edge Chromium: CVE-2024-43578 Severity 9 CVSS (AV:N/AC:M/Au:N/C:C/I:C/A:P) Published 10/18/2024 Created 10/18/2024 Added 10/18/2024 Modified 01/28/2025 Description Microsoft Edge (Chromium-based) Remote Code Execution Vulnerability Solution(s) microsoft-edge-upgrade-latest References https://attackerkb.com/topics/cve-2024-43578 CVE - 2024-43578 https://msrc.microsoft.com/update-guide/vulnerability/CVE-2024-43578

Microsoft Edge Chromium: CVE-2024-49023 Severity 5 CVSS (AV:N/AC:H/Au:N/C:C/I:N/A:N) Published 10/18/2024 Created 10/18/2024 Added 10/18/2024 Modified 01/28/2025 Description Microsoft Edge (Chromium-based) Remote Code Execution Vulnerability Solution(s) microsoft-edge-upgrade-latest References https://attackerkb.com/topics/cve-2024-49023 CVE - 2024-49023 https://msrc.microsoft.com/update-guide/vulnerability/CVE-2024-49023

Huawei EulerOS: CVE-2024-47692: kernel security update Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 10/21/2024 Created 02/12/2025 Added 02/11/2025 Modified 02/11/2025 Description In the Linux kernel, the following vulnerability has been resolved: nfsd: return -EINVAL when namelen is 0 When we have a corrupted main.sqlite in /var/lib/nfs/nfsdcld/, it may result in namelen being 0, which will cause memdup_user() to return ZERO_SIZE_PTR. When we access the name.data that has been assigned the value of ZERO_SIZE_PTR in nfs4_client_to_reclaim(), null pointer dereference is triggered. [ T1205] ================================================================== [ T1205] BUG: KASAN: null-ptr-deref in nfs4_client_to_reclaim+0xe9/0x260 [ T1205] Read of size 1 at addr 0000000000000010 by task nfsdcld/1205 [ T1205] [ T1205] CPU: 11 PID: 1205 Comm: nfsdcld Not tainted 5.10.0-00003-g2c1423731b8d #406 [ T1205] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ?-20190727_073836-buildvm-ppc64le-16.ppc.fedoraproject.org-3.fc31 04/01/2014 [ T1205] Call Trace: [ T1205]dump_stack+0x9a/0xd0 [ T1205]? nfs4_client_to_reclaim+0xe9/0x260 [ T1205]__kasan_report.cold+0x34/0x84 [ T1205]? nfs4_client_to_reclaim+0xe9/0x260 [ T1205]kasan_report+0x3a/0x50 [ T1205]nfs4_client_to_reclaim+0xe9/0x260 [ T1205]? nfsd4_release_lockowner+0x410/0x410 [ T1205]cld_pipe_downcall+0x5ca/0x760 [ T1205]? nfsd4_cld_tracking_exit+0x1d0/0x1d0 [ T1205]? down_write_killable_nested+0x170/0x170 [ T1205]? avc_policy_seqno+0x28/0x40 [ T1205]? selinux_file_permission+0x1b4/0x1e0 [ T1205]rpc_pipe_write+0x84/0xb0 [ T1205]vfs_write+0x143/0x520 [ T1205]ksys_write+0xc9/0x170 [ T1205]? __ia32_sys_read+0x50/0x50 [ T1205]? ktime_get_coarse_real_ts64+0xfe/0x110 [ T1205]? ktime_get_coarse_real_ts64+0xa2/0x110 [ T1205]do_syscall_64+0x33/0x40 [ T1205]entry_SYSCALL_64_after_hwframe+0x67/0xd1 [ T1205] RIP: 0033:0x7fdbdb761bc7 [ T1205] Code: 0f 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 514 [ T1205] RSP: 002b:00007fff8c4b7248 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 [ T1205] RAX: ffffffffffffffda RBX: 000000000000042b RCX: 00007fdbdb761bc7 [ T1205] RDX: 000000000000042b RSI: 00007fff8c4b75f0 RDI: 0000000000000008 [ T1205] RBP: 00007fdbdb761bb0 R08: 0000000000000000 R09: 0000000000000001 [ T1205] R10: 0000000000000000 R11: 0000000000000246 R12: 000000000000042b [ T1205] R13: 0000000000000008 R14: 00007fff8c4b75f0 R15: 0000000000000000 [ T1205] ================================================================== Fix it by checking namelen. 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-47692 CVE - 2024-47692 EulerOS-SA-2025-1192

Debian: CVE-2024-47692: linux, linux-6.1 -- security update Severity 7 CVSS (AV:N/AC:L/Au:S/C:N/I:N/A:C) Published 10/21/2024 Created 11/12/2024 Added 11/11/2024 Modified 01/28/2025 Description In the Linux kernel, the following vulnerability has been resolved: nfsd: return -EINVAL when namelen is 0 When we have a corrupted main.sqlite in /var/lib/nfs/nfsdcld/, it may result in namelen being 0, which will cause memdup_user() to return ZERO_SIZE_PTR. When we access the name.data that has been assigned the value of ZERO_SIZE_PTR in nfs4_client_to_reclaim(), null pointer dereference is triggered. [ T1205] ================================================================== [ T1205] BUG: KASAN: null-ptr-deref in nfs4_client_to_reclaim+0xe9/0x260 [ T1205] Read of size 1 at addr 0000000000000010 by task nfsdcld/1205 [ T1205] [ T1205] CPU: 11 PID: 1205 Comm: nfsdcld Not tainted 5.10.0-00003-g2c1423731b8d #406 [ T1205] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ?-20190727_073836-buildvm-ppc64le-16.ppc.fedoraproject.org-3.fc31 04/01/2014 [ T1205] Call Trace: [ T1205]dump_stack+0x9a/0xd0 [ T1205]? nfs4_client_to_reclaim+0xe9/0x260 [ T1205]__kasan_report.cold+0x34/0x84 [ T1205]? nfs4_client_to_reclaim+0xe9/0x260 [ T1205]kasan_report+0x3a/0x50 [ T1205]nfs4_client_to_reclaim+0xe9/0x260 [ T1205]? nfsd4_release_lockowner+0x410/0x410 [ T1205]cld_pipe_downcall+0x5ca/0x760 [ T1205]? nfsd4_cld_tracking_exit+0x1d0/0x1d0 [ T1205]? down_write_killable_nested+0x170/0x170 [ T1205]? avc_policy_seqno+0x28/0x40 [ T1205]? selinux_file_permission+0x1b4/0x1e0 [ T1205]rpc_pipe_write+0x84/0xb0 [ T1205]vfs_write+0x143/0x520 [ T1205]ksys_write+0xc9/0x170 [ T1205]? __ia32_sys_read+0x50/0x50 [ T1205]? ktime_get_coarse_real_ts64+0xfe/0x110 [ T1205]? ktime_get_coarse_real_ts64+0xa2/0x110 [ T1205]do_syscall_64+0x33/0x40 [ T1205]entry_SYSCALL_64_after_hwframe+0x67/0xd1 [ T1205] RIP: 0033:0x7fdbdb761bc7 [ T1205] Code: 0f 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 514 [ T1205] RSP: 002b:00007fff8c4b7248 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 [ T1205] RAX: ffffffffffffffda RBX: 000000000000042b RCX: 00007fdbdb761bc7 [ T1205] RDX: 000000000000042b RSI: 00007fff8c4b75f0 RDI: 0000000000000008 [ T1205] RBP: 00007fdbdb761bb0 R08: 0000000000000000 R09: 0000000000000001 [ T1205] R10: 0000000000000000 R11: 0000000000000246 R12: 000000000000042b [ T1205] R13: 0000000000000008 R14: 00007fff8c4b75f0 R15: 0000000000000000 [ T1205] ================================================================== Fix it by checking namelen. Solution(s) debian-upgrade-linux debian-upgrade-linux-6-1 References https://attackerkb.com/topics/cve-2024-47692 CVE - 2024-47692 DLA-4008-1

Huawei EulerOS: CVE-2024-49954: kernel security update Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 10/21/2024 Created 02/12/2025 Added 02/11/2025 Modified 02/11/2025 Description In the Linux kernel, the following vulnerability has been resolved: static_call: Replace pointless WARN_ON() in static_call_module_notify() static_call_module_notify() triggers a WARN_ON(), when memory allocation fails in __static_call_add_module(). That's not really justified, because the failure case must be correctly handled by the well known call chain and the error code is passed through to the initiating userspace application. A memory allocation fail is not a fatal problem, but the WARN_ON() takes the machine out when panic_on_warn is set. Replace it with a pr_warn(). 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-49954 CVE - 2024-49954 EulerOS-SA-2025-1192

Huawei EulerOS: CVE-2024-49949: kernel security update Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 10/21/2024 Created 02/12/2025 Added 02/11/2025 Modified 02/11/2025 Description In the Linux kernel, the following vulnerability has been resolved: net: avoid potential underflow in qdisc_pkt_len_init() with UFO After commit 7c6d2ecbda83 ("net: be more gentle about silly gso requests coming from user") virtio_net_hdr_to_skb() had sanity check to detect malicious attempts from user space to cook a bad GSO packet. Then commit cf9acc90c80ec ("net: virtio_net_hdr_to_skb: count transport header in UFO") while fixing one issue, allowed user space to cook a GSO packet with the following characteristic : IPv4 SKB_GSO_UDP, gso_size=3, skb->len = 28. When this packet arrives in qdisc_pkt_len_init(), we end up with hdr_len = 28 (IPv4 header + UDP header), matching skb->len Then the following sets gso_segs to 0 : gso_segs = DIV_ROUND_UP(skb->len - hdr_len, shinfo->gso_size); Then later we set qdisc_skb_cb(skb)->pkt_len to back to zero :/ qdisc_skb_cb(skb)->pkt_len += (gso_segs - 1) * hdr_len; This leads to the following crash in fq_codel [1] qdisc_pkt_len_init() is best effort, we only want an estimation of the bytes sent on the wire, not crashing the kernel. This patch is fixing this particular issue, a following one adds more sanity checks for another potential bug. [1] [ 70.724101] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ 70.724561] #PF: supervisor read access in kernel mode [ 70.724561] #PF: error_code(0x0000) - not-present page [ 70.724561] PGD 10ac61067 P4D 10ac61067 PUD 107ee2067 PMD 0 [ 70.724561] Oops: Oops: 0000 [#1] SMP NOPTI [ 70.724561] CPU: 11 UID: 0 PID: 2163 Comm: b358537762 Not tainted 6.11.0-virtme #991 [ 70.724561] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 70.724561] RIP: 0010:fq_codel_enqueue (net/sched/sch_fq_codel.c:120 net/sched/sch_fq_codel.c:168 net/sched/sch_fq_codel.c:230) sch_fq_codel [ 70.724561] Code: 24 08 49 c1 e1 06 44 89 7c 24 18 45 31 ed 45 31 c0 31 ff 89 44 24 14 4c 03 8b 90 01 00 00 eb 04 39 ca 73 37 4d 8b 39 83 c7 01 <49> 8b 17 49 89 11 41 8b 57 28 45 8b 5f 34 49 c7 07 00 00 00 00 49 All code ======== 0: 24 08 and$0x8,%al 2: 49 c1 e1 06 shl$0x6,%r9 6: 44 89 7c 24 18 mov%r15d,0x18(%rsp) b: 45 31 ed xor%r13d,%r13d e: 45 31 c0 xor%r8d,%r8d 11: 31 ff xor%edi,%edi 13: 89 44 24 14 mov%eax,0x14(%rsp) 17: 4c 03 8b 90 01 00 00 add0x190(%rbx),%r9 1e: eb 04 jmp0x24 20: 39 ca cmp%ecx,%edx 22: 73 37 jae0x5b 24: 4d 8b 39 mov(%r9),%r15 27: 83 c7 01 add$0x1,%edi 2a:* 49 8b 17 mov(%r15),%rdx <-- trapping instruction 2d: 49 89 11 mov%rdx,(%r9) 30: 41 8b 57 28 mov0x28(%r15),%edx 34: 45 8b 5f 34 mov0x34(%r15),%r11d 38: 49 c7 07 00 00 00 00 movq $0x0,(%r15) 3f: 49 rex.WB Code starting with the faulting instruction =========================================== 0: 49 8b 17 mov(%r15),%rdx 3: 49 89 11 mov%rdx,(%r9) 6: 41 8b 57 28 mov0x28(%r15),%edx a: 45 8b 5f 34 mov0x34(%r15),%r11d e: 49 c7 07 00 00 00 00 movq $0x0,(%r15) 15: 49 rex.WB [ 70.724561] RSP: 0018:ffff95ae85e6fb90 EFLAGS: 00000202 [ 70.724561] RAX: 0000000002000000 RBX: ffff95ae841de000 RCX: 0000000000000000 [ 70.724561] RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000001 [ 70.724561] RBP: ffff95ae85e6fbf8 R08: 0000000000000000 R09: ffff95b710a30000 [ 70.724561] R10: 0000000000000000 R11: bdf289445ce31881 R12: ffff95ae85e6fc58 [ 70.724561] R13: 0000000000000000 R14: 0000000000000040 R15: 0000000000000000 [ 70.724561] FS:000000002c5c1380(0000) GS:ffff95bd7fcc0000(0000) knlGS:0000000000000000 [ 70.724561] CS:0010 DS: 0000 ES: 0000 C ---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-49949 CVE - 2024-49949 EulerOS-SA-2025-1192

Oracle Linux: CVE-2024-50036: ELSA-2025-20095: Unbreakable Enterprise kernel security update (IMPORTANT) (Multiple Advisories) Severity 6 CVSS (AV:L/AC:H/Au:S/C:C/I:C/A:C) Published 10/21/2024 Created 02/12/2025 Added 02/10/2025 Modified 02/13/2025 Description In the Linux kernel, the following vulnerability has been resolved: net: do not delay dst_entries_add() in dst_release() dst_entries_add() uses per-cpu data that might be freed at netns dismantle from ip6_route_net_exit() calling dst_entries_destroy() Before ip6_route_net_exit() can be called, we release all the dsts associated with this netns, via calls to dst_release(), which waits an rcu grace period before calling dst_destroy() dst_entries_add() use in dst_destroy() is racy, because dst_entries_destroy() could have been called already. Decrementing the number of dsts must happen sooner. Notes: 1) in CONFIG_XFRM case, dst_destroy() can call dst_release_immediate(child), this might also cause UAF if the child does not have DST_NOCOUNT set. IPSEC maintainers might take a look and see how to address this. 2) There is also discussion about removing this count of dst, which might happen in future kernels. Solution(s) oracle-linux-upgrade-kernel-uek References https://attackerkb.com/topics/cve-2024-50036 CVE - 2024-50036 ELSA-2025-20095

Huawei EulerOS: CVE-2024-47679: kernel security update Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 10/21/2024 Created 02/12/2025 Added 02/11/2025 Modified 02/11/2025 Description In the Linux kernel, the following vulnerability has been resolved: vfs: fix race between evice_inodes() and find_inode()&iput() Hi, all Recently I noticed a bug[1] in btrfs, after digged it into and I believe it'a race in vfs. Let's assume there's a inode (ie ino 261) with i_count 1 is called by iput(), and there's a concurrent thread calling generic_shutdown_super(). cpu0:cpu1: iput() // i_count is 1 ->spin_lock(inode) ->dec i_count to 0 ->iput_final()generic_shutdown_super() ->__inode_add_lru() ->evict_inodes() // cause some reason[2] ->if (atomic_read(inode->i_count)) continue; // return before// inode 261 passed the above check // list_lru_add_obj() // and then schedule out ->spin_unlock() // note here: the inode 261 // was still at sb list and hash list, // and I_FREEING|I_WILL_FREE was not been set btrfs_iget() // after some function calls ->find_inode() // found the above inode 261 ->spin_lock(inode) // check I_FREEING|I_WILL_FREE // and passed ->__iget() ->spin_unlock(inode)// schedule back ->spin_lock(inode) // check (I_NEW|I_FREEING|I_WILL_FREE) flags, // passed and set I_FREEING iput()->spin_unlock(inode) ->spin_lock(inode) ->evict() // dec i_count to 0 ->iput_final() ->spin_unlock() ->evict() Now, we have two threads simultaneously evicting the same inode, which may trigger the BUG(inode->i_state & I_CLEAR) statement both within clear_inode() and iput(). To fix the bug, recheck the inode->i_count after holding i_lock. Because in the most scenarios, the first check is valid, and the overhead of spin_lock() can be reduced. If there is any misunderstanding, please let me know, thanks. [1]: https://lore.kernel.org/linux-btrfs/[email protected]/ [2]: The reason might be 1. SB_ACTIVE was removed or 2. mapping_shrinkable() return false when I reproduced the bug. 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-47679 CVE - 2024-47679 EulerOS-SA-2025-1192

VMware Photon OS: CVE-2024-50022 Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 10/21/2024 Created 01/21/2025 Added 01/20/2025 Modified 02/04/2025 Description In the Linux kernel, the following vulnerability has been resolved: device-dax: correct pgoff align in dax_set_mapping() pgoff should be aligned using ALIGN_DOWN() instead of ALIGN().Otherwise, vmf->address not aligned to fault_size will be aligned to the next alignment, that can result in memory failure getting the wrong address. It's a subtle situation that only can be observed in page_mapped_in_vma() after the page is page fault handled by dev_dax_huge_fault.Generally, there is little chance to perform page_mapped_in_vma in dev-dax's page unless in specific error injection to the dax device to trigger an MCE - memory-failure.In that case, page_mapped_in_vma() will be triggered to determine which task is accessing the failure address and kill that task in the end. We used self-developed dax device (which is 2M aligned mapping) , to perform error injection to random address.It turned out that error injected to non-2M-aligned address was causing endless MCE until panic. Because page_mapped_in_vma() kept resulting wrong address and the task accessing the failure address was never killed properly: [ 3783.719419] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3784.049006] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3784.049190] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3784.448042] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3784.448186] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3784.792026] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3784.792179] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3785.162502] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3785.162633] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3785.461116] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3785.461247] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3785.764730] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3785.764859] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3786.042128] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3786.042259] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3786.464293] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3786.464423] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3786.818090] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3786.818217] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3787.085297] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3787.085424] Memory failure: 0x200c9742: recovery action for dax page: Recovered It took us several weeks to pinpoint this problem, but we eventually used bpftrace to trace the page fault and mce address and successfully identified the issue. Joao added: ; Likely we never reproduce in production because we always pin : device-dax regions in the region align they provide (Qemu does : similarly with prealloc in hugetlb/file backed memory).I think this : bug requires that we touch *unpinned* device-dax regions unaligned to : the device-dax selected alignment (page size i.e.4K/2M/1G) Solution(s) vmware-photon_os_update_tdnf References https://attackerkb.com/topics/cve-2024-50022 CVE - 2024-50022

VMware Photon OS: CVE-2024-50010 Severity 4 CVSS (AV:L/AC:H/Au:S/C:N/I:N/A:C) Published 10/21/2024 Created 01/21/2025 Added 01/20/2025 Modified 02/04/2025 Description In the Linux kernel, the following vulnerability has been resolved: exec: don't WARN for racy path_noexec check Both i_mode and noexec checks wrapped in WARN_ON stem from an artifact of the previous implementation. They used to legitimately check for the condition, but that got moved up in two commits: 633fb6ac3980 ("exec: move S_ISREG() check earlier") 0fd338b2d2cd ("exec: move path_noexec() check earlier") Instead of being removed said checks are WARN_ON'ed instead, which has some debug value. However, the spurious path_noexec check is racy, resulting in unwarranted warnings should someone race with setting the noexec flag. One can note there is more to perm-checking whether execve is allowed and none of the conditions are guaranteed to still hold after they were tested for. Additionally this does not validate whether the code path did any perm checking to begin with -- it will pass if the inode happens to be regular. Keep the redundant path_noexec() check even though it's mindless nonsense checking for guarantee that isn't given so drop the WARN. Reword the commentary and do small tidy ups while here. [brauner: keep redundant path_noexec() check] Solution(s) vmware-photon_os_update_tdnf References https://attackerkb.com/topics/cve-2024-50010 CVE - 2024-50010

VMware Photon OS: CVE-2024-49975 Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 10/21/2024 Created 01/21/2025 Added 01/20/2025 Modified 02/04/2025 Description In the Linux kernel, the following vulnerability has been resolved: uprobes: fix kernel info leak via "[uprobes]" vma xol_add_vma() maps the uninitialized page allocated by __create_xol_area() into userspace. On some architectures (x86) this memory is readable even without VM_READ, VM_EXEC results in the same pgprot_t as VM_EXEC|VM_READ, although this doesn't really matter, debugger can read this memory anyway. Solution(s) vmware-photon_os_update_tdnf References https://attackerkb.com/topics/cve-2024-49975 CVE - 2024-49975

VMware Photon OS: CVE-2024-49973 Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 10/21/2024 Created 01/21/2025 Added 01/20/2025 Modified 02/04/2025 Description In the Linux kernel, the following vulnerability has been resolved: r8169: add tally counter fields added with RTL8125 RTL8125 added fields to the tally counter, what may result in the chip dma'ing these new fields to unallocated memory. Therefore make sure that the allocated memory area is big enough to hold all of the tally counter values, even if we use only parts of it. Solution(s) vmware-photon_os_update_tdnf References https://attackerkb.com/topics/cve-2024-49973 CVE - 2024-49973

VMware Photon OS: CVE-2024-49955 Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 10/21/2024 Created 01/21/2025 Added 01/20/2025 Modified 02/04/2025 Description In the Linux kernel, the following vulnerability has been resolved: ACPI: battery: Fix possible crash when unregistering a battery hook When a battery hook returns an error when adding a new battery, then the battery hook is automatically unregistered. However the battery hook provider cannot know that, so it will later call battery_hook_unregister() on the already unregistered battery hook, resulting in a crash. Fix this by using the list head to mark already unregistered battery hooks as already being unregistered so that they can be ignored by battery_hook_unregister(). Solution(s) vmware-photon_os_update_tdnf References https://attackerkb.com/topics/cve-2024-49955 CVE - 2024-49955

Ivanti Pulse Connect Secure: Security Advisory Ivanti Connect Secure and Policy Secure (CVE-2024-37404) Severity 8 CVSS (AV:N/AC:L/Au:M/C:C/I:C/A:C) Published 10/18/2024 Created 10/10/2024 Added 10/18/2024 Modified 02/12/2025 Description Improper Input Validation in the admin portal of Ivanti Connect Secure before 22.7R2.1 and 9.1R18.9, or Ivanti Policy Secure before 22.7R1.1 allows a remote authenticated attacker to achieve remote code execution. Solution(s) pulse-secure-pulse-connect-secure-upgrade-22_7r2_1 pulse-secure-pulse-connect-secure-upgrade-9_1r18_9 References https://attackerkb.com/topics/cve-2024-37404 CVE - 2024-37404 https://forums.ivanti.com/s/article/Security-Advisory-Ivanti-Connect-Secure-and-Policy-Secure-CVE-2024-37404?language=en_US

Oracle Linux: CVE-2024-10041: ELSA-2024-10379:pam security update (IMPORTANT) (Multiple Advisories) Severity 4 CVSS (AV:L/AC:H/Au:S/C:C/I:N/A:N) Published 10/18/2024 Created 12/10/2024 Added 11/27/2024 Modified 01/07/2025 Description A vulnerability was found in PAM. The secret information is stored in memory, where the attacker can trigger the victim program to execute by sending characters to its standard input (stdin). As this occurs, the attacker can train the branch predictor to execute an ROP chain speculatively. This flaw could result in leaked passwords, such as those found in /etc/shadow while performing authentications. Solution(s) oracle-linux-upgrade-pam oracle-linux-upgrade-pam-devel oracle-linux-upgrade-pam-docs References https://attackerkb.com/topics/cve-2024-10041 CVE - 2024-10041 ELSA-2024-10379 ELSA-2024-11250

Microsoft Edge Chromium: CVE-2024-43566 Severity 10 CVSS (AV:N/AC:L/Au:N/C:C/I:C/A:C) Published 10/18/2024 Created 10/18/2024 Added 10/18/2024 Modified 01/28/2025 Description Microsoft Edge (Chromium-based) Remote Code Execution Vulnerability Solution(s) microsoft-edge-upgrade-latest References https://attackerkb.com/topics/cve-2024-43566 CVE - 2024-43566 https://msrc.microsoft.com/update-guide/vulnerability/CVE-2024-43566

Microsoft Edge Chromium: CVE-2024-43579 Severity 9 CVSS (AV:N/AC:M/Au:N/C:C/I:C/A:P) Published 10/18/2024 Created 10/18/2024 Added 10/18/2024 Modified 01/28/2025 Description Microsoft Edge (Chromium-based) Remote Code Execution Vulnerability Solution(s) microsoft-edge-upgrade-latest References https://attackerkb.com/topics/cve-2024-43579 CVE - 2024-43579 https://msrc.microsoft.com/update-guide/vulnerability/CVE-2024-43579

Microsoft Edge Chromium: CVE-2024-43580 Severity 6 CVSS (AV:N/AC:M/Au:N/C:P/I:P/A:N) Published 10/18/2024 Created 10/18/2024 Added 10/18/2024 Modified 01/28/2025 Description Microsoft Edge (Chromium-based) Spoofing Vulnerability Solution(s) microsoft-edge-upgrade-latest References https://attackerkb.com/topics/cve-2024-43580 CVE - 2024-43580 https://msrc.microsoft.com/update-guide/vulnerability/CVE-2024-43580

Microsoft Edge Chromium: CVE-2024-43596 Severity 9 CVSS (AV:N/AC:M/Au:N/C:C/I:C/A:C) Published 10/18/2024 Created 10/18/2024 Added 10/18/2024 Modified 01/28/2025 Description Microsoft Edge (Chromium-based) Remote Code Execution Vulnerability Solution(s) microsoft-edge-upgrade-latest References https://attackerkb.com/topics/cve-2024-43596 CVE - 2024-43596 https://msrc.microsoft.com/update-guide/vulnerability/CVE-2024-43596

Microsoft Edge Chromium: CVE-2024-43577 Severity 4 CVSS (AV:N/AC:M/Au:N/C:N/I:P/A:N) Published 10/18/2024 Created 10/22/2024 Added 10/21/2024 Modified 01/28/2025 Description Microsoft Edge (Chromium-based) Spoofing Vulnerability Solution(s) microsoft-edge-upgrade-latest References https://attackerkb.com/topics/cve-2024-43577 CVE - 2024-43577 https://msrc.microsoft.com/update-guide/vulnerability/CVE-2024-43577