ISHACK AI BOT 发布的所有帖子
-
VMware Photon OS: CVE-2024-26586
VMware Photon OS: CVE-2024-26586 Severity 6 CVSS (AV:L/AC:L/Au:M/C:C/I:C/A:C) Published 02/22/2024 Created 01/21/2025 Added 01/20/2025 Modified 02/04/2025 Description In the Linux kernel, the following vulnerability has been resolved: mlxsw: spectrum_acl_tcam: Fix stack corruption When tc filters are first added to a net device, the corresponding local port gets bound to an ACL group in the device. The group contains a list of ACLs. In turn, each ACL points to a different TCAM region where the filters are stored. During forwarding, the ACLs are sequentially evaluated until a match is found. One reason to place filters in different regions is when they are added with decreasing priorities and in an alternating order so that two consecutive filters can never fit in the same region because of their key usage. In Spectrum-2 and newer ASICs the firmware started to report that the maximum number of ACLs in a group is more than 16, but the layout of the register that configures ACL groups (PAGT) was not updated to account for that. It is therefore possible to hit stack corruption [1] in the rare case where more than 16 ACLs in a group are required. Fix by limiting the maximum ACL group size to the minimum between what the firmware reports and the maximum ACLs that fit in the PAGT register. Add a test case to make sure the machine does not crash when this condition is hit. [1] Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: mlxsw_sp_acl_tcam_group_update+0x116/0x120 [...] dump_stack_lvl+0x36/0x50 panic+0x305/0x330 __stack_chk_fail+0x15/0x20 mlxsw_sp_acl_tcam_group_update+0x116/0x120 mlxsw_sp_acl_tcam_group_region_attach+0x69/0x110 mlxsw_sp_acl_tcam_vchunk_get+0x492/0xa20 mlxsw_sp_acl_tcam_ventry_add+0x25/0xe0 mlxsw_sp_acl_rule_add+0x47/0x240 mlxsw_sp_flower_replace+0x1a9/0x1d0 tc_setup_cb_add+0xdc/0x1c0 fl_hw_replace_filter+0x146/0x1f0 fl_change+0xc17/0x1360 tc_new_tfilter+0x472/0xb90 rtnetlink_rcv_msg+0x313/0x3b0 netlink_rcv_skb+0x58/0x100 netlink_unicast+0x244/0x390 netlink_sendmsg+0x1e4/0x440 ____sys_sendmsg+0x164/0x260 ___sys_sendmsg+0x9a/0xe0 __sys_sendmsg+0x7a/0xc0 do_syscall_64+0x40/0xe0 entry_SYSCALL_64_after_hwframe+0x63/0x6b Solution(s) vmware-photon_os_update_tdnf References https://attackerkb.com/topics/cve-2024-26586 CVE - 2024-26586
-
VMware Photon OS: CVE-2024-26591
VMware Photon OS: CVE-2024-26591 Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 02/22/2024 Created 01/21/2025 Added 01/20/2025 Modified 02/04/2025 Description In the Linux kernel, the following vulnerability has been resolved: bpf: Fix re-attachment branch in bpf_tracing_prog_attach The following case can cause a crash due to missing attach_btf: 1) load rawtp program 2) load fentry program with rawtp as target_fd 3) create tracing link for fentry program with target_fd = 0 4) repeat 3 In the end we have: - prog->aux->dst_trampoline == NULL - tgt_prog == NULL (because we did not provide target_fd to link_create) - prog->aux->attach_btf == NULL (the program was loaded with attach_prog_fd=X) - the program was loaded for tgt_prog but we have no way to find out which one BUG: kernel NULL pointer dereference, address: 0000000000000058 Call Trace: <TASK> ? __die+0x20/0x70 ? page_fault_oops+0x15b/0x430 ? fixup_exception+0x22/0x330 ? exc_page_fault+0x6f/0x170 ? asm_exc_page_fault+0x22/0x30 ? bpf_tracing_prog_attach+0x279/0x560 ? btf_obj_id+0x5/0x10 bpf_tracing_prog_attach+0x439/0x560 __sys_bpf+0x1cf4/0x2de0 __x64_sys_bpf+0x1c/0x30 do_syscall_64+0x41/0xf0 entry_SYSCALL_64_after_hwframe+0x6e/0x76 Return -EINVAL in this situation. Solution(s) vmware-photon_os_update_tdnf References https://attackerkb.com/topics/cve-2024-26591 CVE - 2024-26591
-
VMware Photon OS: CVE-2023-52452
VMware Photon OS: CVE-2023-52452 Severity 7 CVSS (AV:L/AC:L/Au:S/C:C/I:C/A:C) Published 02/22/2024 Created 01/21/2025 Added 01/20/2025 Modified 02/04/2025 Description In the Linux kernel, the following vulnerability has been resolved: bpf: Fix accesses to uninit stack slots Privileged programs are supposed to be able to read uninitialized stack memory (ever since 6715df8d5) but, before this patch, these accesses were permitted inconsistently. In particular, accesses were permitted above state->allocated_stack, but not below it. In other words, if the stack was already "large enough", the access was permitted, but otherwise the access was rejected instead of being allowed to "grow the stack". This undesired rejection was happening in two places: - in check_stack_slot_within_bounds() - in check_stack_range_initialized() This patch arranges for these accesses to be permitted. A bunch of tests that were relying on the old rejection had to change; all of them were changed to add also run unprivileged, in which case the old behavior persists. One tests couldn't be updated - global_func16 - because it can't run unprivileged for other reasons. This patch also fixes the tracking of the stack size for variable-offset reads. This second fix is bundled in the same commit as the first one because they're inter-related. Before this patch, writes to the stack using registers containing a variable offset (as opposed to registers with fixed, known values) were not properly contributing to the function's needed stack size. As a result, it was possible for a program to verify, but then to attempt to read out-of-bounds data at runtime because a too small stack had been allocated for it. Each function tracks the size of the stack it needs in bpf_subprog_info.stack_depth, which is maintained by update_stack_depth(). For regular memory accesses, check_mem_access() was calling update_state_depth() but it was passing in only the fixed part of the offset register, ignoring the variable offset. This was incorrect; the minimum possible value of that register should be used instead. This tracking is now fixed by centralizing the tracking of stack size in grow_stack_state(), and by lifting the calls to grow_stack_state() to check_stack_access_within_bounds() as suggested by Andrii. The code is now simpler and more convincingly tracks the correct maximum stack size. check_stack_range_initialized() can now rely on enough stack having been allocated for the access; this helps with the fix for the first issue. A few tests were changed to also check the stack depth computation. The one that fails without this patch is verifier_var_off:stack_write_priv_vs_unpriv. Solution(s) vmware-photon_os_update_tdnf References https://attackerkb.com/topics/cve-2023-52452 CVE - 2023-52452
-
VMware Photon OS: CVE-2023-52447
VMware Photon OS: CVE-2023-52447 Severity 6 CVSS (AV:L/AC:L/Au:M/C:C/I:C/A:C) Published 02/22/2024 Created 01/21/2025 Added 01/20/2025 Modified 02/04/2025 Description In the Linux kernel, the following vulnerability has been resolved: bpf: Defer the free of inner map when necessary When updating or deleting an inner map in map array or map htab, the map may still be accessed by non-sleepable program or sleepable program. However bpf_map_fd_put_ptr() decreases the ref-counter of the inner map directly through bpf_map_put(), if the ref-counter is the last one (which is true for most cases), the inner map will be freed by ops->map_free() in a kworker. But for now, most .map_free() callbacks don't use synchronize_rcu() or its variants to wait for the elapse of a RCU grace period, so after the invocation of ops->map_free completes, the bpf program which is accessing the inner map may incur use-after-free problem. Fix the free of inner map by invoking bpf_map_free_deferred() after both one RCU grace period and one tasks trace RCU grace period if the inner map has been removed from the outer map before. The deferment is accomplished by using call_rcu() or call_rcu_tasks_trace() when releasing the last ref-counter of bpf map. The newly-added rcu_head field in bpf_map shares the same storage space with work field to reduce the size of bpf_map. Solution(s) vmware-photon_os_update_tdnf References https://attackerkb.com/topics/cve-2023-52447 CVE - 2023-52447
-
VMware Photon OS: CVE-2024-26589
VMware Photon OS: CVE-2024-26589 Severity 7 CVSS (AV:L/AC:L/Au:S/C:C/I:C/A:C) Published 02/22/2024 Created 01/21/2025 Added 01/20/2025 Modified 02/04/2025 Description In the Linux kernel, the following vulnerability has been resolved: bpf: Reject variable offset alu on PTR_TO_FLOW_KEYS For PTR_TO_FLOW_KEYS, check_flow_keys_access() only uses fixed off for validation. However, variable offset ptr alu is not prohibited for this ptr kind. So the variable offset is not checked. The following prog is accepted: func#0 @0 0: R1=ctx() R10=fp0 0: (bf) r6 = r1 ; R1=ctx() R6_w=ctx() 1: (79) r7 = *(u64 *)(r6 +144); R6_w=ctx() R7_w=flow_keys() 2: (b7) r8 = 1024 ; R8_w=1024 3: (37) r8 /= 1 ; R8_w=scalar() 4: (57) r8 &= 1024; R8_w=scalar(smin=smin32=0, smax=umax=smax32=umax32=1024,var_off=(0x0; 0x400)) 5: (0f) r7 += r8 mark_precise: frame0: last_idx 5 first_idx 0 subseq_idx -1 mark_precise: frame0: regs=r8 stack= before 4: (57) r8 &= 1024 mark_precise: frame0: regs=r8 stack= before 3: (37) r8 /= 1 mark_precise: frame0: regs=r8 stack= before 2: (b7) r8 = 1024 6: R7_w=flow_keys(smin=smin32=0,smax=umax=smax32=umax32=1024,var_off =(0x0; 0x400)) R8_w=scalar(smin=smin32=0,smax=umax=smax32=umax32=1024, var_off=(0x0; 0x400)) 6: (79) r0 = *(u64 *)(r7 +0); R0_w=scalar() 7: (95) exit This prog loads flow_keys to r7, and adds the variable offset r8 to r7, and finally causes out-of-bounds access: BUG: unable to handle page fault for address: ffffc90014c80038 [...] Call Trace: <TASK> bpf_dispatcher_nop_func include/linux/bpf.h:1231 [inline] __bpf_prog_run include/linux/filter.h:651 [inline] bpf_prog_run include/linux/filter.h:658 [inline] bpf_prog_run_pin_on_cpu include/linux/filter.h:675 [inline] bpf_flow_dissect+0x15f/0x350 net/core/flow_dissector.c:991 bpf_prog_test_run_flow_dissector+0x39d/0x620 net/bpf/test_run.c:1359 bpf_prog_test_run kernel/bpf/syscall.c:4107 [inline] __sys_bpf+0xf8f/0x4560 kernel/bpf/syscall.c:5475 __do_sys_bpf kernel/bpf/syscall.c:5561 [inline] __se_sys_bpf kernel/bpf/syscall.c:5559 [inline] __x64_sys_bpf+0x73/0xb0 kernel/bpf/syscall.c:5559 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x3f/0x110 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b Fix this by rejecting ptr alu with variable offset on flow_keys. Applying the patch rejects the program with "R7 pointer arithmetic on flow_keys prohibited". Solution(s) vmware-photon_os_update_tdnf References https://attackerkb.com/topics/cve-2024-26589 CVE - 2024-26589
-
Ubuntu: (Multiple Advisories) (CVE-2023-52444): Linux kernel (OEM) vulnerabilities
Ubuntu: (Multiple Advisories) (CVE-2023-52444): Linux kernel (OEM) vulnerabilities Severity 7 CVSS (AV:L/AC:L/Au:S/C:C/I:C/A:C) Published 02/22/2024 Created 03/13/2024 Added 03/12/2024 Modified 01/30/2025 Description In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to avoid dirent corruption As Al reported in link[1]: f2fs_rename() ... if (old_dir != new_dir && !whiteout) f2fs_set_link(old_inode, old_dir_entry, old_dir_page, new_dir); else f2fs_put_page(old_dir_page, 0); You want correct inumber in the ".." link.And cross-directory rename does move the source to new parent, even if you'd been asked to leave a whiteout in the old place. [1] https://lore.kernel.org/all/20231017055040.GN800259@ZenIV/ With below testcase, it may cause dirent corruption, due to it missed to call f2fs_set_link() to update ".." link to new directory. - mkdir -p dir/foo - renameat2 -w dir/foo bar [ASSERT] (__chk_dots_dentries:1421)--> Bad inode number[0x4] for '..', parent parent ino is [0x3] [FSCK] other corrupted bugs [Fail] Solution(s) ubuntu-upgrade-linux-image-4-15-0-1133-oracle ubuntu-upgrade-linux-image-4-15-0-1154-kvm ubuntu-upgrade-linux-image-4-15-0-1164-gcp ubuntu-upgrade-linux-image-4-15-0-1170-aws ubuntu-upgrade-linux-image-4-15-0-1179-azure ubuntu-upgrade-linux-image-4-15-0-227-generic ubuntu-upgrade-linux-image-4-15-0-227-lowlatency ubuntu-upgrade-linux-image-4-4-0-1134-aws ubuntu-upgrade-linux-image-4-4-0-1135-kvm ubuntu-upgrade-linux-image-4-4-0-1172-aws ubuntu-upgrade-linux-image-4-4-0-257-generic ubuntu-upgrade-linux-image-4-4-0-257-lowlatency ubuntu-upgrade-linux-image-5-15-0-102-generic ubuntu-upgrade-linux-image-5-15-0-102-generic-64k ubuntu-upgrade-linux-image-5-15-0-102-generic-lpae ubuntu-upgrade-linux-image-5-15-0-102-lowlatency ubuntu-upgrade-linux-image-5-15-0-102-lowlatency-64k ubuntu-upgrade-linux-image-5-15-0-1040-gkeop ubuntu-upgrade-linux-image-5-15-0-1048-nvidia ubuntu-upgrade-linux-image-5-15-0-1048-nvidia-lowlatency ubuntu-upgrade-linux-image-5-15-0-1050-ibm ubuntu-upgrade-linux-image-5-15-0-1050-raspi ubuntu-upgrade-linux-image-5-15-0-1052-intel-iotg ubuntu-upgrade-linux-image-5-15-0-1054-gke ubuntu-upgrade-linux-image-5-15-0-1054-kvm ubuntu-upgrade-linux-image-5-15-0-1055-gcp ubuntu-upgrade-linux-image-5-15-0-1055-oracle ubuntu-upgrade-linux-image-5-15-0-1057-aws ubuntu-upgrade-linux-image-5-15-0-1060-azure ubuntu-upgrade-linux-image-5-15-0-1060-azure-fde ubuntu-upgrade-linux-image-5-4-0-1034-iot ubuntu-upgrade-linux-image-5-4-0-1041-xilinx-zynqmp ubuntu-upgrade-linux-image-5-4-0-1069-ibm ubuntu-upgrade-linux-image-5-4-0-1082-bluefield ubuntu-upgrade-linux-image-5-4-0-1089-gkeop ubuntu-upgrade-linux-image-5-4-0-1106-raspi ubuntu-upgrade-linux-image-5-4-0-1110-kvm ubuntu-upgrade-linux-image-5-4-0-1121-oracle ubuntu-upgrade-linux-image-5-4-0-1122-aws ubuntu-upgrade-linux-image-5-4-0-1126-gcp ubuntu-upgrade-linux-image-5-4-0-1127-azure ubuntu-upgrade-linux-image-5-4-0-175-generic ubuntu-upgrade-linux-image-5-4-0-175-lowlatency ubuntu-upgrade-linux-image-5-4-0-176-generic ubuntu-upgrade-linux-image-5-4-0-176-generic-lpae ubuntu-upgrade-linux-image-5-4-0-176-lowlatency ubuntu-upgrade-linux-image-6-1-0-1035-oem ubuntu-upgrade-linux-image-6-5-0-1015-starfive ubuntu-upgrade-linux-image-6-5-0-1017-laptop ubuntu-upgrade-linux-image-6-5-0-1018-raspi ubuntu-upgrade-linux-image-6-5-0-1021-aws ubuntu-upgrade-linux-image-6-5-0-1021-nvidia ubuntu-upgrade-linux-image-6-5-0-1021-nvidia-64k ubuntu-upgrade-linux-image-6-5-0-1022-azure ubuntu-upgrade-linux-image-6-5-0-1022-azure-fde ubuntu-upgrade-linux-image-6-5-0-1022-gcp ubuntu-upgrade-linux-image-6-5-0-1024-oem ubuntu-upgrade-linux-image-6-5-0-1024-oracle ubuntu-upgrade-linux-image-6-5-0-1024-oracle-64k ubuntu-upgrade-linux-image-6-5-0-41-generic ubuntu-upgrade-linux-image-6-5-0-41-generic-64k ubuntu-upgrade-linux-image-6-5-0-41-lowlatency ubuntu-upgrade-linux-image-6-5-0-41-lowlatency-64k ubuntu-upgrade-linux-image-aws ubuntu-upgrade-linux-image-aws-hwe ubuntu-upgrade-linux-image-aws-lts-18-04 ubuntu-upgrade-linux-image-aws-lts-20-04 ubuntu-upgrade-linux-image-aws-lts-22-04 ubuntu-upgrade-linux-image-azure ubuntu-upgrade-linux-image-azure-cvm ubuntu-upgrade-linux-image-azure-fde ubuntu-upgrade-linux-image-azure-fde-lts-22-04 ubuntu-upgrade-linux-image-azure-lts-18-04 ubuntu-upgrade-linux-image-azure-lts-20-04 ubuntu-upgrade-linux-image-azure-lts-22-04 ubuntu-upgrade-linux-image-bluefield ubuntu-upgrade-linux-image-gcp ubuntu-upgrade-linux-image-gcp-lts-18-04 ubuntu-upgrade-linux-image-gcp-lts-20-04 ubuntu-upgrade-linux-image-gcp-lts-22-04 ubuntu-upgrade-linux-image-generic ubuntu-upgrade-linux-image-generic-64k ubuntu-upgrade-linux-image-generic-64k-hwe-20-04 ubuntu-upgrade-linux-image-generic-64k-hwe-22-04 ubuntu-upgrade-linux-image-generic-hwe-16-04 ubuntu-upgrade-linux-image-generic-hwe-18-04 ubuntu-upgrade-linux-image-generic-hwe-20-04 ubuntu-upgrade-linux-image-generic-hwe-22-04 ubuntu-upgrade-linux-image-generic-lpae ubuntu-upgrade-linux-image-generic-lpae-hwe-20-04 ubuntu-upgrade-linux-image-generic-lts-xenial ubuntu-upgrade-linux-image-gke ubuntu-upgrade-linux-image-gke-5-15 ubuntu-upgrade-linux-image-gkeop ubuntu-upgrade-linux-image-gkeop-5-15 ubuntu-upgrade-linux-image-gkeop-5-4 ubuntu-upgrade-linux-image-ibm ubuntu-upgrade-linux-image-ibm-lts-20-04 ubuntu-upgrade-linux-image-intel ubuntu-upgrade-linux-image-intel-iotg ubuntu-upgrade-linux-image-kvm ubuntu-upgrade-linux-image-laptop-23-10 ubuntu-upgrade-linux-image-lowlatency ubuntu-upgrade-linux-image-lowlatency-64k ubuntu-upgrade-linux-image-lowlatency-64k-hwe-20-04 ubuntu-upgrade-linux-image-lowlatency-64k-hwe-22-04 ubuntu-upgrade-linux-image-lowlatency-hwe-16-04 ubuntu-upgrade-linux-image-lowlatency-hwe-18-04 ubuntu-upgrade-linux-image-lowlatency-hwe-20-04 ubuntu-upgrade-linux-image-lowlatency-hwe-22-04 ubuntu-upgrade-linux-image-lowlatency-lts-xenial ubuntu-upgrade-linux-image-nvidia ubuntu-upgrade-linux-image-nvidia-6-5 ubuntu-upgrade-linux-image-nvidia-64k-6-5 ubuntu-upgrade-linux-image-nvidia-64k-hwe-22-04 ubuntu-upgrade-linux-image-nvidia-hwe-22-04 ubuntu-upgrade-linux-image-nvidia-lowlatency ubuntu-upgrade-linux-image-oem ubuntu-upgrade-linux-image-oem-20-04 ubuntu-upgrade-linux-image-oem-20-04b ubuntu-upgrade-linux-image-oem-20-04c ubuntu-upgrade-linux-image-oem-20-04d ubuntu-upgrade-linux-image-oem-22-04 ubuntu-upgrade-linux-image-oem-22-04a ubuntu-upgrade-linux-image-oem-22-04b ubuntu-upgrade-linux-image-oem-22-04c ubuntu-upgrade-linux-image-oem-22-04d ubuntu-upgrade-linux-image-oem-osp1 ubuntu-upgrade-linux-image-oracle ubuntu-upgrade-linux-image-oracle-64k ubuntu-upgrade-linux-image-oracle-lts-18-04 ubuntu-upgrade-linux-image-oracle-lts-20-04 ubuntu-upgrade-linux-image-oracle-lts-22-04 ubuntu-upgrade-linux-image-raspi ubuntu-upgrade-linux-image-raspi-hwe-18-04 ubuntu-upgrade-linux-image-raspi-nolpae ubuntu-upgrade-linux-image-raspi2 ubuntu-upgrade-linux-image-snapdragon-hwe-18-04 ubuntu-upgrade-linux-image-starfive ubuntu-upgrade-linux-image-virtual ubuntu-upgrade-linux-image-virtual-hwe-16-04 ubuntu-upgrade-linux-image-virtual-hwe-18-04 ubuntu-upgrade-linux-image-virtual-hwe-20-04 ubuntu-upgrade-linux-image-virtual-hwe-22-04 ubuntu-upgrade-linux-image-virtual-lts-xenial ubuntu-upgrade-linux-image-xilinx-zynqmp References https://attackerkb.com/topics/cve-2023-52444 CVE - 2023-52444 USN-6688-1 USN-6725-1 USN-6725-2 USN-6726-1 USN-6726-2 USN-6726-3 USN-6765-1 USN-6818-1 USN-6818-2 USN-6818-3 USN-6818-4 USN-6819-1 USN-6819-2 USN-6819-3 USN-6819-4 USN-6926-1 USN-6926-2 USN-6926-3 USN-6938-1 View more
-
Ubuntu: (CVE-2024-26590): linux-raspi-realtime vulnerability
Ubuntu: (CVE-2024-26590): linux-raspi-realtime vulnerability Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 02/22/2024 Created 02/12/2025 Added 02/11/2025 Modified 02/11/2025 Description In the Linux kernel, the following vulnerability has been resolved: erofs: fix inconsistent per-file compression format EROFS can select compression algorithms on a per-file basis, and each per-file compression algorithm needs to be marked in the on-disk superblock for initialization. However, syzkaller can generate inconsistent crafted images that use an unsupported algorithmtype for specific inodes, e.g. use MicroLZMA algorithmtype even it's not set in `sbi->available_compr_algs`.This can lead to an unexpected "BUG: kernel NULL pointer dereference" if the corresponding decompressor isn't built-in. Fix this by checking against `sbi->available_compr_algs` for each m_algorithmformat request.Incorrect !erofs_sb_has_compr_cfgs preset bitmap is now fixed together since it was harmless previously. Solution(s) ubuntu-upgrade-linux-raspi-realtime References https://attackerkb.com/topics/cve-2024-26590 CVE - 2024-26590 https://git.kernel.org/stable/c/118a8cf504d7dfa519562d000f423ee3ca75d2c4 https://git.kernel.org/stable/c/823ba1d2106019ddf195287ba53057aee33cf724 https://git.kernel.org/stable/c/eed24b816e50c6cd18cbee0ff0d7218c8fced199 https://www.cve.org/CVERecord?id=CVE-2024-26590
-
Oracle Linux: CVE-2024-26587: ELSA-2024-12682: Unbreakable Enterprise kernel security update (IMPORTANT) (Multiple Advisories)
Oracle Linux: CVE-2024-26587: ELSA-2024-12682: Unbreakable Enterprise kernel security update (IMPORTANT) (Multiple Advisories) Severity 4 CVSS (AV:L/AC:H/Au:S/C:N/I:N/A:C) Published 02/22/2024 Created 10/18/2024 Added 10/16/2024 Modified 01/23/2025 Description In the Linux kernel, the following vulnerability has been resolved: net: netdevsim: don't try to destroy PHC on VFs PHC gets initialized in nsim_init_netdevsim(), which is only called if (nsim_dev_port_is_pf()). Create a counterpart of nsim_init_netdevsim() and move the mock_phc_destroy() there. This fixes a crash trying to destroy netdevsim with VFs instantiated, as caught by running the devlink.sh test: BUG: kernel NULL pointer dereference, address: 00000000000000b8 RIP: 0010:mock_phc_destroy+0xd/0x30 Call Trace: <TASK> nsim_destroy+0x4a/0x70 [netdevsim] __nsim_dev_port_del+0x47/0x70 [netdevsim] nsim_dev_reload_destroy+0x105/0x120 [netdevsim] nsim_drv_remove+0x2f/0xb0 [netdevsim] device_release_driver_internal+0x1a1/0x210 bus_remove_device+0xd5/0x120 device_del+0x159/0x490 device_unregister+0x12/0x30 del_device_store+0x11a/0x1a0 [netdevsim] kernfs_fop_write_iter+0x130/0x1d0 vfs_write+0x30b/0x4b0 ksys_write+0x69/0xf0 do_syscall_64+0xcc/0x1e0 entry_SYSCALL_64_after_hwframe+0x6f/0x77 Solution(s) oracle-linux-upgrade-kernel-uek References https://attackerkb.com/topics/cve-2024-26587 CVE - 2024-26587 ELSA-2024-12682
-
Huawei EulerOS: CVE-2023-52445: kernel security update
Huawei EulerOS: CVE-2023-52445: kernel security update Severity 7 CVSS (AV:L/AC:L/Au:S/C:C/I:C/A:C) Published 02/22/2024 Created 07/17/2024 Added 07/17/2024 Modified 01/28/2025 Description In the Linux kernel, the following vulnerability has been resolved: media: pvrusb2: fix use after free on context disconnection Upon module load, a kthread is created targeting the pvr2_context_thread_func function, which may call pvr2_context_destroy and thus call kfree() on the context object. However, that might happen before the usb hub_event handler is able to notify the driver. This patch adds a sanity check before the invalid read reported by syzbot, within the context disconnection call stack. 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-2023-52445 CVE - 2023-52445 EulerOS-SA-2024-1964
-
Fortinet FortiOS: NULL Pointer Dereference (CVE-2023-29180)
Fortinet FortiOS: NULL Pointer Dereference (CVE-2023-29180) Severity 8 CVSS (AV:N/AC:L/Au:N/C:N/I:N/A:C) Published 02/22/2024 Created 12/13/2024 Added 12/12/2024 Modified 01/28/2025 Description A null pointer dereference in Fortinet FortiOS version 7.2.0 through 7.2.4, 7.0.0 through 7.0.11, 6.4.0 through 6.4.12, 6.2.0 through 6.2.14, 6.0.0 through 6.0.16, FortiProxy 7.2.0 through 7.2.3, 7.0.0 through 7.0.10, 2.0.0 through 2.0.12, 1.2.0 through 1.2.13, 1.1.0 through 1.1.6, 1.0.0 through 1.0.7 allows attacker to denial of service via specially crafted HTTP requests. Solution(s) fortios-upgrade-6_0_17 fortios-upgrade-6_2_15 fortios-upgrade-6_4_13 fortios-upgrade-7_0_12 fortios-upgrade-7_2_5 References https://attackerkb.com/topics/cve-2023-29180 CVE - 2023-29180 https://fortiguard.com/psirt/FG-IR-23-111
-
Fortinet FortiOS: Use of Externally-Controlled Format String (CVE-2023-29181)
Fortinet FortiOS: Use of Externally-Controlled Format String (CVE-2023-29181) Severity 9 CVSS (AV:N/AC:L/Au:S/C:C/I:C/A:C) Published 02/22/2024 Created 12/13/2024 Added 12/12/2024 Modified 01/28/2025 Description A use of externally-controlled format string in Fortinet FortiOS 7.2.0 through 7.2.4, 7.0.0 through 7.0.11, 6.4.0 through 6.4.12, 6.2.0 through 6.2.14, 6.0.0 through 6.0.16, FortiProxy 7.2.0 through 7.2.4, 7.0.0 through 7.0.10, 2.0.0 through 2.0.12, 1.2.0 through 1.2.13, 1.1.0 through 1.1.6, 1.0.0 through 1.0.7, FortiPAM 1.0.0 through 1.0.3 allows attacker to execute unauthorized code or commands via specially crafted command. Solution(s) fortios-upgrade-6_2_15 fortios-upgrade-6_4_13 fortios-upgrade-7_0_12 fortios-upgrade-7_2_5 References https://attackerkb.com/topics/cve-2023-29181 CVE - 2023-29181 https://fortiguard.com/psirt/FG-IR-23-119
-
Fortinet FortiOS: Unspecified Security Vulnerability (CVE-2023-29179)
Fortinet FortiOS: Unspecified Security Vulnerability (CVE-2023-29179) Severity 7 CVSS (AV:N/AC:L/Au:S/C:N/I:N/A:C) Published 02/22/2024 Created 12/13/2024 Added 12/12/2024 Modified 01/28/2025 Description A null pointer dereference in Fortinet FortiOS version 7.2.0 through 7.2.4, 7.0.0 through 7.0.11, 6.4.0 through 6.4.12, Fortiproxy version 7.2.0 through 7.2.4, 7.0.0 through 7.0.10 allows attacker to denial of service viaspecially crafted HTTP requests. Solution(s) fortios-upgrade-6_4_13 fortios-upgrade-7_0_12 fortios-upgrade-7_2_5 References https://attackerkb.com/topics/cve-2023-29179 CVE - 2023-29179 https://fortiguard.com/psirt/FG-IR-23-125
-
Huawei EulerOS: CVE-2023-52160: wpa_supplicant security update
Huawei EulerOS: CVE-2023-52160: wpa_supplicant security update Severity 7 CVSS (AV:N/AC:M/Au:N/C:C/I:N/A:N) Published 02/22/2024 Created 07/23/2024 Added 07/23/2024 Modified 01/30/2025 Description The implementation of PEAP in wpa_supplicant through 2.10 allows authentication bypass. For a successful attack, wpa_supplicant must be configured to not verify the network's TLS certificate during Phase 1 authentication, and an eap_peap_decrypt vulnerability can then be abused to skip Phase 2 authentication. The attack vector is sending an EAP-TLV Success packet instead of starting Phase 2. This allows an adversary to impersonate Enterprise Wi-Fi networks. Solution(s) huawei-euleros-2_0_sp8-upgrade-wpa_supplicant References https://attackerkb.com/topics/cve-2023-52160 CVE - 2023-52160 EulerOS-SA-2024-2495
-
Ubuntu: (Multiple Advisories) (CVE-2023-52451): Linux kernel (OEM) vulnerabilities
Ubuntu: (Multiple Advisories) (CVE-2023-52451): Linux kernel (OEM) vulnerabilities Severity 7 CVSS (AV:L/AC:L/Au:S/C:C/I:C/A:C) Published 02/22/2024 Created 03/13/2024 Added 03/12/2024 Modified 01/30/2025 Description In the Linux kernel, the following vulnerability has been resolved: powerpc/pseries/memhp: Fix access beyond end of drmem array dlpar_memory_remove_by_index() may access beyond the bounds of the drmem lmb array when the LMB lookup fails to match an entry with the given DRC index. When the search fails, the cursor is left pointing to &drmem_info->lmbs[drmem_info->n_lmbs], which is one element past the last valid entry in the array. The debug message at the end of the function then dereferences this pointer: pr_debug("Failed to hot-remove memory at %llx\n", lmb->base_addr); This was found by inspection and confirmed with KASAN: pseries-hotplug-mem: Attempting to hot-remove LMB, drc index 1234 ================================================================== BUG: KASAN: slab-out-of-bounds in dlpar_memory+0x298/0x1658 Read of size 8 at addr c000000364e97fd0 by task bash/949 dump_stack_lvl+0xa4/0xfc (unreliable) print_report+0x214/0x63c kasan_report+0x140/0x2e0 __asan_load8+0xa8/0xe0 dlpar_memory+0x298/0x1658 handle_dlpar_errorlog+0x130/0x1d0 dlpar_store+0x18c/0x3e0 kobj_attr_store+0x68/0xa0 sysfs_kf_write+0xc4/0x110 kernfs_fop_write_iter+0x26c/0x390 vfs_write+0x2d4/0x4e0 ksys_write+0xac/0x1a0 system_call_exception+0x268/0x530 system_call_vectored_common+0x15c/0x2ec Allocated by task 1: kasan_save_stack+0x48/0x80 kasan_set_track+0x34/0x50 kasan_save_alloc_info+0x34/0x50 __kasan_kmalloc+0xd0/0x120 __kmalloc+0x8c/0x320 kmalloc_array.constprop.0+0x48/0x5c drmem_init+0x2a0/0x41c do_one_initcall+0xe0/0x5c0 kernel_init_freeable+0x4ec/0x5a0 kernel_init+0x30/0x1e0 ret_from_kernel_user_thread+0x14/0x1c The buggy address belongs to the object at c000000364e80000 which belongs to the cache kmalloc-128k of size 131072 The buggy address is located 0 bytes to the right of allocated 98256-byte region [c000000364e80000, c000000364e97fd0) ================================================================== pseries-hotplug-mem: Failed to hot-remove memory at 0 Log failed lookups with a separate message and dereference the cursor only when it points to a valid entry. Solution(s) ubuntu-upgrade-linux-image-4-15-0-1130-oracle ubuntu-upgrade-linux-image-4-15-0-1151-kvm ubuntu-upgrade-linux-image-4-15-0-1161-gcp ubuntu-upgrade-linux-image-4-15-0-1167-aws ubuntu-upgrade-linux-image-4-15-0-1176-azure ubuntu-upgrade-linux-image-4-15-0-224-generic ubuntu-upgrade-linux-image-4-15-0-224-lowlatency ubuntu-upgrade-linux-image-4-4-0-1130-aws ubuntu-upgrade-linux-image-4-4-0-1131-kvm ubuntu-upgrade-linux-image-4-4-0-1168-aws ubuntu-upgrade-linux-image-4-4-0-253-generic ubuntu-upgrade-linux-image-4-4-0-253-lowlatency ubuntu-upgrade-linux-image-5-15-0-102-generic ubuntu-upgrade-linux-image-5-15-0-102-generic-64k ubuntu-upgrade-linux-image-5-15-0-102-generic-lpae ubuntu-upgrade-linux-image-5-15-0-102-lowlatency ubuntu-upgrade-linux-image-5-15-0-102-lowlatency-64k ubuntu-upgrade-linux-image-5-15-0-1040-gkeop ubuntu-upgrade-linux-image-5-15-0-1048-nvidia ubuntu-upgrade-linux-image-5-15-0-1048-nvidia-lowlatency ubuntu-upgrade-linux-image-5-15-0-1050-ibm ubuntu-upgrade-linux-image-5-15-0-1050-raspi ubuntu-upgrade-linux-image-5-15-0-1052-intel-iotg ubuntu-upgrade-linux-image-5-15-0-1054-gke ubuntu-upgrade-linux-image-5-15-0-1054-kvm ubuntu-upgrade-linux-image-5-15-0-1055-gcp ubuntu-upgrade-linux-image-5-15-0-1055-oracle ubuntu-upgrade-linux-image-5-15-0-1057-aws ubuntu-upgrade-linux-image-5-15-0-1060-azure ubuntu-upgrade-linux-image-5-15-0-1060-azure-fde ubuntu-upgrade-linux-image-5-4-0-1034-iot ubuntu-upgrade-linux-image-5-4-0-1041-xilinx-zynqmp ubuntu-upgrade-linux-image-5-4-0-1069-ibm ubuntu-upgrade-linux-image-5-4-0-1082-bluefield ubuntu-upgrade-linux-image-5-4-0-1089-gkeop ubuntu-upgrade-linux-image-5-4-0-1106-raspi ubuntu-upgrade-linux-image-5-4-0-1110-kvm ubuntu-upgrade-linux-image-5-4-0-1121-oracle ubuntu-upgrade-linux-image-5-4-0-1122-aws ubuntu-upgrade-linux-image-5-4-0-1126-gcp ubuntu-upgrade-linux-image-5-4-0-1127-azure ubuntu-upgrade-linux-image-5-4-0-175-generic ubuntu-upgrade-linux-image-5-4-0-175-lowlatency ubuntu-upgrade-linux-image-5-4-0-176-generic ubuntu-upgrade-linux-image-5-4-0-176-generic-lpae ubuntu-upgrade-linux-image-5-4-0-176-lowlatency ubuntu-upgrade-linux-image-6-1-0-1035-oem ubuntu-upgrade-linux-image-6-5-0-1015-starfive ubuntu-upgrade-linux-image-6-5-0-1017-laptop ubuntu-upgrade-linux-image-6-5-0-1018-raspi ubuntu-upgrade-linux-image-6-5-0-1021-aws ubuntu-upgrade-linux-image-6-5-0-1021-nvidia ubuntu-upgrade-linux-image-6-5-0-1021-nvidia-64k ubuntu-upgrade-linux-image-6-5-0-1022-azure ubuntu-upgrade-linux-image-6-5-0-1022-azure-fde ubuntu-upgrade-linux-image-6-5-0-1022-gcp ubuntu-upgrade-linux-image-6-5-0-1024-oem ubuntu-upgrade-linux-image-6-5-0-1024-oracle ubuntu-upgrade-linux-image-6-5-0-1024-oracle-64k ubuntu-upgrade-linux-image-6-5-0-41-generic ubuntu-upgrade-linux-image-6-5-0-41-generic-64k ubuntu-upgrade-linux-image-6-5-0-41-lowlatency ubuntu-upgrade-linux-image-6-5-0-41-lowlatency-64k ubuntu-upgrade-linux-image-aws ubuntu-upgrade-linux-image-aws-hwe ubuntu-upgrade-linux-image-aws-lts-18-04 ubuntu-upgrade-linux-image-aws-lts-20-04 ubuntu-upgrade-linux-image-aws-lts-22-04 ubuntu-upgrade-linux-image-azure ubuntu-upgrade-linux-image-azure-cvm ubuntu-upgrade-linux-image-azure-fde ubuntu-upgrade-linux-image-azure-fde-lts-22-04 ubuntu-upgrade-linux-image-azure-lts-18-04 ubuntu-upgrade-linux-image-azure-lts-20-04 ubuntu-upgrade-linux-image-azure-lts-22-04 ubuntu-upgrade-linux-image-bluefield ubuntu-upgrade-linux-image-gcp ubuntu-upgrade-linux-image-gcp-lts-18-04 ubuntu-upgrade-linux-image-gcp-lts-20-04 ubuntu-upgrade-linux-image-gcp-lts-22-04 ubuntu-upgrade-linux-image-generic ubuntu-upgrade-linux-image-generic-64k ubuntu-upgrade-linux-image-generic-64k-hwe-20-04 ubuntu-upgrade-linux-image-generic-64k-hwe-22-04 ubuntu-upgrade-linux-image-generic-hwe-16-04 ubuntu-upgrade-linux-image-generic-hwe-18-04 ubuntu-upgrade-linux-image-generic-hwe-20-04 ubuntu-upgrade-linux-image-generic-hwe-22-04 ubuntu-upgrade-linux-image-generic-lpae ubuntu-upgrade-linux-image-generic-lpae-hwe-20-04 ubuntu-upgrade-linux-image-generic-lts-xenial ubuntu-upgrade-linux-image-gke ubuntu-upgrade-linux-image-gke-5-15 ubuntu-upgrade-linux-image-gkeop ubuntu-upgrade-linux-image-gkeop-5-15 ubuntu-upgrade-linux-image-gkeop-5-4 ubuntu-upgrade-linux-image-ibm ubuntu-upgrade-linux-image-ibm-lts-20-04 ubuntu-upgrade-linux-image-intel ubuntu-upgrade-linux-image-intel-iotg ubuntu-upgrade-linux-image-kvm ubuntu-upgrade-linux-image-laptop-23-10 ubuntu-upgrade-linux-image-lowlatency ubuntu-upgrade-linux-image-lowlatency-64k ubuntu-upgrade-linux-image-lowlatency-64k-hwe-20-04 ubuntu-upgrade-linux-image-lowlatency-64k-hwe-22-04 ubuntu-upgrade-linux-image-lowlatency-hwe-16-04 ubuntu-upgrade-linux-image-lowlatency-hwe-18-04 ubuntu-upgrade-linux-image-lowlatency-hwe-20-04 ubuntu-upgrade-linux-image-lowlatency-hwe-22-04 ubuntu-upgrade-linux-image-lowlatency-lts-xenial ubuntu-upgrade-linux-image-nvidia ubuntu-upgrade-linux-image-nvidia-6-5 ubuntu-upgrade-linux-image-nvidia-64k-6-5 ubuntu-upgrade-linux-image-nvidia-64k-hwe-22-04 ubuntu-upgrade-linux-image-nvidia-hwe-22-04 ubuntu-upgrade-linux-image-nvidia-lowlatency ubuntu-upgrade-linux-image-oem ubuntu-upgrade-linux-image-oem-20-04 ubuntu-upgrade-linux-image-oem-20-04b ubuntu-upgrade-linux-image-oem-20-04c ubuntu-upgrade-linux-image-oem-20-04d ubuntu-upgrade-linux-image-oem-22-04 ubuntu-upgrade-linux-image-oem-22-04a ubuntu-upgrade-linux-image-oem-22-04b ubuntu-upgrade-linux-image-oem-22-04c ubuntu-upgrade-linux-image-oem-22-04d ubuntu-upgrade-linux-image-oem-osp1 ubuntu-upgrade-linux-image-oracle ubuntu-upgrade-linux-image-oracle-64k ubuntu-upgrade-linux-image-oracle-lts-18-04 ubuntu-upgrade-linux-image-oracle-lts-20-04 ubuntu-upgrade-linux-image-oracle-lts-22-04 ubuntu-upgrade-linux-image-raspi ubuntu-upgrade-linux-image-raspi-hwe-18-04 ubuntu-upgrade-linux-image-raspi-nolpae ubuntu-upgrade-linux-image-raspi2 ubuntu-upgrade-linux-image-snapdragon-hwe-18-04 ubuntu-upgrade-linux-image-starfive ubuntu-upgrade-linux-image-virtual ubuntu-upgrade-linux-image-virtual-hwe-16-04 ubuntu-upgrade-linux-image-virtual-hwe-18-04 ubuntu-upgrade-linux-image-virtual-hwe-20-04 ubuntu-upgrade-linux-image-virtual-hwe-22-04 ubuntu-upgrade-linux-image-virtual-lts-xenial ubuntu-upgrade-linux-image-xilinx-zynqmp References https://attackerkb.com/topics/cve-2023-52451 CVE - 2023-52451 USN-6688-1 USN-6725-1 USN-6725-2 USN-6726-1 USN-6726-2 USN-6726-3 USN-6739-1 USN-6740-1 USN-6765-1 USN-6818-1 USN-6818-2 USN-6818-3 USN-6818-4 USN-6819-1 USN-6819-2 USN-6819-3 USN-6819-4 View more
-
Huawei EulerOS: CVE-2023-52447: kernel security update
Huawei EulerOS: CVE-2023-52447: kernel security update Severity 7 CVSS (AV:L/AC:L/Au:M/C:C/I:C/A:C) Published 02/22/2024 Created 07/02/2024 Added 07/01/2024 Modified 01/30/2025 Description In the Linux kernel, the following vulnerability has been resolved: bpf: Defer the free of inner map when necessary When updating or deleting an inner map in map array or map htab, the map may still be accessed by non-sleepable program or sleepable program. However bpf_map_fd_put_ptr() decreases the ref-counter of the inner map directly through bpf_map_put(), if the ref-counter is the last one (which is true for most cases), the inner map will be freed by ops->map_free() in a kworker. But for now, most .map_free() callbacks don't use synchronize_rcu() or its variants to wait for the elapse of a RCU grace period, so after the invocation of ops->map_free completes, the bpf program which is accessing the inner map may incur use-after-free problem. Fix the free of inner map by invoking bpf_map_free_deferred() after both one RCU grace period and one tasks trace RCU grace period if the inner map has been removed from the outer map before. The deferment is accomplished by using call_rcu() or call_rcu_tasks_trace() when releasing the last ref-counter of bpf map. The newly-added rcu_head field in bpf_map shares the same storage space with work field to reduce the size of bpf_map. Solution(s) huawei-euleros-2_0_sp12-upgrade-bpftool huawei-euleros-2_0_sp12-upgrade-kernel huawei-euleros-2_0_sp12-upgrade-kernel-abi-stablelists huawei-euleros-2_0_sp12-upgrade-kernel-tools huawei-euleros-2_0_sp12-upgrade-kernel-tools-libs huawei-euleros-2_0_sp12-upgrade-python3-perf References https://attackerkb.com/topics/cve-2023-52447 CVE - 2023-52447 EulerOS-SA-2024-1873
-
Alma Linux: CVE-2023-52445: Moderate: kernel update (Multiple Advisories)
Alma Linux: CVE-2023-52445: Moderate: kernel update (Multiple Advisories) Severity 7 CVSS (AV:L/AC:L/Au:S/C:C/I:C/A:C) Published 02/22/2024 Created 06/07/2024 Added 06/06/2024 Modified 01/28/2025 Description In the Linux kernel, the following vulnerability has been resolved: media: pvrusb2: fix use after free on context disconnection Upon module load, a kthread is created targeting the pvr2_context_thread_func function, which may call pvr2_context_destroy and thus call kfree() on the context object. However, that might happen before the usb hub_event handler is able to notify the driver. This patch adds a sanity check before the invalid read reported by syzbot, within the context disconnection call stack. Solution(s) alma-upgrade-bpftool alma-upgrade-kernel alma-upgrade-kernel-abi-stablelists alma-upgrade-kernel-core alma-upgrade-kernel-cross-headers alma-upgrade-kernel-debug alma-upgrade-kernel-debug-core alma-upgrade-kernel-debug-devel alma-upgrade-kernel-debug-modules alma-upgrade-kernel-debug-modules-extra alma-upgrade-kernel-devel alma-upgrade-kernel-doc alma-upgrade-kernel-headers alma-upgrade-kernel-modules alma-upgrade-kernel-modules-extra alma-upgrade-kernel-rt alma-upgrade-kernel-rt-core alma-upgrade-kernel-rt-debug alma-upgrade-kernel-rt-debug-core alma-upgrade-kernel-rt-debug-devel alma-upgrade-kernel-rt-debug-kvm alma-upgrade-kernel-rt-debug-modules alma-upgrade-kernel-rt-debug-modules-extra alma-upgrade-kernel-rt-devel alma-upgrade-kernel-rt-kvm alma-upgrade-kernel-rt-modules alma-upgrade-kernel-rt-modules-extra alma-upgrade-kernel-tools alma-upgrade-kernel-tools-libs alma-upgrade-kernel-tools-libs-devel alma-upgrade-kernel-zfcpdump alma-upgrade-kernel-zfcpdump-core alma-upgrade-kernel-zfcpdump-devel alma-upgrade-kernel-zfcpdump-modules alma-upgrade-kernel-zfcpdump-modules-extra alma-upgrade-perf alma-upgrade-python3-perf References https://attackerkb.com/topics/cve-2023-52445 CVE - 2023-52445 https://errata.almalinux.org/8/ALSA-2024-3618.html https://errata.almalinux.org/8/ALSA-2024-3627.html
-
Red Hat: CVE-2024-26589: kernel: bpf: Reject variable offset alu on PTR_TO_FLOW_KEYS (Multiple Advisories)
Red Hat: CVE-2024-26589: kernel: bpf: Reject variable offset alu on PTR_TO_FLOW_KEYS (Multiple Advisories) Severity 4 CVSS (AV:L/AC:H/Au:M/C:N/I:N/A:C) Published 02/22/2024 Created 12/06/2024 Added 12/05/2024 Modified 12/05/2024 Description In the Linux kernel, the following vulnerability has been resolved: bpf: Reject variable offset alu on PTR_TO_FLOW_KEYS For PTR_TO_FLOW_KEYS, check_flow_keys_access() only uses fixed off for validation. However, variable offset ptr alu is not prohibited for this ptr kind. So the variable offset is not checked. The following prog is accepted: func#0 @0 0: R1=ctx() R10=fp0 0: (bf) r6 = r1 ; R1=ctx() R6_w=ctx() 1: (79) r7 = *(u64 *)(r6 +144); R6_w=ctx() R7_w=flow_keys() 2: (b7) r8 = 1024 ; R8_w=1024 3: (37) r8 /= 1 ; R8_w=scalar() 4: (57) r8 &= 1024; R8_w=scalar(smin=smin32=0, smax=umax=smax32=umax32=1024,var_off=(0x0; 0x400)) 5: (0f) r7 += r8 mark_precise: frame0: last_idx 5 first_idx 0 subseq_idx -1 mark_precise: frame0: regs=r8 stack= before 4: (57) r8 &= 1024 mark_precise: frame0: regs=r8 stack= before 3: (37) r8 /= 1 mark_precise: frame0: regs=r8 stack= before 2: (b7) r8 = 1024 6: R7_w=flow_keys(smin=smin32=0,smax=umax=smax32=umax32=1024,var_off =(0x0; 0x400)) R8_w=scalar(smin=smin32=0,smax=umax=smax32=umax32=1024, var_off=(0x0; 0x400)) 6: (79) r0 = *(u64 *)(r7 +0); R0_w=scalar() 7: (95) exit This prog loads flow_keys to r7, and adds the variable offset r8 to r7, and finally causes out-of-bounds access: BUG: unable to handle page fault for address: ffffc90014c80038 [...] Call Trace: <TASK> bpf_dispatcher_nop_func include/linux/bpf.h:1231 [inline] __bpf_prog_run include/linux/filter.h:651 [inline] bpf_prog_run include/linux/filter.h:658 [inline] bpf_prog_run_pin_on_cpu include/linux/filter.h:675 [inline] bpf_flow_dissect+0x15f/0x350 net/core/flow_dissector.c:991 bpf_prog_test_run_flow_dissector+0x39d/0x620 net/bpf/test_run.c:1359 bpf_prog_test_run kernel/bpf/syscall.c:4107 [inline] __sys_bpf+0xf8f/0x4560 kernel/bpf/syscall.c:5475 __do_sys_bpf kernel/bpf/syscall.c:5561 [inline] __se_sys_bpf kernel/bpf/syscall.c:5559 [inline] __x64_sys_bpf+0x73/0xb0 kernel/bpf/syscall.c:5559 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x3f/0x110 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b Fix this by rejecting ptr alu with variable offset on flow_keys. Applying the patch rejects the program with "R7 pointer arithmetic on flow_keys prohibited". Solution(s) redhat-upgrade-kernel redhat-upgrade-kernel-rt References CVE-2024-26589 RHSA-2024:9315
-
Red Hat: CVE-2024-26591: kernel: bpf: Fix re-attachment branch in bpf_tracing_prog_attach (Multiple Advisories)
Red Hat: CVE-2024-26591: kernel: bpf: Fix re-attachment branch in bpf_tracing_prog_attach (Multiple Advisories) Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 02/22/2024 Created 12/06/2024 Added 12/05/2024 Modified 12/05/2024 Description In the Linux kernel, the following vulnerability has been resolved: bpf: Fix re-attachment branch in bpf_tracing_prog_attach The following case can cause a crash due to missing attach_btf: 1) load rawtp program 2) load fentry program with rawtp as target_fd 3) create tracing link for fentry program with target_fd = 0 4) repeat 3 In the end we have: - prog->aux->dst_trampoline == NULL - tgt_prog == NULL (because we did not provide target_fd to link_create) - prog->aux->attach_btf == NULL (the program was loaded with attach_prog_fd=X) - the program was loaded for tgt_prog but we have no way to find out which one BUG: kernel NULL pointer dereference, address: 0000000000000058 Call Trace: <TASK> ? __die+0x20/0x70 ? page_fault_oops+0x15b/0x430 ? fixup_exception+0x22/0x330 ? exc_page_fault+0x6f/0x170 ? asm_exc_page_fault+0x22/0x30 ? bpf_tracing_prog_attach+0x279/0x560 ? btf_obj_id+0x5/0x10 bpf_tracing_prog_attach+0x439/0x560 __sys_bpf+0x1cf4/0x2de0 __x64_sys_bpf+0x1c/0x30 do_syscall_64+0x41/0xf0 entry_SYSCALL_64_after_hwframe+0x6e/0x76 Return -EINVAL in this situation. Solution(s) redhat-upgrade-kernel redhat-upgrade-kernel-rt References CVE-2024-26591 RHSA-2024:9315
-
Huawei EulerOS: CVE-2023-52451: kernel security update
Huawei EulerOS: CVE-2023-52451: kernel security update Severity 7 CVSS (AV:L/AC:L/Au:S/C:C/I:C/A:C) Published 02/22/2024 Created 07/02/2024 Added 07/01/2024 Modified 01/30/2025 Description In the Linux kernel, the following vulnerability has been resolved: powerpc/pseries/memhp: Fix access beyond end of drmem array dlpar_memory_remove_by_index() may access beyond the bounds of the drmem lmb array when the LMB lookup fails to match an entry with the given DRC index. When the search fails, the cursor is left pointing to &drmem_info->lmbs[drmem_info->n_lmbs], which is one element past the last valid entry in the array. The debug message at the end of the function then dereferences this pointer: pr_debug("Failed to hot-remove memory at %llx\n", lmb->base_addr); This was found by inspection and confirmed with KASAN: pseries-hotplug-mem: Attempting to hot-remove LMB, drc index 1234 ================================================================== BUG: KASAN: slab-out-of-bounds in dlpar_memory+0x298/0x1658 Read of size 8 at addr c000000364e97fd0 by task bash/949 dump_stack_lvl+0xa4/0xfc (unreliable) print_report+0x214/0x63c kasan_report+0x140/0x2e0 __asan_load8+0xa8/0xe0 dlpar_memory+0x298/0x1658 handle_dlpar_errorlog+0x130/0x1d0 dlpar_store+0x18c/0x3e0 kobj_attr_store+0x68/0xa0 sysfs_kf_write+0xc4/0x110 kernfs_fop_write_iter+0x26c/0x390 vfs_write+0x2d4/0x4e0 ksys_write+0xac/0x1a0 system_call_exception+0x268/0x530 system_call_vectored_common+0x15c/0x2ec Allocated by task 1: kasan_save_stack+0x48/0x80 kasan_set_track+0x34/0x50 kasan_save_alloc_info+0x34/0x50 __kasan_kmalloc+0xd0/0x120 __kmalloc+0x8c/0x320 kmalloc_array.constprop.0+0x48/0x5c drmem_init+0x2a0/0x41c do_one_initcall+0xe0/0x5c0 kernel_init_freeable+0x4ec/0x5a0 kernel_init+0x30/0x1e0 ret_from_kernel_user_thread+0x14/0x1c The buggy address belongs to the object at c000000364e80000 which belongs to the cache kmalloc-128k of size 131072 The buggy address is located 0 bytes to the right of allocated 98256-byte region [c000000364e80000, c000000364e97fd0) ================================================================== pseries-hotplug-mem: Failed to hot-remove memory at 0 Log failed lookups with a separate message and dereference the cursor only when it points to a valid entry. Solution(s) huawei-euleros-2_0_sp12-upgrade-bpftool huawei-euleros-2_0_sp12-upgrade-kernel huawei-euleros-2_0_sp12-upgrade-kernel-abi-stablelists huawei-euleros-2_0_sp12-upgrade-kernel-tools huawei-euleros-2_0_sp12-upgrade-kernel-tools-libs huawei-euleros-2_0_sp12-upgrade-python3-perf References https://attackerkb.com/topics/cve-2023-52451 CVE - 2023-52451 EulerOS-SA-2024-1873
-
Oracle Linux: CVE-2024-25126: ELSA-2024-2113: pcs security update (MODERATE) (Multiple Advisories)
Oracle Linux: CVE-2024-25126: ELSA-2024-2113:pcs security update (MODERATE) (Multiple Advisories) Severity 5 CVSS (AV:N/AC:L/Au:N/C:N/I:N/A:P) Published 02/22/2024 Created 05/22/2024 Added 05/07/2024 Modified 01/07/2025 Description Rack is a modular Ruby web server interface. Carefully crafted content type headers can cause Rack’s media type parser to take much longer than expected, leading to a possible denial of service vulnerability (ReDos 2nd degree polynomial). This vulnerability is patched in 3.0.9.1 and 2.2.8.1. A denial of service (DoS) vulnerability was found in rubygem-rack in how it parses Content-Type. Carefully crafted content type headers can cause Rack’s media type parser to take much longer than expected, leading to a possible denial of service vulnerability. Solution(s) oracle-linux-upgrade-pcs oracle-linux-upgrade-pcs-snmp References https://attackerkb.com/topics/cve-2024-25126 CVE - 2024-25126 ELSA-2024-2113 ELSA-2024-2953
-
Huawei EulerOS: CVE-2024-26589: kernel security update
Huawei EulerOS: CVE-2024-26589: kernel security update Severity 7 CVSS (AV:L/AC:L/Au:S/C:C/I:C/A:C) Published 02/22/2024 Created 07/02/2024 Added 07/01/2024 Modified 01/30/2025 Description In the Linux kernel, the following vulnerability has been resolved: bpf: Reject variable offset alu on PTR_TO_FLOW_KEYS For PTR_TO_FLOW_KEYS, check_flow_keys_access() only uses fixed off for validation. However, variable offset ptr alu is not prohibited for this ptr kind. So the variable offset is not checked. The following prog is accepted: func#0 @0 0: R1=ctx() R10=fp0 0: (bf) r6 = r1 ; R1=ctx() R6_w=ctx() 1: (79) r7 = *(u64 *)(r6 +144); R6_w=ctx() R7_w=flow_keys() 2: (b7) r8 = 1024 ; R8_w=1024 3: (37) r8 /= 1 ; R8_w=scalar() 4: (57) r8 &= 1024; R8_w=scalar(smin=smin32=0, smax=umax=smax32=umax32=1024,var_off=(0x0; 0x400)) 5: (0f) r7 += r8 mark_precise: frame0: last_idx 5 first_idx 0 subseq_idx -1 mark_precise: frame0: regs=r8 stack= before 4: (57) r8 &= 1024 mark_precise: frame0: regs=r8 stack= before 3: (37) r8 /= 1 mark_precise: frame0: regs=r8 stack= before 2: (b7) r8 = 1024 6: R7_w=flow_keys(smin=smin32=0,smax=umax=smax32=umax32=1024,var_off =(0x0; 0x400)) R8_w=scalar(smin=smin32=0,smax=umax=smax32=umax32=1024, var_off=(0x0; 0x400)) 6: (79) r0 = *(u64 *)(r7 +0); R0_w=scalar() 7: (95) exit This prog loads flow_keys to r7, and adds the variable offset r8 to r7, and finally causes out-of-bounds access: BUG: unable to handle page fault for address: ffffc90014c80038 [...] Call Trace: <TASK> bpf_dispatcher_nop_func include/linux/bpf.h:1231 [inline] __bpf_prog_run include/linux/filter.h:651 [inline] bpf_prog_run include/linux/filter.h:658 [inline] bpf_prog_run_pin_on_cpu include/linux/filter.h:675 [inline] bpf_flow_dissect+0x15f/0x350 net/core/flow_dissector.c:991 bpf_prog_test_run_flow_dissector+0x39d/0x620 net/bpf/test_run.c:1359 bpf_prog_test_run kernel/bpf/syscall.c:4107 [inline] __sys_bpf+0xf8f/0x4560 kernel/bpf/syscall.c:5475 __do_sys_bpf kernel/bpf/syscall.c:5561 [inline] __se_sys_bpf kernel/bpf/syscall.c:5559 [inline] __x64_sys_bpf+0x73/0xb0 kernel/bpf/syscall.c:5559 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x3f/0x110 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b Fix this by rejecting ptr alu with variable offset on flow_keys. Applying the patch rejects the program with "R7 pointer arithmetic on flow_keys prohibited". 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-26589 CVE - 2024-26589 EulerOS-SA-2024-1873
-
Oracle Linux: CVE-2023-52451: ELSA-2024-5101: kernel security update (IMPORTANT) (Multiple Advisories)
Oracle Linux: CVE-2023-52451: ELSA-2024-5101:kernel security update (IMPORTANT) (Multiple Advisories) Severity 4 CVSS (AV:L/AC:L/Au:M/C:N/I:N/A:C) Published 02/22/2024 Created 10/18/2024 Added 10/16/2024 Modified 11/29/2024 Description In the Linux kernel, the following vulnerability has been resolved: powerpc/pseries/memhp: Fix access beyond end of drmem array dlpar_memory_remove_by_index() may access beyond the bounds of the drmem lmb array when the LMB lookup fails to match an entry with the given DRC index. When the search fails, the cursor is left pointing to &drmem_info->lmbs[drmem_info->n_lmbs], which is one element past the last valid entry in the array. The debug message at the end of the function then dereferences this pointer: pr_debug("Failed to hot-remove memory at %llx\n", lmb->base_addr); This was found by inspection and confirmed with KASAN: pseries-hotplug-mem: Attempting to hot-remove LMB, drc index 1234 ================================================================== BUG: KASAN: slab-out-of-bounds in dlpar_memory+0x298/0x1658 Read of size 8 at addr c000000364e97fd0 by task bash/949 dump_stack_lvl+0xa4/0xfc (unreliable) print_report+0x214/0x63c kasan_report+0x140/0x2e0 __asan_load8+0xa8/0xe0 dlpar_memory+0x298/0x1658 handle_dlpar_errorlog+0x130/0x1d0 dlpar_store+0x18c/0x3e0 kobj_attr_store+0x68/0xa0 sysfs_kf_write+0xc4/0x110 kernfs_fop_write_iter+0x26c/0x390 vfs_write+0x2d4/0x4e0 ksys_write+0xac/0x1a0 system_call_exception+0x268/0x530 system_call_vectored_common+0x15c/0x2ec Allocated by task 1: kasan_save_stack+0x48/0x80 kasan_set_track+0x34/0x50 kasan_save_alloc_info+0x34/0x50 __kasan_kmalloc+0xd0/0x120 __kmalloc+0x8c/0x320 kmalloc_array.constprop.0+0x48/0x5c drmem_init+0x2a0/0x41c do_one_initcall+0xe0/0x5c0 kernel_init_freeable+0x4ec/0x5a0 kernel_init+0x30/0x1e0 ret_from_kernel_user_thread+0x14/0x1c The buggy address belongs to the object at c000000364e80000 which belongs to the cache kmalloc-128k of size 131072 The buggy address is located 0 bytes to the right of allocated 98256-byte region [c000000364e80000, c000000364e97fd0) ================================================================== pseries-hotplug-mem: Failed to hot-remove memory at 0 Log failed lookups with a separate message and dereference the cursor only when it points to a valid entry. Solution(s) oracle-linux-upgrade-kernel References https://attackerkb.com/topics/cve-2023-52451 CVE - 2023-52451 ELSA-2024-5101
-
Oracle Linux: CVE-2023-52448: ELSA-2024-2394: kernel security, bug fix, and enhancement update (IMPORTANT) (Multiple Advisories)
Oracle Linux: CVE-2023-52448: ELSA-2024-2394:kernel security, bug fix, and enhancement update (IMPORTANT) (Multiple Advisories) Severity 4 CVSS (AV:L/AC:H/Au:S/C:N/I:N/A:C) Published 02/22/2024 Created 05/21/2024 Added 05/14/2024 Modified 01/07/2025 Description In the Linux kernel, the following vulnerability has been resolved: gfs2: Fix kernel NULL pointer dereference in gfs2_rgrp_dump Syzkaller has reported a NULL pointer dereference when accessing rgd->rd_rgl in gfs2_rgrp_dump().This can happen when creating rgd->rd_gl fails in read_rindex_entry().Add a NULL pointer check in gfs2_rgrp_dump() to prevent that. A NULL pointer dereference flaw was found in the Linux kernel when accessing the rgd->rd_rgl in the gfs2_rgrp_dump() function. This issue may lead to a crash. Solution(s) oracle-linux-upgrade-kernel References https://attackerkb.com/topics/cve-2023-52448 CVE - 2023-52448 ELSA-2024-2394 ELSA-2024-3138
-
Debian: CVE-2023-52449: linux -- security update
Debian: CVE-2023-52449: linux -- security update Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 02/22/2024 Created 06/28/2024 Added 06/27/2024 Modified 01/28/2025 Description In the Linux kernel, the following vulnerability has been resolved: mtd: Fix gluebi NULL pointer dereference caused by ftl notifier If both ftl.ko and gluebi.ko are loaded, the notifier of ftl triggers NULL pointer dereference when trying to access ‘gluebi->desc’ in gluebi_read(). ubi_gluebi_init ubi_register_volume_notifier ubi_enumerate_volumes ubi_notify_all gluebi_notifynb->notifier_call() gluebi_create mtd_device_register mtd_device_parse_register add_mtd_device blktrans_notify_add not->add() ftl_add_mtd tr->add_mtd() scan_header mtd_read mtd_read_oob mtd_read_oob_std gluebi_read mtd->read() gluebi->desc - NULL Detailed reproduction information available at the Link [1], In the normal case, obtain gluebi->desc in the gluebi_get_device(), and access gluebi->desc in the gluebi_read(). However, gluebi_get_device() is not executed in advance in the ftl_add_mtd() process, which leads to NULL pointer dereference. The solution for the gluebi module is to run jffs2 on the UBI volume without considering working with ftl or mtdblock [2]. Therefore, this problem can be avoided by preventing gluebi from creating the mtdblock device after creating mtd partition of the type MTD_UBIVOLUME. Solution(s) debian-upgrade-linux References https://attackerkb.com/topics/cve-2023-52449 CVE - 2023-52449 DLA-3840-1 DLA-3841-1
-
Debian: CVE-2023-3966: openvswitch -- security update
Debian: CVE-2023-3966: openvswitch -- security update Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 02/22/2024 Created 03/19/2024 Added 03/18/2024 Modified 03/18/2024 Description A flaw was found in Open vSwitch where multiple versions are vulnerable to crafted Geneve packets, which may result in a denial of service and invalid memory accesses. Triggering this issue requires that hardware offloading via the netlink path is enabled. Solution(s) debian-upgrade-openvswitch References https://attackerkb.com/topics/cve-2023-3966 CVE - 2023-3966 DSA-5640-1