Vulnerabilities

The 'control' in Parrot ANAFI USA firmware 1.10.4 does not check the MAV_MISSION_TYPE(0, 1, 2, 255), which allows attacker to cut off the connection between a controller and the drone by sending MAVLink MISSION_COUNT command with a wrong MAV_MISSION_TYPE.

<br /> An improper export vulnerability was reported in the Motorola Enterprise MotoDpms Provider (com.motorola.server.enterprise.MotoDpmsProvider) that could allow a local attacker to read local data.

An Implicit intent vulnerability was reported in the Motorola framework that could allow an attacker to read telephony-related data.

Insecure Permissions vulnerability in e-trust Horacius 1.0, 1.1, and 1.2 allows a local attacker to escalate privileges via the password reset function.

Mullvad VPN through 2024.1 on Android does not set a DNS server in the blocking state (after a hard failure to create a tunnel), and thus DNS traffic can leave the device. Data showing that the affected device was the origin of sensitive DNS requests may be observed and logged by operators of unintended DNS servers.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> peci: cpu: Fix use-after-free in adev_release()<br /> <br /> When auxiliary_device_add() returns an error, auxiliary_device_uninit()<br /> is called, which causes refcount for device to be decremented and<br /> .release callback will be triggered.<br /> <br /> Because adev_release() re-calls auxiliary_device_uninit(), it will cause<br /> use-after-free:<br /> [ 1269.455172] WARNING: CPU: 0 PID: 14267 at lib/refcount.c:28 refcount_warn_saturate+0x110/0x15<br /> [ 1269.464007] refcount_t: underflow; use-after-free.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cgroup: Add missing cpus_read_lock() to cgroup_attach_task_all()<br /> <br /> syzbot is hitting percpu_rwsem_assert_held(&amp;cpu_hotplug_lock) warning at<br /> cpuset_attach() [1], for commit 4f7e7236435ca0ab ("cgroup: Fix<br /> threadgroup_rwsem cpus_read_lock() deadlock") missed that<br /> cpuset_attach() is also called from cgroup_attach_task_all().<br /> Add cpus_read_lock() like what cgroup_procs_write_start() does.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> of: fdt: fix off-by-one error in unflatten_dt_nodes()<br /> <br /> Commit 78c44d910d3e ("drivers/of: Fix depth when unflattening devicetree")<br /> forgot to fix up the depth check in the loop body in unflatten_dt_nodes()<br /> which makes it possible to overflow the nps[] buffer...<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with the SVACE static<br /> analysis tool.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/smc: Fix possible access to freed memory in link clear<br /> <br /> After modifying the QP to the Error state, all RX WR would be completed<br /> with WC in IB_WC_WR_FLUSH_ERR status. Current implementation does not<br /> wait for it is done, but destroy the QP and free the link group directly.<br /> So there is a risk that accessing the freed memory in tasklet context.<br /> <br /> Here is a crash example:<br /> <br /> BUG: unable to handle page fault for address: ffffffff8f220860<br /> #PF: supervisor write access in kernel mode<br /> #PF: error_code(0x0002) - not-present page<br /> PGD f7300e067 P4D f7300e067 PUD f7300f063 PMD 8c4e45063 PTE 800ffff08c9df060<br /> Oops: 0002 [#1] SMP PTI<br /> CPU: 1 PID: 0 Comm: swapper/1 Kdump: loaded Tainted: G S OE 5.10.0-0607+ #23<br /> Hardware name: Inspur NF5280M4/YZMB-00689-101, BIOS 4.1.20 07/09/2018<br /> RIP: 0010:native_queued_spin_lock_slowpath+0x176/0x1b0<br /> Code: f3 90 48 8b 32 48 85 f6 74 f6 eb d5 c1 ee 12 83 e0 03 83 ee 01 48 c1 e0 05 48 63 f6 48 05 00 c8 02 00 48 03 04 f5 00 09 98 8e 89 10 8b 42 08 85 c0 75 09 f3 90 8b 42 08 85 c0 74 f7 48 8b 32<br /> RSP: 0018:ffffb3b6c001ebd8 EFLAGS: 00010086<br /> RAX: ffffffff8f220860 RBX: 0000000000000246 RCX: 0000000000080000<br /> RDX: ffff91db1f86c800 RSI: 000000000000173c RDI: ffff91db62bace00<br /> RBP: ffff91db62bacc00 R08: 0000000000000000 R09: c00000010000028b<br /> R10: 0000000000055198 R11: ffffb3b6c001ea58 R12: ffff91db80e05010<br /> R13: 000000000000000a R14: 0000000000000006 R15: 0000000000000040<br /> FS: 0000000000000000(0000) GS:ffff91db1f840000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: ffffffff8f220860 CR3: 00000001f9580004 CR4: 00000000003706e0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> _raw_spin_lock_irqsave+0x30/0x40<br /> mlx5_ib_poll_cq+0x4c/0xc50 [mlx5_ib]<br /> smc_wr_rx_tasklet_fn+0x56/0xa0 [smc]<br /> tasklet_action_common.isra.21+0x66/0x100<br /> __do_softirq+0xd5/0x29c<br /> asm_call_irq_on_stack+0x12/0x20<br /> <br /> do_softirq_own_stack+0x37/0x40<br /> irq_exit_rcu+0x9d/0xa0<br /> sysvec_call_function_single+0x34/0x80<br /> asm_sysvec_call_function_single+0x12/0x20

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> erofs: fix pcluster use-after-free on UP platforms<br /> <br /> During stress testing with CONFIG_SMP disabled, KASAN reports as below:<br /> <br /> ==================================================================<br /> BUG: KASAN: use-after-free in __mutex_lock+0xe5/0xc30<br /> Read of size 8 at addr ffff8881094223f8 by task stress/7789<br /> <br /> CPU: 0 PID: 7789 Comm: stress Not tainted 6.0.0-rc1-00002-g0d53d2e882f9 #3<br /> Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011<br /> Call Trace:<br /> <br /> ..<br /> __mutex_lock+0xe5/0xc30<br /> ..<br /> z_erofs_do_read_page+0x8ce/0x1560<br /> ..<br /> z_erofs_readahead+0x31c/0x580<br /> ..<br /> Freed by task 7787<br /> kasan_save_stack+0x1e/0x40<br /> kasan_set_track+0x20/0x30<br /> kasan_set_free_info+0x20/0x40<br /> __kasan_slab_free+0x10c/0x190<br /> kmem_cache_free+0xed/0x380<br /> rcu_core+0x3d5/0xc90<br /> __do_softirq+0x12d/0x389<br /> <br /> Last potentially related work creation:<br /> kasan_save_stack+0x1e/0x40<br /> __kasan_record_aux_stack+0x97/0xb0<br /> call_rcu+0x3d/0x3f0<br /> erofs_shrink_workstation+0x11f/0x210<br /> erofs_shrink_scan+0xdc/0x170<br /> shrink_slab.constprop.0+0x296/0x530<br /> drop_slab+0x1c/0x70<br /> drop_caches_sysctl_handler+0x70/0x80<br /> proc_sys_call_handler+0x20a/0x2f0<br /> vfs_write+0x555/0x6c0<br /> ksys_write+0xbe/0x160<br /> do_syscall_64+0x3b/0x90<br /> <br /> The root cause is that erofs_workgroup_unfreeze() doesn&amp;#39;t reset to<br /> orig_val thus it causes a race that the pcluster reuses unexpectedly<br /> before freeing.<br /> <br /> Since UP platforms are quite rare now, such path becomes unnecessary.<br /> Let&amp;#39;s drop such specific-designed path directly instead.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> IB/core: Fix a nested dead lock as part of ODP flow<br /> <br /> Fix a nested dead lock as part of ODP flow by using mmput_async().<br /> <br /> From the below call trace [1] can see that calling mmput() once we have<br /> the umem_odp-&gt;umem_mutex locked as required by<br /> ib_umem_odp_map_dma_and_lock() might trigger in the same task the<br /> exit_mmap()-&gt;__mmu_notifier_release()-&gt;mlx5_ib_invalidate_range() which<br /> may dead lock when trying to lock the same mutex.<br /> <br /> Moving to use mmput_async() will solve the problem as the above<br /> exit_mmap() flow will be called in other task and will be executed once<br /> the lock will be available.<br /> <br /> [1]<br /> [64843.077665] task:kworker/u133:2 state:D stack: 0 pid:80906 ppid:<br /> 2 flags:0x00004000<br /> [64843.077672] Workqueue: mlx5_ib_page_fault mlx5_ib_eqe_pf_action [mlx5_ib]<br /> [64843.077719] Call Trace:<br /> [64843.077722] <br /> [64843.077724] __schedule+0x23d/0x590<br /> [64843.077729] schedule+0x4e/0xb0<br /> [64843.077735] schedule_preempt_disabled+0xe/0x10<br /> [64843.077740] __mutex_lock.constprop.0+0x263/0x490<br /> [64843.077747] __mutex_lock_slowpath+0x13/0x20<br /> [64843.077752] mutex_lock+0x34/0x40<br /> [64843.077758] mlx5_ib_invalidate_range+0x48/0x270 [mlx5_ib]<br /> [64843.077808] __mmu_notifier_release+0x1a4/0x200<br /> [64843.077816] exit_mmap+0x1bc/0x200<br /> [64843.077822] ? walk_page_range+0x9c/0x120<br /> [64843.077828] ? __cond_resched+0x1a/0x50<br /> [64843.077833] ? mutex_lock+0x13/0x40<br /> [64843.077839] ? uprobe_clear_state+0xac/0x120<br /> [64843.077860] mmput+0x5f/0x140<br /> [64843.077867] ib_umem_odp_map_dma_and_lock+0x21b/0x580 [ib_core]<br /> [64843.077931] pagefault_real_mr+0x9a/0x140 [mlx5_ib]<br /> [64843.077962] pagefault_mr+0xb4/0x550 [mlx5_ib]<br /> [64843.077992] pagefault_single_data_segment.constprop.0+0x2ac/0x560<br /> [mlx5_ib]<br /> [64843.078022] mlx5_ib_eqe_pf_action+0x528/0x780 [mlx5_ib]<br /> [64843.078051] process_one_work+0x22b/0x3d0<br /> [64843.078059] worker_thread+0x53/0x410<br /> [64843.078065] ? process_one_work+0x3d0/0x3d0<br /> [64843.078073] kthread+0x12a/0x150<br /> [64843.078079] ? set_kthread_struct+0x50/0x50<br /> [64843.078085] ret_from_fork+0x22/0x30<br /> [64843.078093]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nvme-tcp: fix UAF when detecting digest errors<br /> <br /> We should also bail from the io_work loop when we set rd_enabled to true,<br /> so we don&amp;#39;t attempt to read data from the socket when the TCP stream is<br /> already out-of-sync or corrupted.