Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Fix accesses to uninit stack slots<br /> <br /> Privileged programs are supposed to be able to read uninitialized stack<br /> memory (ever since 6715df8d5) but, before this patch, these accesses<br /> were permitted inconsistently. In particular, accesses were permitted<br /> above state-&gt;allocated_stack, but not below it. In other words, if the<br /> stack was already "large enough", the access was permitted, but<br /> otherwise the access was rejected instead of being allowed to "grow the<br /> stack". This undesired rejection was happening in two places:<br /> - in check_stack_slot_within_bounds()<br /> - in check_stack_range_initialized()<br /> This patch arranges for these accesses to be permitted. A bunch of tests<br /> that were relying on the old rejection had to change; all of them were<br /> changed to add also run unprivileged, in which case the old behavior<br /> persists. One tests couldn&amp;#39;t be updated - global_func16 - because it<br /> can&amp;#39;t run unprivileged for other reasons.<br /> <br /> This patch also fixes the tracking of the stack size for variable-offset<br /> reads. This second fix is bundled in the same commit as the first one<br /> because they&amp;#39;re inter-related. Before this patch, writes to the stack<br /> using registers containing a variable offset (as opposed to registers<br /> with fixed, known values) were not properly contributing to the<br /> function&amp;#39;s needed stack size. As a result, it was possible for a program<br /> to verify, but then to attempt to read out-of-bounds data at runtime<br /> because a too small stack had been allocated for it.<br /> <br /> Each function tracks the size of the stack it needs in<br /> bpf_subprog_info.stack_depth, which is maintained by<br /> update_stack_depth(). For regular memory accesses, check_mem_access()<br /> was calling update_state_depth() but it was passing in only the fixed<br /> part of the offset register, ignoring the variable offset. This was<br /> incorrect; the minimum possible value of that register should be used<br /> instead.<br /> <br /> This tracking is now fixed by centralizing the tracking of stack size in<br /> grow_stack_state(), and by lifting the calls to grow_stack_state() to<br /> check_stack_access_within_bounds() as suggested by Andrii. The code is<br /> now simpler and more convincingly tracks the correct maximum stack size.<br /> check_stack_range_initialized() can now rely on enough stack having been<br /> allocated for the access; this helps with the fix for the first issue.<br /> <br /> A few tests were changed to also check the stack depth computation. The<br /> one that fails without this patch is verifier_var_off:stack_write_priv_vs_unpriv.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mlxsw: spectrum_acl_tcam: Fix stack corruption<br /> <br /> When tc filters are first added to a net device, the corresponding local<br /> port gets bound to an ACL group in the device. The group contains a list<br /> of ACLs. In turn, each ACL points to a different TCAM region where the<br /> filters are stored. During forwarding, the ACLs are sequentially<br /> evaluated until a match is found.<br /> <br /> One reason to place filters in different regions is when they are added<br /> with decreasing priorities and in an alternating order so that two<br /> consecutive filters can never fit in the same region because of their<br /> key usage.<br /> <br /> In Spectrum-2 and newer ASICs the firmware started to report that the<br /> maximum number of ACLs in a group is more than 16, but the layout of the<br /> register that configures ACL groups (PAGT) was not updated to account<br /> for that. It is therefore possible to hit stack corruption [1] in the<br /> rare case where more than 16 ACLs in a group are required.<br /> <br /> Fix by limiting the maximum ACL group size to the minimum between what<br /> the firmware reports and the maximum ACLs that fit in the PAGT register.<br /> <br /> Add a test case to make sure the machine does not crash when this<br /> condition is hit.<br /> <br /> [1]<br /> Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: mlxsw_sp_acl_tcam_group_update+0x116/0x120<br /> [...]<br /> dump_stack_lvl+0x36/0x50<br /> panic+0x305/0x330<br /> __stack_chk_fail+0x15/0x20<br /> mlxsw_sp_acl_tcam_group_update+0x116/0x120<br /> mlxsw_sp_acl_tcam_group_region_attach+0x69/0x110<br /> mlxsw_sp_acl_tcam_vchunk_get+0x492/0xa20<br /> mlxsw_sp_acl_tcam_ventry_add+0x25/0xe0<br /> mlxsw_sp_acl_rule_add+0x47/0x240<br /> mlxsw_sp_flower_replace+0x1a9/0x1d0<br /> tc_setup_cb_add+0xdc/0x1c0<br /> fl_hw_replace_filter+0x146/0x1f0<br /> fl_change+0xc17/0x1360<br /> tc_new_tfilter+0x472/0xb90<br /> rtnetlink_rcv_msg+0x313/0x3b0<br /> netlink_rcv_skb+0x58/0x100<br /> netlink_unicast+0x244/0x390<br /> netlink_sendmsg+0x1e4/0x440<br /> ____sys_sendmsg+0x164/0x260<br /> ___sys_sendmsg+0x9a/0xe0<br /> __sys_sendmsg+0x7a/0xc0<br /> do_syscall_64+0x40/0xe0<br /> entry_SYSCALL_64_after_hwframe+0x63/0x6b

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: netdevsim: don&amp;#39;t try to destroy PHC on VFs<br /> <br /> PHC gets initialized in nsim_init_netdevsim(), which<br /> is only called if (nsim_dev_port_is_pf()).<br /> <br /> Create a counterpart of nsim_init_netdevsim() and<br /> move the mock_phc_destroy() there.<br /> <br /> This fixes a crash trying to destroy netdevsim with<br /> VFs instantiated, as caught by running the devlink.sh test:<br /> <br /> BUG: kernel NULL pointer dereference, address: 00000000000000b8<br /> RIP: 0010:mock_phc_destroy+0xd/0x30<br /> Call Trace:<br /> <br /> nsim_destroy+0x4a/0x70 [netdevsim]<br /> __nsim_dev_port_del+0x47/0x70 [netdevsim]<br /> nsim_dev_reload_destroy+0x105/0x120 [netdevsim]<br /> nsim_drv_remove+0x2f/0xb0 [netdevsim]<br /> device_release_driver_internal+0x1a1/0x210<br /> bus_remove_device+0xd5/0x120<br /> device_del+0x159/0x490<br /> device_unregister+0x12/0x30<br /> del_device_store+0x11a/0x1a0 [netdevsim]<br /> kernfs_fop_write_iter+0x130/0x1d0<br /> vfs_write+0x30b/0x4b0<br /> ksys_write+0x69/0xf0<br /> do_syscall_64+0xcc/0x1e0<br /> entry_SYSCALL_64_after_hwframe+0x6f/0x77

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> LoongArch: BPF: Prevent out-of-bounds memory access<br /> <br /> The test_tag test triggers an unhandled page fault:<br /> <br /> # ./test_tag<br /> [ 130.640218] CPU 0 Unable to handle kernel paging request at virtual address ffff80001b898004, era == 9000000003137f7c, ra == 9000000003139e70<br /> [ 130.640501] Oops[#3]:<br /> [ 130.640553] CPU: 0 PID: 1326 Comm: test_tag Tainted: G D O 6.7.0-rc4-loong-devel-gb62ab1a397cf #47 61985c1d94084daa2432f771daa45b56b10d8d2a<br /> [ 130.640764] Hardware name: QEMU QEMU Virtual Machine, BIOS unknown 2/2/2022<br /> [ 130.640874] pc 9000000003137f7c ra 9000000003139e70 tp 9000000104cb4000 sp 9000000104cb7a40<br /> [ 130.641001] a0 ffff80001b894000 a1 ffff80001b897ff8 a2 000000006ba210be a3 0000000000000000<br /> [ 130.641128] a4 000000006ba210be a5 00000000000000f1 a6 00000000000000b3 a7 0000000000000000<br /> [ 130.641256] t0 0000000000000000 t1 00000000000007f6 t2 0000000000000000 t3 9000000004091b70<br /> [ 130.641387] t4 000000006ba210be t5 0000000000000004 t6 fffffffffffffff0 t7 90000000040913e0<br /> [ 130.641512] t8 0000000000000005 u0 0000000000000dc0 s9 0000000000000009 s0 9000000104cb7ae0<br /> [ 130.641641] s1 00000000000007f6 s2 0000000000000009 s3 0000000000000095 s4 0000000000000000<br /> [ 130.641771] s5 ffff80001b894000 s6 ffff80001b897fb0 s7 9000000004090c50 s8 0000000000000000<br /> [ 130.641900] ra: 9000000003139e70 build_body+0x1fcc/0x4988<br /> [ 130.642007] ERA: 9000000003137f7c build_body+0xd8/0x4988<br /> [ 130.642112] CRMD: 000000b0 (PLV0 -IE -DA +PG DACF=CC DACM=CC -WE)<br /> [ 130.642261] PRMD: 00000004 (PPLV0 +PIE -PWE)<br /> [ 130.642353] EUEN: 00000003 (+FPE +SXE -ASXE -BTE)<br /> [ 130.642458] ECFG: 00071c1c (LIE=2-4,10-12 VS=7)<br /> [ 130.642554] ESTAT: 00010000 [PIL] (IS= ECode=1 EsubCode=0)<br /> [ 130.642658] BADV: ffff80001b898004<br /> [ 130.642719] PRID: 0014c010 (Loongson-64bit, Loongson-3A5000)<br /> [ 130.642815] Modules linked in: [last unloaded: bpf_testmod(O)]<br /> [ 130.642924] Process test_tag (pid: 1326, threadinfo=00000000f7f4015f, task=000000006499f9fd)<br /> [ 130.643062] Stack : 0000000000000000 9000000003380724 0000000000000000 0000000104cb7be8<br /> [ 130.643213] 0000000000000000 25af8d9b6e600558 9000000106250ea0 9000000104cb7ae0<br /> [ 130.643378] 0000000000000000 0000000000000000 9000000104cb7be8 90000000049f6000<br /> [ 130.643538] 0000000000000090 9000000106250ea0 ffff80001b894000 ffff80001b894000<br /> [ 130.643685] 00007ffffb917790 900000000313ca94 0000000000000000 0000000000000000<br /> [ 130.643831] ffff80001b894000 0000000000000ff7 0000000000000000 9000000100468000<br /> [ 130.643983] 0000000000000000 0000000000000000 0000000000000040 25af8d9b6e600558<br /> [ 130.644131] 0000000000000bb7 ffff80001b894048 0000000000000000 0000000000000000<br /> [ 130.644276] 9000000104cb7be8 90000000049f6000 0000000000000090 9000000104cb7bdc<br /> [ 130.644423] ffff80001b894000 0000000000000000 00007ffffb917790 90000000032acfb0<br /> [ 130.644572] ...<br /> [ 130.644629] Call Trace:<br /> [ 130.644641] [] build_body+0xd8/0x4988<br /> [ 130.644785] [] bpf_int_jit_compile+0x228/0x4ec<br /> [ 130.644891] [] bpf_prog_select_runtime+0x158/0x1b0<br /> [ 130.645003] [] bpf_prog_load+0x760/0xb44<br /> [ 130.645089] [] __sys_bpf+0xbb8/0x2588<br /> [ 130.645175] [] sys_bpf+0x20/0x2c<br /> [ 130.645259] [] do_syscall+0x7c/0x94<br /> [ 130.645369] [] handle_syscall+0xbc/0x158<br /> [ 130.645507]<br /> [ 130.645539] Code: 380839f6 380831f9 28412bae 004081ad 0014cb50 004083e8 02bff34c 58008e91<br /> [ 130.645729]<br /> [ 130.646418] ---[ end trace 0000000000000000 ]---<br /> <br /> On my machine, which has CONFIG_PAGE_SIZE_16KB=y, the test failed at<br /> loading a BPF prog with 2039 instructions:<br /> <br /> prog = (struct bpf_prog *)ffff80001b894000<br /> insn = (struct bpf_insn *)(prog-&gt;insnsi)fff<br /> ---truncated---

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&amp;#39;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.

The Access Point functionality in eapol_auth_key_handle in eapol.c in iNet wireless daemon (IWD) before 2.14 allows attackers to gain unauthorized access to a protected Wi-Fi network. An attacker can complete the EAPOL handshake by skipping Msg2/4 and instead sending Msg4/4 with an all-zero key.

cmseasy V7.7.7.9 has an arbitrary file deletion vulnerability in lib/admin/template_admin.php.

Hertzbeat is a real-time monitoring system. In `CalculateAlarm.java`, `AviatorEvaluator` is used to directly execute the expression function, and no security policy is configured, resulting in AviatorScript (which can execute any static method by default) script injection. Version 1.4.1 fixes this vulnerability.

Hertzbeat is a real-time monitoring system. At the interface of `/define/yml`, SnakeYAML is used as a parser to parse yml content, but no security configuration is used, resulting in a YAML deserialization vulnerability. Version 1.4.1 fixes this vulnerability.

Hertzbeat is a real-time monitoring system. In the implementation of `JmxCollectImpl.java`, `JMXConnectorFactory.connect` is vulnerable to JNDI injection. The corresponding interface is `/api/monitor/detect`. If there is a URL field, the address will be used by default. When the URL is `service:jmx:rmi:///jndi/rmi://xxxxxxx:1099/localHikari`, it can be exploited to cause remote code execution. Version 1.4.1 contains a fix for this issue.

baserCMS is a website development framework. Prior to version 5.0.9, there is a cross-site scripting vulnerability in the site search feature. Version 5.0.9 contains a fix for this vulnerability.

baserCMS is a website development framework. Prior to version 5.0.9, there is an OS Command Injection vulnerability in the site search feature of baserCMS. Version 5.0.9 contains a fix for this vulnerability.