CVSS: 7.8EPSS: 0%CPEs: 6EXPL: 0CVE-2023-52447 – bpf: Defer the free of inner map when necessary
https://notcve.org/view.php?id=CVE-2023-52447
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. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: posponer la liberación del mapa interno cuando sea necesario Al actualizar o eliminar un mapa interno en la matriz de mapas o en el htab de mapas, aún se puede acceder al mapa mediante un programa que no se puede dormir o un programa que se puede dormir. . • https://git.kernel.org/stable/c/bba1dc0b55ac462d24ed1228ad49800c238cd6d7 https://git.kernel.org/stable/c/90c445799fd1dc214d7c6279c144e33a35e29ef2 https://git.kernel.org/stable/c/37d98fb9c3144c0fddf7f6e99aece9927ac8dce6 https://git.kernel.org/stable/c/62fca83303d608ad4fec3f7428c8685680bb01b0 https://git.kernel.org/stable/c/f91cd728b10c51f6d4a39957ccd56d1e802fc8ee https://git.kernel.org/stable/c/bfd9b20c4862f41d4590fde11d70a5eeae53dcc5 https://git.kernel.org/stable/c/876673364161da50eed6b472d746ef88242b2368 https://lists.debian.org/debian-lts-announce/2024/06/ • CWE-416: Use After Free •
CVSS: 7.8EPSS: 0%CPEs: 8EXPL: 0CVE-2023-52445 – media: pvrusb2: fix use after free on context disconnection
https://notcve.org/view.php?id=CVE-2023-52445
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. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: medios: pvrusb2: corrige el use after free de desconexión de contexto. Al cargar el módulo, se crea un kthread dirigido a la función pvr2_context_thread_func, que puede llamar a pvr2_context_destroy y, por lo tanto, llamar a kfree() en el objeto de contexto. • https://git.kernel.org/stable/c/e5be15c63804e05b5a94197524023702a259e308 https://git.kernel.org/stable/c/ec36c134dd020d28e312c2f1766f85525e747aab https://git.kernel.org/stable/c/47aa8fcd5e8b5563af4042a00f25ba89bef8f33d https://git.kernel.org/stable/c/3233d8bf7893550045682192cb227af7fa3defeb https://git.kernel.org/stable/c/ec3634ebe23fc3c44ebc67c6d25917300bc68c08 https://git.kernel.org/stable/c/30773ea47d41773f9611ffb4ebc9bda9d19a9e7e https://git.kernel.org/stable/c/2cf0005d315549b8d2b940ff96a66c2a889aa795 https://git.kernel.org/stable/c/437b5f57732bb4cc32cc9f8895d2010ee • CWE-416: Use After Free •
CVSS: 7.8EPSS: 0%CPEs: 8EXPL: 0CVE-2023-52444 – f2fs: fix to avoid dirent corruption
https://notcve.org/view.php?id=CVE-2023-52444
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 '. • https://git.kernel.org/stable/c/7e01e7ad746bc8198a8b46163ddc73a1c7d22339 https://git.kernel.org/stable/c/02160112e6d45c2610b049df6eb693d7a2e57b46 https://git.kernel.org/stable/c/5624a3c1b1ebc8991318e1cce2aa719542991024 https://git.kernel.org/stable/c/6f866885e147d33efc497f1095f35b2ee5ec7310 https://git.kernel.org/stable/c/f100ba617d8be6c98a68f3744ef7617082975b77 https://git.kernel.org/stable/c/f0145860c20be6bae6785c7a2249577674702ac7 https://git.kernel.org/stable/c/d3c0b49aaa12a61d560528f5d605029ab57f0728 https://git.kernel.org/stable/c/2fb4867f4405aea8c0519d7d188207f23 • CWE-119: Improper Restriction of Operations within the Bounds of a Memory Buffer •
CVSS: 7.8EPSS: 0%CPEs: 5EXPL: 0CVE-2024-26589 – bpf: Reject variable offset alu on PTR_TO_FLOW_KEYS
https://notcve.org/view.php?id=CVE-2024-26589
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". En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: Rechazar variable offset alu en PTR_TO_FLOW_KEYS Para PTR_TO_FLOW_KEYS, check_flow_keys_access() solo usa fijo para la validación. Sin embargo, el desplazamiento variable ptr alu no está prohibido para este tipo de ptr. • https://git.kernel.org/stable/c/d58e468b1112dcd1d5193c0a89ff9f98b5a3e8b9 https://git.kernel.org/stable/c/29ffa63f21bcdcef3e36b03cccf9d0cd031f6ab0 https://git.kernel.org/stable/c/4108b86e324da42f7ed425bd71632fd844300dc8 https://git.kernel.org/stable/c/e8d3872b617c21100c5ee4f64e513997a68c2e3d https://git.kernel.org/stable/c/1b500d5d6cecf98dd6ca88bc9e7ae1783c83e6d3 https://git.kernel.org/stable/c/22c7fa171a02d310e3a3f6ed46a698ca8a0060ed • CWE-119: Improper Restriction of Operations within the Bounds of a Memory Buffer •
CVSS: 6.7EPSS: 0%CPEs: 6EXPL: 0CVE-2024-26586 – mlxsw: spectrum_acl_tcam: Fix stack corruption
https://notcve.org/view.php?id=CVE-2024-26586
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 En el kernel de Linux, se resolvió la siguiente vulnerabilidad: mlxsw: espectro_acl_tcam: corrige la corrupción de la pila Cuando los filtros tc se agregan por primera vez a un dispositivo de red, el puerto local correspondiente se vincula a un grupo ACL en el dispositivo. • https://git.kernel.org/stable/c/c3ab435466d5109b2c7525a3b90107d4d9e918fc https://git.kernel.org/stable/c/56750ea5d15426b5f307554e7699e8b5f76c3182 https://git.kernel.org/stable/c/348112522a35527c5bcba933b9fefb40a4f44f15 https://git.kernel.org/stable/c/6fd24675188d354b1cad47462969afa2ab09d819 https://git.kernel.org/stable/c/2f5e1565740490706332c06f36211d4ce0f88e62 https://git.kernel.org/stable/c/a361c2c1da5dbb13ca67601cf961ab3ad68af383 https://git.kernel.org/stable/c/483ae90d8f976f8339cf81066312e1329f2d3706 https://lists.debian.org/debian-lts-announce/2024/06/ • CWE-787: Out-of-bounds Write •