Vulnerabilities

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.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: don&amp;#39;t drop extent_map for free space inode on write error<br /> <br /> While running the CI for an unrelated change I hit the following panic<br /> with generic/648 on btrfs_holes_spacecache.<br /> <br /> assertion failed: block_start != EXTENT_MAP_HOLE, in fs/btrfs/extent_io.c:1385<br /> ------------[ cut here ]------------<br /> kernel BUG at fs/btrfs/extent_io.c:1385!<br /> invalid opcode: 0000 [#1] PREEMPT SMP NOPTI<br /> CPU: 1 PID: 2695096 Comm: fsstress Kdump: loaded Tainted: G W 6.8.0-rc2+ #1<br /> RIP: 0010:__extent_writepage_io.constprop.0+0x4c1/0x5c0<br /> Call Trace:<br /> <br /> extent_write_cache_pages+0x2ac/0x8f0<br /> extent_writepages+0x87/0x110<br /> do_writepages+0xd5/0x1f0<br /> filemap_fdatawrite_wbc+0x63/0x90<br /> __filemap_fdatawrite_range+0x5c/0x80<br /> btrfs_fdatawrite_range+0x1f/0x50<br /> btrfs_write_out_cache+0x507/0x560<br /> btrfs_write_dirty_block_groups+0x32a/0x420<br /> commit_cowonly_roots+0x21b/0x290<br /> btrfs_commit_transaction+0x813/0x1360<br /> btrfs_sync_file+0x51a/0x640<br /> __x64_sys_fdatasync+0x52/0x90<br /> do_syscall_64+0x9c/0x190<br /> entry_SYSCALL_64_after_hwframe+0x6e/0x76<br /> <br /> This happens because we fail to write out the free space cache in one<br /> instance, come back around and attempt to write it again. However on<br /> the second pass through we go to call btrfs_get_extent() on the inode to<br /> get the extent mapping. Because this is a new block group, and with the<br /> free space inode we always search the commit root to avoid deadlocking<br /> with the tree, we find nothing and return a EXTENT_MAP_HOLE for the<br /> requested range.<br /> <br /> This happens because the first time we try to write the space cache out<br /> we hit an error, and on an error we drop the extent mapping. This is<br /> normal for normal files, but the free space cache inode is special. We<br /> always expect the extent map to be correct. Thus the second time<br /> through we end up with a bogus extent map.<br /> <br /> Since we&amp;#39;re deprecating this feature, the most straightforward way to<br /> fix this is to simply skip dropping the extent map range for this failed<br /> range.<br /> <br /> I shortened the test by using error injection to stress the area to make<br /> it easier to reproduce. With this patch in place we no longer panic<br /> with my error injection test.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: do not ASSERT() if the newly created subvolume already got read<br /> <br /> [BUG]<br /> There is a syzbot crash, triggered by the ASSERT() during subvolume<br /> creation:<br /> <br /> assertion failed: !anon_dev, in fs/btrfs/disk-io.c:1319<br /> ------------[ cut here ]------------<br /> kernel BUG at fs/btrfs/disk-io.c:1319!<br /> invalid opcode: 0000 [#1] PREEMPT SMP KASAN<br /> RIP: 0010:btrfs_get_root_ref.part.0+0x9aa/0xa60<br /> <br /> btrfs_get_new_fs_root+0xd3/0xf0<br /> create_subvol+0xd02/0x1650<br /> btrfs_mksubvol+0xe95/0x12b0<br /> __btrfs_ioctl_snap_create+0x2f9/0x4f0<br /> btrfs_ioctl_snap_create+0x16b/0x200<br /> btrfs_ioctl+0x35f0/0x5cf0<br /> __x64_sys_ioctl+0x19d/0x210<br /> do_syscall_64+0x3f/0xe0<br /> entry_SYSCALL_64_after_hwframe+0x63/0x6b<br /> ---[ end trace 0000000000000000 ]---<br /> <br /> [CAUSE]<br /> During create_subvol(), after inserting root item for the newly created<br /> subvolume, we would trigger btrfs_get_new_fs_root() to get the<br /> btrfs_root of that subvolume.<br /> <br /> The idea here is, we have preallocated an anonymous device number for<br /> the subvolume, thus we can assign it to the new subvolume.<br /> <br /> But there is really nothing preventing things like backref walk to read<br /> the new subvolume.<br /> If that happens before we call btrfs_get_new_fs_root(), the subvolume<br /> would be read out, with a new anonymous device number assigned already.<br /> <br /> In that case, we would trigger ASSERT(), as we really expect no one to<br /> read out that subvolume (which is not yet accessible from the fs).<br /> But things like backref walk is still possible to trigger the read on<br /> the subvolume.<br /> <br /> Thus our assumption on the ASSERT() is not correct in the first place.<br /> <br /> [FIX]<br /> Fix it by removing the ASSERT(), and just free the @anon_dev, reset it<br /> to 0, and continue.<br /> <br /> If the subvolume tree is read out by something else, it should have<br /> already get a new anon_dev assigned thus we only need to free the<br /> preallocated one.

Puwell Cloud Tech Co, Ltd 360Eyes Pro v3.9.5.16(3090516) was discovered to transmit sensitive information in cleartext. This vulnerability allows attackers to intercept and access sensitive information, including users&amp;#39; credentials and password change requests.