Vulnerabilities

Static Web Server (SWS) is a tiny and fast production-ready web server suitable to serve static web files or assets. In affected versions if directory listings are enabled for a directory that an untrusted user has upload privileges for, a malicious file name like `.txt` will allow JavaScript code execution in the context of the web server’s domain. SWS generally does not perform escaping of HTML entities on any values inserted in the directory listing. At the very least `file_name` and `current_path` could contain malicious data however. `file_uri` could also be malicious but the relevant scenarios seem to be all caught by hyper. For any web server that allow users to upload files or create directories under a name of their choosing this becomes a stored Cross-site Scripting vulnerability. Users are advised to upgrade. There are no known workarounds for this vulnerability.

The Geo Controller WordPress plugin before 8.6.5 unserializes user input via some of its AJAX actions and REST API routes, which could allow unauthenticated users to perform PHP Object Injection when a suitable gadget is present on the blog.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fork: defer linking file vma until vma is fully initialized<br /> <br /> Thorvald reported a WARNING [1]. And the root cause is below race:<br /> <br /> CPU 1 CPU 2<br /> fork hugetlbfs_fallocate<br /> dup_mmap hugetlbfs_punch_hole<br /> i_mmap_lock_write(mapping);<br /> vma_interval_tree_insert_after -- Child vma is visible through i_mmap tree.<br /> i_mmap_unlock_write(mapping);<br /> hugetlb_dup_vma_private -- Clear vma_lock outside i_mmap_rwsem!<br /> i_mmap_lock_write(mapping);<br /> hugetlb_vmdelete_list<br /> vma_interval_tree_foreach<br /> hugetlb_vma_trylock_write -- Vma_lock is cleared.<br /> tmp-&gt;vm_ops-&gt;open -- Alloc new vma_lock outside i_mmap_rwsem!<br /> hugetlb_vma_unlock_write -- Vma_lock is assigned!!!<br /> i_mmap_unlock_write(mapping);<br /> <br /> hugetlb_dup_vma_private() and hugetlb_vm_op_open() are called outside<br /> i_mmap_rwsem lock while vma lock can be used in the same time. Fix this<br /> by deferring linking file vma until vma is fully initialized. Those vmas<br /> should be initialized first before they can be used.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5e: Prevent deadlock while disabling aRFS<br /> <br /> When disabling aRFS under the `priv-&gt;state_lock`, any scheduled<br /> aRFS works are canceled using the `cancel_work_sync` function,<br /> which waits for the work to end if it has already started.<br /> However, while waiting for the work handler, the handler will<br /> try to acquire the `state_lock` which is already acquired.<br /> <br /> The worker acquires the lock to delete the rules if the state<br /> is down, which is not the worker&amp;#39;s responsibility since<br /> disabling aRFS deletes the rules.<br /> <br /> Add an aRFS state variable, which indicates whether the aRFS is<br /> enabled and prevent adding rules when the aRFS is disabled.<br /> <br /> Kernel log:<br /> <br /> ======================================================<br /> WARNING: possible circular locking dependency detected<br /> 6.7.0-rc4_net_next_mlx5_5483eb2 #1 Tainted: G I<br /> ------------------------------------------------------<br /> ethtool/386089 is trying to acquire lock:<br /> ffff88810f21ce68 ((work_completion)(&amp;rule-&gt;arfs_work)){+.+.}-{0:0}, at: __flush_work+0x74/0x4e0<br /> <br /> but task is already holding lock:<br /> ffff8884a1808cc0 (&amp;priv-&gt;state_lock){+.+.}-{3:3}, at: mlx5e_ethtool_set_channels+0x53/0x200 [mlx5_core]<br /> <br /> which lock already depends on the new lock.<br /> <br /> the existing dependency chain (in reverse order) is:<br /> <br /> -&gt; #1 (&amp;priv-&gt;state_lock){+.+.}-{3:3}:<br /> __mutex_lock+0x80/0xc90<br /> arfs_handle_work+0x4b/0x3b0 [mlx5_core]<br /> process_one_work+0x1dc/0x4a0<br /> worker_thread+0x1bf/0x3c0<br /> kthread+0xd7/0x100<br /> ret_from_fork+0x2d/0x50<br /> ret_from_fork_asm+0x11/0x20<br /> <br /> -&gt; #0 ((work_completion)(&amp;rule-&gt;arfs_work)){+.+.}-{0:0}:<br /> __lock_acquire+0x17b4/0x2c80<br /> lock_acquire+0xd0/0x2b0<br /> __flush_work+0x7a/0x4e0<br /> __cancel_work_timer+0x131/0x1c0<br /> arfs_del_rules+0x143/0x1e0 [mlx5_core]<br /> mlx5e_arfs_disable+0x1b/0x30 [mlx5_core]<br /> mlx5e_ethtool_set_channels+0xcb/0x200 [mlx5_core]<br /> ethnl_set_channels+0x28f/0x3b0<br /> ethnl_default_set_doit+0xec/0x240<br /> genl_family_rcv_msg_doit+0xd0/0x120<br /> genl_rcv_msg+0x188/0x2c0<br /> netlink_rcv_skb+0x54/0x100<br /> genl_rcv+0x24/0x40<br /> netlink_unicast+0x1a1/0x270<br /> netlink_sendmsg+0x214/0x460<br /> __sock_sendmsg+0x38/0x60<br /> __sys_sendto+0x113/0x170<br /> __x64_sys_sendto+0x20/0x30<br /> do_syscall_64+0x40/0xe0<br /> entry_SYSCALL_64_after_hwframe+0x46/0x4e<br /> <br /> other info that might help us debug this:<br /> <br /> Possible unsafe locking scenario:<br /> <br /> CPU0 CPU1<br /> ---- ----<br /> lock(&amp;priv-&gt;state_lock);<br /> lock((work_completion)(&amp;rule-&gt;arfs_work));<br /> lock(&amp;priv-&gt;state_lock);<br /> lock((work_completion)(&amp;rule-&gt;arfs_work));<br /> <br /> *** DEADLOCK ***<br /> <br /> 3 locks held by ethtool/386089:<br /> #0: ffffffff82ea7210 (cb_lock){++++}-{3:3}, at: genl_rcv+0x15/0x40<br /> #1: ffffffff82e94c88 (rtnl_mutex){+.+.}-{3:3}, at: ethnl_default_set_doit+0xd3/0x240<br /> #2: ffff8884a1808cc0 (&amp;priv-&gt;state_lock){+.+.}-{3:3}, at: mlx5e_ethtool_set_channels+0x53/0x200 [mlx5_core]<br /> <br /> stack backtrace:<br /> CPU: 15 PID: 386089 Comm: ethtool Tainted: G I 6.7.0-rc4_net_next_mlx5_5483eb2 #1<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x60/0xa0<br /> check_noncircular+0x144/0x160<br /> __lock_acquire+0x17b4/0x2c80<br /> lock_acquire+0xd0/0x2b0<br /> ? __flush_work+0x74/0x4e0<br /> ? save_trace+0x3e/0x360<br /> ? __flush_work+0x74/0x4e0<br /> __flush_work+0x7a/0x4e0<br /> ? __flush_work+0x74/0x4e0<br /> ? __lock_acquire+0xa78/0x2c80<br /> ? lock_acquire+0xd0/0x2b0<br /> ? mark_held_locks+0x49/0x70<br /> __cancel_work_timer+0x131/0x1c0<br /> ? mark_held_locks+0x49/0x70<br /> arfs_del_rules+0x143/0x1e0 [mlx5_core]<br /> mlx5e_arfs_disable+0x1b/0x30 [mlx5_core]<br /> mlx5e_ethtool_set_channels+0xcb/0x200 [mlx5_core]<br /> ethnl_set_channels+0x28f/0x3b0<br /> ethnl_default_set_doit+0xec/0x240<br /> genl_family_rcv_msg_doit+0xd0/0x120<br /> genl_rcv_msg+0x188/0x2c0<br /> ? ethn<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: flowtable: incorrect pppoe tuple<br /> <br /> pppoe traffic reaching ingress path does not match the flowtable entry<br /> because the pppoe header is expected to be at the network header offset.<br /> This bug causes a mismatch in the flow table lookup, so pppoe packets<br /> enter the classical forwarding path.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> r8169: fix LED-related deadlock on module removal<br /> <br /> Binding devm_led_classdev_register() to the netdev is problematic<br /> because on module removal we get a RTNL-related deadlock. Fix this<br /> by avoiding the device-managed LED functions.<br /> <br /> Note: We can safely call led_classdev_unregister() for a LED even<br /> if registering it failed, because led_classdev_unregister() detects<br /> this and is a no-op in this case.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: flowtable: validate pppoe header<br /> <br /> Ensure there is sufficient room to access the protocol field of the<br /> PPPoe header. Validate it once before the flowtable lookup, then use a<br /> helper function to access protocol field.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nft_set_pipapo: walk over current view on netlink dump<br /> <br /> The generation mask can be updated while netlink dump is in progress.<br /> The pipapo set backend walk iterator cannot rely on it to infer what<br /> view of the datastructure is to be used. Add notation to specify if user<br /> wants to read/update the set.<br /> <br /> Based on patch from Florian Westphal.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: br_netfilter: skip conntrack input hook for promisc packets<br /> <br /> For historical reasons, when bridge device is in promisc mode, packets<br /> that are directed to the taps follow bridge input hook path. This patch<br /> adds a workaround to reset conntrack for these packets.<br /> <br /> Jianbo Liu reports warning splats in their test infrastructure where<br /> cloned packets reach the br_netfilter input hook to confirm the<br /> conntrack object.<br /> <br /> Scratch one bit from BR_INPUT_SKB_CB to annotate that this packet has<br /> reached the input hook because it is passed up to the bridge device to<br /> reach the taps.<br /> <br /> [ 57.571874] WARNING: CPU: 1 PID: 0 at net/bridge/br_netfilter_hooks.c:616 br_nf_local_in+0x157/0x180 [br_netfilter]<br /> [ 57.572749] Modules linked in: xt_MASQUERADE nf_conntrack_netlink nfnetlink iptable_nat xt_addrtype xt_conntrack nf_nat br_netfilter rpcsec_gss_krb5 auth_rpcgss oid_registry overlay rpcrdma rdma_ucm ib_iser libiscsi scsi_transport_isc si ib_umad rdma_cm ib_ipoib iw_cm ib_cm mlx5_ib ib_uverbs ib_core mlx5ctl mlx5_core<br /> [ 57.575158] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 6.8.0+ #19<br /> [ 57.575700] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014<br /> [ 57.576662] RIP: 0010:br_nf_local_in+0x157/0x180 [br_netfilter]<br /> [ 57.577195] Code: fe ff ff 41 bd 04 00 00 00 be 04 00 00 00 e9 4a ff ff ff be 04 00 00 00 48 89 ef e8 f3 a9 3c e1 66 83 ad b4 00 00 00 04 eb 91 0b e9 f1 fe ff ff 0f 0b e9 df fe ff ff 48 89 df e8 b3 53 47 e1<br /> [ 57.578722] RSP: 0018:ffff88885f845a08 EFLAGS: 00010202<br /> [ 57.579207] RAX: 0000000000000002 RBX: ffff88812dfe8000 RCX: 0000000000000000<br /> [ 57.579830] RDX: ffff88885f845a60 RSI: ffff8881022dc300 RDI: 0000000000000000<br /> [ 57.580454] RBP: ffff88885f845a60 R08: 0000000000000001 R09: 0000000000000003<br /> [ 57.581076] R10: 00000000ffff1300 R11: 0000000000000002 R12: 0000000000000000<br /> [ 57.581695] R13: ffff8881047ffe00 R14: ffff888108dbee00 R15: ffff88814519b800<br /> [ 57.582313] FS: 0000000000000000(0000) GS:ffff88885f840000(0000) knlGS:0000000000000000<br /> [ 57.583040] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 57.583564] CR2: 000000c4206aa000 CR3: 0000000103847001 CR4: 0000000000370eb0<br /> [ 57.584194] DR0: 0000000000000000 DR1: 0000000000000000 DR2:<br /> 0000000000000000<br /> [ 57.584820] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7:<br /> 0000000000000400<br /> [ 57.585440] Call Trace:<br /> [ 57.585721] <br /> [ 57.585976] ? __warn+0x7d/0x130<br /> [ 57.586323] ? br_nf_local_in+0x157/0x180 [br_netfilter]<br /> [ 57.586811] ? report_bug+0xf1/0x1c0<br /> [ 57.587177] ? handle_bug+0x3f/0x70<br /> [ 57.587539] ? exc_invalid_op+0x13/0x60<br /> [ 57.587929] ? asm_exc_invalid_op+0x16/0x20<br /> [ 57.588336] ? br_nf_local_in+0x157/0x180 [br_netfilter]<br /> [ 57.588825] nf_hook_slow+0x3d/0xd0<br /> [ 57.589188] ? br_handle_vlan+0x4b/0x110<br /> [ 57.589579] br_pass_frame_up+0xfc/0x150<br /> [ 57.589970] ? br_port_flags_change+0x40/0x40<br /> [ 57.590396] br_handle_frame_finish+0x346/0x5e0<br /> [ 57.590837] ? ipt_do_table+0x32e/0x430<br /> [ 57.591221] ? br_handle_local_finish+0x20/0x20<br /> [ 57.591656] br_nf_hook_thresh+0x4b/0xf0 [br_netfilter]<br /> [ 57.592286] ? br_handle_local_finish+0x20/0x20<br /> [ 57.592802] br_nf_pre_routing_finish+0x178/0x480 [br_netfilter]<br /> [ 57.593348] ? br_handle_local_finish+0x20/0x20<br /> [ 57.593782] ? nf_nat_ipv4_pre_routing+0x25/0x60 [nf_nat]<br /> [ 57.594279] br_nf_pre_routing+0x24c/0x550 [br_netfilter]<br /> [ 57.594780] ? br_nf_hook_thresh+0xf0/0xf0 [br_netfilter]<br /> [ 57.595280] br_handle_frame+0x1f3/0x3d0<br /> [ 57.595676] ? br_handle_local_finish+0x20/0x20<br /> [ 57.596118] ? br_handle_frame_finish+0x5e0/0x5e0<br /> [ 57.596566] __netif_receive_skb_core+0x25b/0xfc0<br /> [ 57.597017] ? __napi_build_skb+0x37/0x40<br /> [ 57.597418] __netif_receive_skb_list_core+0xfb/0x220

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nf_tables: Fix potential data-race in __nft_obj_type_get()<br /> <br /> nft_unregister_obj() can concurrent with __nft_obj_type_get(),<br /> and there is not any protection when iterate over nf_tables_objects<br /> list in __nft_obj_type_get(). Therefore, there is potential data-race<br /> of nf_tables_objects list entry.<br /> <br /> Use list_for_each_entry_rcu() to iterate over nf_tables_objects<br /> list in __nft_obj_type_get(), and use rcu_read_lock() in the caller<br /> nft_obj_type_get() to protect the entire type query process.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nf_tables: Fix potential data-race in __nft_expr_type_get()<br /> <br /> nft_unregister_expr() can concurrent with __nft_expr_type_get(),<br /> and there is not any protection when iterate over nf_tables_expressions<br /> list in __nft_expr_type_get(). Therefore, there is potential data-race<br /> of nf_tables_expressions list entry.<br /> <br /> Use list_for_each_entry_rcu() to iterate over nf_tables_expressions<br /> list in __nft_expr_type_get(), and use rcu_read_lock() in the caller<br /> nft_expr_type_get() to protect the entire type query process.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> thermal/debugfs: Add missing count increment to thermal_debug_tz_trip_up()<br /> <br /> The count field in struct trip_stats, representing the number of times<br /> the zone temperature was above the trip point, needs to be incremented<br /> in thermal_debug_tz_trip_up(), for two reasons.<br /> <br /> First, if a trip point is crossed on the way up for the first time,<br /> thermal_debug_update_temp() called from update_temperature() does<br /> not see it because it has not been added to trips_crossed[] array<br /> in the thermal zone&amp;#39;s struct tz_debugfs object yet. Therefore, when<br /> thermal_debug_tz_trip_up() is called after that, the trip point&amp;#39;s<br /> count value is 0, and the attempt to divide by it during the average<br /> temperature computation leads to a divide error which causes the kernel<br /> to crash. Setting the count to 1 before the division by incrementing it<br /> fixes this problem.<br /> <br /> Second, if a trip point is crossed on the way up, but it has been<br /> crossed on the way up already before, its count value needs to be<br /> incremented to make a record of the fact that the zone temperature is<br /> above the trip now. Without doing that, if the mitigations applied<br /> after crossing the trip cause the zone temperature to drop below its<br /> threshold, the count will not be updated for this episode at all and<br /> the average temperature in the trip statistics record will be somewhat<br /> higher than it should be.<br /> <br /> Cc :6.8+ # 6.8+