Vulnerabilities

TP-Link Omada ER605 Access Control Command Injection Remote Code Execution Vulnerability. This vulnerability allows network-adjacent attackers to execute arbitrary code on affected installations of TP-Link Omada ER605. Authentication is required to exploit this vulnerability.<br /> <br /> The specific issue exists within the handling of the name field in the access control user interface. The issue results from the lack of proper validation of a user-supplied string before using it to execute a system call. An attacker can leverage this vulnerability to execute code in the context of root. Was ZDI-CAN-22227.

A vulnerability in the web-based management interface of Cisco Nexus Dashboard and Cisco Nexus Dashboard hosted services could allow an unauthenticated, remote attacker to conduct a cross-site request forgery (CSRF) attack on an affected system.<br /> <br /> This vulnerability is due to insufficient CSRF protections for the web-based management interface on an affected system. An attacker could exploit this vulnerability by persuading a user to click a malicious link. A successful exploit could allow the attacker to perform arbitrary actions with the privilege level of the affected user. If the affected user has administrative privileges, these actions could include modifying the system configuration and creating new privileged accounts.<br /> <br /> Note: There are internal security mechanisms in place that limit the scope of this exploit, reducing the Security Impact Rating of this vulnerability.

A vulnerability in Cisco Nexus Dashboard could allow an authenticated, local attacker with valid rescue-user credentials to elevate privileges to root on an affected device.<br /> <br /> This vulnerability is due to insufficient protections for a sensitive access token. An attacker could exploit this vulnerability by using this token to access resources within the device infrastructure. A successful exploit could allow an attacker to gain root access to the filesystem or hosted containers on an affected device.

In VeridiumID before 3.5.0, the WebAuthn API allows an internal unauthenticated attacker (who can pass enrollment verifications and is allowed to enroll a FIDO key) to register their FIDO authenticator to a victim’s account and consequently take over the account.

If an insecure element was added to a page after a delay, Firefox would not replace the secure icon with a mixed content security status This vulnerability affects Firefox for iOS

Dragging Javascript URLs to the address bar could cause them to be loaded, bypassing restrictions and security protections This vulnerability affects Firefox for iOS

Rejected reason: DO NOT USE THIS CANDIDATE NUMBER. ConsultIDs: none. Reason: This candidate was withdrawn by its CNA. Further investigation showed that it was not a security issue. Notes: none.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/i915/dsc: Fix the macro that calculates DSCC_/DSCA_ PPS reg address<br /> <br /> Commit bd077259d0a9 ("drm/i915/vdsc: Add function to read any PPS<br /> register") defines a new macro to calculate the DSC PPS register<br /> addresses with PPS number as an input. This macro correctly calculates<br /> the addresses till PPS 11 since the addresses increment by 4. So in that<br /> case the following macro works correctly to give correct register<br /> address:<br /> <br /> _MMIO(_DSCA_PPS_0 + (pps) * 4)<br /> <br /> However after PPS 11, the register address for PPS 12 increments by 12<br /> because of RC Buffer memory allocation in between. Because of this<br /> discontinuity in the address space, the macro calculates wrong addresses<br /> for PPS 12 - 16 resulting into incorrect DSC PPS parameter value<br /> read/writes causing DSC corruption.<br /> <br /> This fixes it by correcting this macro to add the offset of 12 for PPS<br /> &gt;=12.<br /> <br /> v3: Add correct paranthesis for pps argument (Jani Nikula)<br /> <br /> (cherry picked from commit 6074be620c31dc2ae11af96a1a5ea95580976fb5)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: rt5645: Fix deadlock in rt5645_jack_detect_work()<br /> <br /> There is a path in rt5645_jack_detect_work(), where rt5645-&gt;jd_mutex<br /> is left locked forever. That may lead to deadlock<br /> when rt5645_jack_detect_work() is called for the second time.<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with SVACE.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> lan966x: Fix crash when adding interface under a lag<br /> <br /> There is a crash when adding one of the lan966x interfaces under a lag<br /> interface. The issue can be reproduced like this:<br /> ip link add name bond0 type bond miimon 100 mode balance-xor<br /> ip link set dev eth0 master bond0<br /> <br /> The reason is because when adding a interface under the lag it would go<br /> through all the ports and try to figure out which other ports are under<br /> that lag interface. And the issue is that lan966x can have ports that are<br /> NULL pointer as they are not probed. So then iterating over these ports<br /> it would just crash as they are NULL pointers.<br /> The fix consists in actually checking for NULL pointers before accessing<br /> something from the ports. Like we do in other places.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5: DPLL, Fix possible use after free after delayed work timer triggers<br /> <br /> I managed to hit following use after free warning recently:<br /> <br /> [ 2169.711665] ==================================================================<br /> [ 2169.714009] BUG: KASAN: slab-use-after-free in __run_timers.part.0+0x179/0x4c0<br /> [ 2169.716293] Write of size 8 at addr ffff88812b326a70 by task swapper/4/0<br /> <br /> [ 2169.719022] CPU: 4 PID: 0 Comm: swapper/4 Not tainted 6.8.0-rc2jiri+ #2<br /> [ 2169.720974] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014<br /> [ 2169.722457] Call Trace:<br /> [ 2169.722756] <br /> [ 2169.723024] dump_stack_lvl+0x58/0xb0<br /> [ 2169.723417] print_report+0xc5/0x630<br /> [ 2169.723807] ? __virt_addr_valid+0x126/0x2b0<br /> [ 2169.724268] kasan_report+0xbe/0xf0<br /> [ 2169.724667] ? __run_timers.part.0+0x179/0x4c0<br /> [ 2169.725116] ? __run_timers.part.0+0x179/0x4c0<br /> [ 2169.725570] __run_timers.part.0+0x179/0x4c0<br /> [ 2169.726003] ? call_timer_fn+0x320/0x320<br /> [ 2169.726404] ? lock_downgrade+0x3a0/0x3a0<br /> [ 2169.726820] ? kvm_clock_get_cycles+0x14/0x20<br /> [ 2169.727257] ? ktime_get+0x92/0x150<br /> [ 2169.727630] ? lapic_next_deadline+0x35/0x60<br /> [ 2169.728069] run_timer_softirq+0x40/0x80<br /> [ 2169.728475] __do_softirq+0x1a1/0x509<br /> [ 2169.728866] irq_exit_rcu+0x95/0xc0<br /> [ 2169.729241] sysvec_apic_timer_interrupt+0x6b/0x80<br /> [ 2169.729718] <br /> [ 2169.729993] <br /> [ 2169.730259] asm_sysvec_apic_timer_interrupt+0x16/0x20<br /> [ 2169.730755] RIP: 0010:default_idle+0x13/0x20<br /> [ 2169.731190] Code: c0 08 00 00 00 4d 29 c8 4c 01 c7 4c 29 c2 e9 72 ff ff ff cc cc cc cc 8b 05 9a 7f 1f 02 85 c0 7e 07 0f 00 2d cf 69 43 00 fb f4 c3 66 66 2e 0f 1f 84 00 00 00 00 00 65 48 8b 04 25 c0 93 04 00<br /> [ 2169.732759] RSP: 0018:ffff888100dbfe10 EFLAGS: 00000242<br /> [ 2169.733264] RAX: 0000000000000001 RBX: ffff888100d9c200 RCX: ffffffff8241bd62<br /> [ 2169.733925] RDX: ffffed109a848b15 RSI: 0000000000000004 RDI: ffffffff8127ac55<br /> [ 2169.734566] RBP: 0000000000000004 R08: 0000000000000000 R09: ffffed109a848b14<br /> [ 2169.735200] R10: ffff8884d42458a3 R11: 000000000000ba7e R12: ffffffff83d7d3a0<br /> [ 2169.735835] R13: 1ffff110201b7fc6 R14: 0000000000000000 R15: ffff888100d9c200<br /> [ 2169.736478] ? ct_kernel_exit.constprop.0+0xa2/0xc0<br /> [ 2169.736954] ? do_idle+0x285/0x290<br /> [ 2169.737323] default_idle_call+0x63/0x90<br /> [ 2169.737730] do_idle+0x285/0x290<br /> [ 2169.738089] ? arch_cpu_idle_exit+0x30/0x30<br /> [ 2169.738511] ? mark_held_locks+0x1a/0x80<br /> [ 2169.738917] ? lockdep_hardirqs_on_prepare+0x12e/0x200<br /> [ 2169.739417] cpu_startup_entry+0x30/0x40<br /> [ 2169.739825] start_secondary+0x19a/0x1c0<br /> [ 2169.740229] ? set_cpu_sibling_map+0xbd0/0xbd0<br /> [ 2169.740673] secondary_startup_64_no_verify+0x15d/0x16b<br /> [ 2169.741179] <br /> <br /> [ 2169.741686] Allocated by task 1098:<br /> [ 2169.742058] kasan_save_stack+0x1c/0x40<br /> [ 2169.742456] kasan_save_track+0x10/0x30<br /> [ 2169.742852] __kasan_kmalloc+0x83/0x90<br /> [ 2169.743246] mlx5_dpll_probe+0xf5/0x3c0 [mlx5_dpll]<br /> [ 2169.743730] auxiliary_bus_probe+0x62/0xb0<br /> [ 2169.744148] really_probe+0x127/0x590<br /> [ 2169.744534] __driver_probe_device+0xd2/0x200<br /> [ 2169.744973] device_driver_attach+0x6b/0xf0<br /> [ 2169.745402] bind_store+0x90/0xe0<br /> [ 2169.745761] kernfs_fop_write_iter+0x1df/0x2a0<br /> [ 2169.746210] vfs_write+0x41f/0x790<br /> [ 2169.746579] ksys_write+0xc7/0x160<br /> [ 2169.746947] do_syscall_64+0x6f/0x140<br /> [ 2169.747333] entry_SYSCALL_64_after_hwframe+0x46/0x4e<br /> <br /> [ 2169.748049] Freed by task 1220:<br /> [ 2169.748393] kasan_save_stack+0x1c/0x40<br /> [ 2169.748789] kasan_save_track+0x10/0x30<br /> [ 2169.749188] kasan_save_free_info+0x3b/0x50<br /> [ 2169.749621] poison_slab_object+0x106/0x180<br /> [ 2169.750044] __kasan_slab_free+0x14/0x50<br /> [ 2169.750451] kfree+0x118/0x330<br /> [ 2169.750792] mlx5_dpll_remove+0xf5/0x110 [mlx5_dpll]<br /> [ 2169.751271] auxiliary_bus_remove+0x2e/0x40<br /> [ 2169.751694] device_release_driver_internal+0x24b/0x2e0<br /> [ 2169.752191] unbind_store+0xa6/0xb0<br /> [ 2169.752563] kernfs_fo<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dpll: fix possible deadlock during netlink dump operation<br /> <br /> Recently, I&amp;#39;ve been hitting following deadlock warning during dpll pin<br /> dump:<br /> <br /> [52804.637962] ======================================================<br /> [52804.638536] WARNING: possible circular locking dependency detected<br /> [52804.639111] 6.8.0-rc2jiri+ #1 Not tainted<br /> [52804.639529] ------------------------------------------------------<br /> [52804.640104] python3/2984 is trying to acquire lock:<br /> [52804.640581] ffff88810e642678 (nlk_cb_mutex-GENERIC){+.+.}-{3:3}, at: netlink_dump+0xb3/0x780<br /> [52804.641417]<br /> but task is already holding lock:<br /> [52804.642010] ffffffff83bde4c8 (dpll_lock){+.+.}-{3:3}, at: dpll_lock_dumpit+0x13/0x20<br /> [52804.642747]<br /> which lock already depends on the new lock.<br /> <br /> [52804.643551]<br /> the existing dependency chain (in reverse order) is:<br /> [52804.644259]<br /> -&gt; #1 (dpll_lock){+.+.}-{3:3}:<br /> [52804.644836] lock_acquire+0x174/0x3e0<br /> [52804.645271] __mutex_lock+0x119/0x1150<br /> [52804.645723] dpll_lock_dumpit+0x13/0x20<br /> [52804.646169] genl_start+0x266/0x320<br /> [52804.646578] __netlink_dump_start+0x321/0x450<br /> [52804.647056] genl_family_rcv_msg_dumpit+0x155/0x1e0<br /> [52804.647575] genl_rcv_msg+0x1ed/0x3b0<br /> [52804.648001] netlink_rcv_skb+0xdc/0x210<br /> [52804.648440] genl_rcv+0x24/0x40<br /> [52804.648831] netlink_unicast+0x2f1/0x490<br /> [52804.649290] netlink_sendmsg+0x36d/0x660<br /> [52804.649742] __sock_sendmsg+0x73/0xc0<br /> [52804.650165] __sys_sendto+0x184/0x210<br /> [52804.650597] __x64_sys_sendto+0x72/0x80<br /> [52804.651045] do_syscall_64+0x6f/0x140<br /> [52804.651474] entry_SYSCALL_64_after_hwframe+0x46/0x4e<br /> [52804.652001]<br /> -&gt; #0 (nlk_cb_mutex-GENERIC){+.+.}-{3:3}:<br /> [52804.652650] check_prev_add+0x1ae/0x1280<br /> [52804.653107] __lock_acquire+0x1ed3/0x29a0<br /> [52804.653559] lock_acquire+0x174/0x3e0<br /> [52804.653984] __mutex_lock+0x119/0x1150<br /> [52804.654423] netlink_dump+0xb3/0x780<br /> [52804.654845] __netlink_dump_start+0x389/0x450<br /> [52804.655321] genl_family_rcv_msg_dumpit+0x155/0x1e0<br /> [52804.655842] genl_rcv_msg+0x1ed/0x3b0<br /> [52804.656272] netlink_rcv_skb+0xdc/0x210<br /> [52804.656721] genl_rcv+0x24/0x40<br /> [52804.657119] netlink_unicast+0x2f1/0x490<br /> [52804.657570] netlink_sendmsg+0x36d/0x660<br /> [52804.658022] __sock_sendmsg+0x73/0xc0<br /> [52804.658450] __sys_sendto+0x184/0x210<br /> [52804.658877] __x64_sys_sendto+0x72/0x80<br /> [52804.659322] do_syscall_64+0x6f/0x140<br /> [52804.659752] entry_SYSCALL_64_after_hwframe+0x46/0x4e<br /> [52804.660281]<br /> other info that might help us debug this:<br /> <br /> [52804.661077] Possible unsafe locking scenario:<br /> <br /> [52804.661671] CPU0 CPU1<br /> [52804.662129] ---- ----<br /> [52804.662577] lock(dpll_lock);<br /> [52804.662924] lock(nlk_cb_mutex-GENERIC);<br /> [52804.663538] lock(dpll_lock);<br /> [52804.664073] lock(nlk_cb_mutex-GENERIC);<br /> [52804.664490]<br /> <br /> The issue as follows: __netlink_dump_start() calls control-&gt;start(cb)<br /> with nlk-&gt;cb_mutex held. In control-&gt;start(cb) the dpll_lock is taken.<br /> Then nlk-&gt;cb_mutex is released and taken again in netlink_dump(), while<br /> dpll_lock still being held. That leads to ABBA deadlock when another<br /> CPU races with the same operation.<br /> <br /> Fix this by moving dpll_lock taking into dumpit() callback which ensures<br /> correct lock taking order.