Vulnerabilities

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.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Fix MST Null Ptr for RV<br /> <br /> The change try to fix below error specific to RV platform:<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000008<br /> PGD 0 P4D 0<br /> Oops: 0000 [#1] PREEMPT SMP NOPTI<br /> CPU: 4 PID: 917 Comm: sway Not tainted 6.3.9-arch1-1 #1 124dc55df4f5272ccb409f39ef4872fc2b3376a2<br /> Hardware name: LENOVO 20NKS01Y00/20NKS01Y00, BIOS R12ET61W(1.31 ) 07/28/2022<br /> RIP: 0010:drm_dp_atomic_find_time_slots+0x5e/0x260 [drm_display_helper]<br /> Code: 01 00 00 48 8b 85 60 05 00 00 48 63 80 88 00 00 00 3b 43 28 0f 8d 2e 01 00 00 48 8b 53 30 48 8d 04 80 48 8d 04 c2 48 8b 40 18 8&gt;<br /> RSP: 0018:ffff960cc2df77d8 EFLAGS: 00010293<br /> RAX: 0000000000000000 RBX: ffff8afb87e81280 RCX: 0000000000000224<br /> RDX: ffff8afb9ee37c00 RSI: ffff8afb8da1a578 RDI: ffff8afb87e81280<br /> RBP: ffff8afb83d67000 R08: 0000000000000001 R09: ffff8afb9652f850<br /> R10: ffff960cc2df7908 R11: 0000000000000002 R12: 0000000000000000<br /> R13: ffff8afb8d7688a0 R14: ffff8afb8da1a578 R15: 0000000000000224<br /> FS: 00007f4dac35ce00(0000) GS:ffff8afe30b00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000000000000008 CR3: 000000010ddc6000 CR4: 00000000003506e0<br /> Call Trace:<br /> <br /> ? __die+0x23/0x70<br /> ? page_fault_oops+0x171/0x4e0<br /> ? plist_add+0xbe/0x100<br /> ? exc_page_fault+0x7c/0x180<br /> ? asm_exc_page_fault+0x26/0x30<br /> ? drm_dp_atomic_find_time_slots+0x5e/0x260 [drm_display_helper 0e67723696438d8e02b741593dd50d80b44c2026]<br /> ? drm_dp_atomic_find_time_slots+0x28/0x260 [drm_display_helper 0e67723696438d8e02b741593dd50d80b44c2026]<br /> compute_mst_dsc_configs_for_link+0x2ff/0xa40 [amdgpu 62e600d2a75e9158e1cd0a243bdc8e6da040c054]<br /> ? fill_plane_buffer_attributes+0x419/0x510 [amdgpu 62e600d2a75e9158e1cd0a243bdc8e6da040c054]<br /> compute_mst_dsc_configs_for_state+0x1e1/0x250 [amdgpu 62e600d2a75e9158e1cd0a243bdc8e6da040c054]<br /> amdgpu_dm_atomic_check+0xecd/0x1190 [amdgpu 62e600d2a75e9158e1cd0a243bdc8e6da040c054]<br /> drm_atomic_check_only+0x5c5/0xa40<br /> drm_mode_atomic_ioctl+0x76e/0xbc0<br /> ? _copy_to_user+0x25/0x30<br /> ? drm_ioctl+0x296/0x4b0<br /> ? __pfx_drm_mode_atomic_ioctl+0x10/0x10<br /> drm_ioctl_kernel+0xcd/0x170<br /> drm_ioctl+0x26d/0x4b0<br /> ? __pfx_drm_mode_atomic_ioctl+0x10/0x10<br /> amdgpu_drm_ioctl+0x4e/0x90 [amdgpu 62e600d2a75e9158e1cd0a243bdc8e6da040c054]<br /> __x64_sys_ioctl+0x94/0xd0<br /> do_syscall_64+0x60/0x90<br /> ? do_syscall_64+0x6c/0x90<br /> entry_SYSCALL_64_after_hwframe+0x72/0xdc<br /> RIP: 0033:0x7f4dad17f76f<br /> Code: 00 48 89 44 24 18 31 c0 48 8d 44 24 60 c7 04 24 10 00 00 00 48 89 44 24 08 48 8d 44 24 20 48 89 44 24 10 b8 10 00 00 00 0f 05 c&gt;<br /> RSP: 002b:00007ffd9ae859f0 EFLAGS: 00000246 ORIG_RAX: 0000000000000010<br /> RAX: ffffffffffffffda RBX: 000055e255a55900 RCX: 00007f4dad17f76f<br /> RDX: 00007ffd9ae85a90 RSI: 00000000c03864bc RDI: 000000000000000b<br /> RBP: 00007ffd9ae85a90 R08: 0000000000000003 R09: 0000000000000003<br /> R10: 0000000000000000 R11: 0000000000000246 R12: 00000000c03864bc<br /> R13: 000000000000000b R14: 000055e255a7fc60 R15: 000055e255a01eb0<br /> <br /> Modules linked in: rfcomm snd_seq_dummy snd_hrtimer snd_seq snd_seq_device ccm cmac algif_hash algif_skcipher af_alg joydev mousedev bnep &gt;<br /> typec libphy k10temp ipmi_msghandler roles i2c_scmi acpi_cpufreq mac_hid nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_mas&gt;<br /> CR2: 0000000000000008<br /> ---[ end trace 0000000000000000 ]---<br /> RIP: 0010:drm_dp_atomic_find_time_slots+0x5e/0x260 [drm_display_helper]<br /> Code: 01 00 00 48 8b 85 60 05 00 00 48 63 80 88 00 00 00 3b 43 28 0f 8d 2e 01 00 00 48 8b 53 30 48 8d 04 80 48 8d 04 c2 48 8b 40 18 8&gt;<br /> RSP: 0018:ffff960cc2df77d8 EFLAGS: 00010293<br /> RAX: 0000000000000000 RBX: ffff8afb87e81280 RCX: 0000000000000224<br /> RDX: ffff8afb9ee37c00 RSI: ffff8afb8da1a578 RDI: ffff8afb87e81280<br /> RBP: ffff8afb83d67000 R08: 0000000000000001 R09: ffff8afb9652f850<br /> R10: ffff960cc2df7908 R11: 0000000000000002 R12: 0000000000000000<br /> R13: ffff8afb8d7688a0 R14: ffff8afb8da1a578 R15: 0000000000000224<br /> FS: 00007f4dac35ce00(0000) GS:ffff8afe30b00000(0000<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iio: magnetometer: rm3100: add boundary check for the value read from RM3100_REG_TMRC<br /> <br /> Recently, we encounter kernel crash in function rm3100_common_probe<br /> caused by out of bound access of array rm3100_samp_rates (because of<br /> underlying hardware failures). Add boundary check to prevent out of<br /> bound access.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tracing/timerlat: Move hrtimer_init to timerlat_fd open()<br /> <br /> Currently, the timerlat&amp;#39;s hrtimer is initialized at the first read of<br /> timerlat_fd, and destroyed at close(). It works, but it causes an error<br /> if the user program open() and close() the file without reading.<br /> <br /> Here&amp;#39;s an example:<br /> <br /> # echo NO_OSNOISE_WORKLOAD &gt; /sys/kernel/debug/tracing/osnoise/options<br /> # echo timerlat &gt; /sys/kernel/debug/tracing/current_tracer<br /> <br /> # cat

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> parisc: BTLB: Fix crash when setting up BTLB at CPU bringup<br /> <br /> When using hotplug and bringing up a 32-bit CPU, ask the firmware about the<br /> BTLB information to set up the static (block) TLB entries.<br /> <br /> For that write access to the static btlb_info struct is needed, but<br /> since it is marked __ro_after_init the kernel segfaults with missing<br /> write permissions.<br /> <br /> Fix the crash by dropping the __ro_after_init annotation.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: hsr: remove WARN_ONCE() in send_hsr_supervision_frame()<br /> <br /> Syzkaller reported [1] hitting a warning after failing to allocate<br /> resources for skb in hsr_init_skb(). Since a WARN_ONCE() call will<br /> not help much in this case, it might be prudent to switch to<br /> netdev_warn_once(). At the very least it will suppress syzkaller<br /> reports such as [1].<br /> <br /> Just in case, use netdev_warn_once() in send_prp_supervision_frame()<br /> for similar reasons.<br /> <br /> [1]<br /> HSR: Could not send supervision frame<br /> WARNING: CPU: 1 PID: 85 at net/hsr/hsr_device.c:294 send_hsr_supervision_frame+0x60a/0x810 net/hsr/hsr_device.c:294<br /> RIP: 0010:send_hsr_supervision_frame+0x60a/0x810 net/hsr/hsr_device.c:294<br /> ...<br /> Call Trace:<br /> <br /> hsr_announce+0x114/0x370 net/hsr/hsr_device.c:382<br /> call_timer_fn+0x193/0x590 kernel/time/timer.c:1700<br /> expire_timers kernel/time/timer.c:1751 [inline]<br /> __run_timers+0x764/0xb20 kernel/time/timer.c:2022<br /> run_timer_softirq+0x58/0xd0 kernel/time/timer.c:2035<br /> __do_softirq+0x21a/0x8de kernel/softirq.c:553<br /> invoke_softirq kernel/softirq.c:427 [inline]<br /> __irq_exit_rcu kernel/softirq.c:632 [inline]<br /> irq_exit_rcu+0xb7/0x120 kernel/softirq.c:644<br /> sysvec_apic_timer_interrupt+0x95/0xb0 arch/x86/kernel/apic/apic.c:1076<br /> <br /> <br /> asm_sysvec_apic_timer_interrupt+0x1a/0x20 arch/x86/include/asm/idtentry.h:649<br /> ...<br /> <br /> This issue is also found in older kernels (at least up to 5.10).

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mptcp: really cope with fastopen race<br /> <br /> Fastopen and PM-trigger subflow shutdown can race, as reported by<br /> syzkaller.<br /> <br /> In my first attempt to close such race, I missed the fact that<br /> the subflow status can change again before the subflow_state_change<br /> callback is invoked.<br /> <br /> Address the issue additionally copying with all the states directly<br /> reachable from TCP_FIN_WAIT1.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> powerpc/iommu: Fix the missing iommu_group_put() during platform domain attach<br /> <br /> The function spapr_tce_platform_iommu_attach_dev() is missing to call<br /> iommu_group_put() when the domain is already set. This refcount leak<br /> shows up with BUG_ON() during DLPAR remove operation as:<br /> <br /> KernelBug: Kernel bug in state &amp;#39;None&amp;#39;: kernel BUG at arch/powerpc/platforms/pseries/iommu.c:100!<br /> Oops: Exception in kernel mode, sig: 5 [#1]<br /> LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=8192 NUMA pSeries<br /> <br /> Hardware name: IBM,9080-HEX POWER10 (raw) 0x800200 0xf000006 of:IBM,FW1060.00 (NH1060_016) hv:phyp pSeries<br /> NIP: c0000000000ff4d4 LR: c0000000000ff4cc CTR: 0000000000000000<br /> REGS: c0000013aed5f840 TRAP: 0700 Tainted: G I (6.8.0-rc3-autotest-g99bd3cb0d12e)<br /> MSR: 8000000000029033 CR: 44002402 XER: 20040000<br /> CFAR: c000000000a0d170 IRQMASK: 0<br /> ...<br /> NIP iommu_reconfig_notifier+0x94/0x200<br /> LR iommu_reconfig_notifier+0x8c/0x200<br /> Call Trace:<br /> iommu_reconfig_notifier+0x8c/0x200 (unreliable)<br /> notifier_call_chain+0xb8/0x19c<br /> blocking_notifier_call_chain+0x64/0x98<br /> of_reconfig_notify+0x44/0xdc<br /> of_detach_node+0x78/0xb0<br /> ofdt_write.part.0+0x86c/0xbb8<br /> proc_reg_write+0xf4/0x150<br /> vfs_write+0xf8/0x488<br /> ksys_write+0x84/0x140<br /> system_call_exception+0x138/0x330<br /> system_call_vectored_common+0x15c/0x2ec<br /> <br /> The patch adds the missing iommu_group_put() call.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> powerpc/kasan: Limit KASAN thread size increase to 32KB<br /> <br /> KASAN is seen to increase stack usage, to the point that it was reported<br /> to lead to stack overflow on some 32-bit machines (see link).<br /> <br /> To avoid overflows the stack size was doubled for KASAN builds in<br /> commit 3e8635fb2e07 ("powerpc/kasan: Force thread size increase with<br /> KASAN").<br /> <br /> However with a 32KB stack size to begin with, the doubling leads to a<br /> 64KB stack, which causes build errors:<br /> arch/powerpc/kernel/switch.S:249: Error: operand out of range (0x000000000000fe50 is not between 0xffffffffffff8000 and 0x0000000000007fff)<br /> <br /> Although the asm could be reworked, in practice a 32KB stack seems<br /> sufficient even for KASAN builds - the additional usage seems to be in<br /> the 2-3KB range for a 64-bit KASAN build.<br /> <br /> So only increase the stack for KASAN if the stack size is