Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> spi: don&amp;#39;t unoptimize message in spi_async()<br /> <br /> Calling spi_maybe_unoptimize_message() in spi_async() is wrong because<br /> the message is likely to be in the queue and not transferred yet. This<br /> can corrupt the message while it is being used by the controller driver.<br /> <br /> spi_maybe_unoptimize_message() is already called in the correct place<br /> in spi_finalize_current_message() to balance the call to<br /> spi_maybe_optimize_message() in spi_async().

A vulnerability classified as critical was found in Tenda i22 1.0.0.3(4687). This vulnerability affects the function formApPortalAccessCodeAuth of the file /goform/apPortalAccessCodeAuth. The manipulation of the argument accessCode/data/acceInfo leads to buffer overflow. The attack can be initiated remotely. The exploit has been disclosed to the public and may be used. NOTE: The vendor was contacted early about this disclosure but did not respond in any way.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> USB: serial: mos7840: fix crash on resume<br /> <br /> Since commit c49cfa917025 ("USB: serial: use generic method if no<br /> alternative is provided in usb serial layer"), USB serial core calls the<br /> generic resume implementation when the driver has not provided one.<br /> <br /> This can trigger a crash on resume with mos7840 since support for<br /> multiple read URBs was added back in 2011. Specifically, both port read<br /> URBs are now submitted on resume for open ports, but the context pointer<br /> of the second URB is left set to the core rather than mos7840 port<br /> structure.<br /> <br /> Fix this by implementing dedicated suspend and resume functions for<br /> mos7840.<br /> <br /> Tested with Delock 87414 USB 2.0 to 4x serial adapter.<br /> <br /> [ johan: analyse crash and rewrite commit message; set busy flag on<br /> resume; drop bulk-in check; drop unnecessary usb_kill_urb() ]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Revert "sched/fair: Make sure to try to detach at least one movable task"<br /> <br /> This reverts commit b0defa7ae03ecf91b8bfd10ede430cff12fcbd06.<br /> <br /> b0defa7ae03ec changed the load balancing logic to ignore env.max_loop if<br /> all tasks examined to that point were pinned. The goal of the patch was<br /> to make it more likely to be able to detach a task buried in a long list<br /> of pinned tasks. However, this has the unfortunate side effect of<br /> creating an O(n) iteration in detach_tasks(), as we now must fully<br /> iterate every task on a cpu if all or most are pinned. Since this load<br /> balance code is done with rq lock held, and often in softirq context, it<br /> is very easy to trigger hard lockups. We observed such hard lockups with<br /> a user who affined O(10k) threads to a single cpu.<br /> <br /> When I discussed this with Vincent he initially suggested that we keep<br /> the limit on the number of tasks to detach, but increase the number of<br /> tasks we can search. However, after some back and forth on the mailing<br /> list, he recommended we instead revert the original patch, as it seems<br /> likely no one was actually getting hit by the original issue.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net, sunrpc: Remap EPERM in case of connection failure in xs_tcp_setup_socket<br /> <br /> When using a BPF program on kernel_connect(), the call can return -EPERM. This<br /> causes xs_tcp_setup_socket() to loop forever, filling up the syslog and causing<br /> the kernel to potentially freeze up.<br /> <br /> Neil suggested:<br /> <br /> This will propagate -EPERM up into other layers which might not be ready<br /> to handle it. It might be safer to map EPERM to an error we would be more<br /> likely to expect from the network system - such as ECONNREFUSED or ENETDOWN.<br /> <br /> ECONNREFUSED as error seems reasonable. For programs setting a different error<br /> can be out of reach (see handling in 4fbac77d2d09) in particular on kernels<br /> which do not have f10d05966196 ("bpf: Make BPF_PROG_RUN_ARRAY return -err<br /> instead of allow boolean"), thus given that it is better to simply remap for<br /> consistent behavior. UDP does handle EPERM in xs_udp_send_request().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wireguard: allowedips: avoid unaligned 64-bit memory accesses<br /> <br /> On the parisc platform, the kernel issues kernel warnings because<br /> swap_endian() tries to load a 128-bit IPv6 address from an unaligned<br /> memory location:<br /> <br /> Kernel: unaligned access to 0x55f4688c in wg_allowedips_insert_v6+0x2c/0x80 [wireguard] (iir 0xf3010df)<br /> Kernel: unaligned access to 0x55f46884 in wg_allowedips_insert_v6+0x38/0x80 [wireguard] (iir 0xf2010dc)<br /> <br /> Avoid such unaligned memory accesses by instead using the<br /> get_unaligned_be64() helper macro.<br /> <br /> [Jason: replace src[8] in original patch with src+8]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cachefiles: add missing lock protection when polling<br /> <br /> Add missing lock protection in poll routine when iterating xarray,<br /> otherwise:<br /> <br /> Even with RCU read lock held, only the slot of the radix tree is<br /> ensured to be pinned there, while the data structure (e.g. struct<br /> cachefiles_req) stored in the slot has no such guarantee. The poll<br /> routine will iterate the radix tree and dereference cachefiles_req<br /> accordingly. Thus RCU read lock is not adequate in this case and<br /> spinlock is needed here.

An issue in the Hardware info module of IT Solutions Enjay CRM OS v1.0 allows attackers to escape the restricted terminal environment and gain root-level privileges on the underlying system.

An IP Spoofing vulnerability has been discovered in Likeshop up to 2.5.7.20210811. This issue allows an attacker to replace their real IP address with any arbitrary IP address, specifically by adding a forged &amp;#39;X-Forwarded&amp;#39; or &amp;#39;Client-IP&amp;#39; header to requests. Exploiting IP spoofing, attackers can bypass account lockout mechanisms during attempts to log into admin accounts, spoof IP addresses in requests sent to the server, and impersonate IP addresses that have logged into user accounts, etc.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> filemap: replace pte_offset_map() with pte_offset_map_nolock()<br /> <br /> The vmf-&gt;ptl in filemap_fault_recheck_pte_none() is still set from<br /> handle_pte_fault(). But at the same time, we did a pte_unmap(vmf-&gt;pte). <br /> After a pte_unmap(vmf-&gt;pte) unmap and rcu_read_unlock(), the page table<br /> may be racily changed and vmf-&gt;ptl maybe fails to protect the actual page<br /> table. Fix this by replacing pte_offset_map() with<br /> pte_offset_map_nolock().<br /> <br /> As David said, the PTL pointer might be stale so if we continue to use<br /> it infilemap_fault_recheck_pte_none(), it might trigger UAF. Also, if<br /> the PTL fails, the issue fixed by commit 58f327f2ce80 ("filemap: avoid<br /> unnecessary major faults in filemap_fault()") might reappear.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm: fix crashes from deferred split racing folio migration<br /> <br /> Even on 6.10-rc6, I&amp;#39;ve been seeing elusive "Bad page state"s (often on<br /> flags when freeing, yet the flags shown are not bad: PG_locked had been<br /> set and cleared??), and VM_BUG_ON_PAGE(page_ref_count(page) == 0)s from<br /> deferred_split_scan()&amp;#39;s folio_put(), and a variety of other BUG and WARN<br /> symptoms implying double free by deferred split and large folio migration.<br /> <br /> 6.7 commit 9bcef5973e31 ("mm: memcg: fix split queue list crash when large<br /> folio migration") was right to fix the memcg-dependent locking broken in<br /> 85ce2c517ade ("memcontrol: only transfer the memcg data for migration"),<br /> but missed a subtlety of deferred_split_scan(): it moves folios to its own<br /> local list to work on them without split_queue_lock, during which time<br /> folio-&gt;_deferred_list is not empty, but even the "right" lock does nothing<br /> to secure the folio and the list it is on.<br /> <br /> Fortunately, deferred_split_scan() is careful to use folio_try_get(): so<br /> folio_migrate_mapping() can avoid the race by folio_undo_large_rmappable()<br /> while the old folio&amp;#39;s reference count is temporarily frozen to 0 - adding<br /> such a freeze in the !mapping case too (originally, folio lock and<br /> unmapping and no swap cache left an anon folio unreachable, so no freezing<br /> was needed there: but the deferred split queue offers a way to reach it).

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> s390/mm: Add NULL pointer check to crst_table_free() base_crst_free()<br /> <br /> crst_table_free() used to work with NULL pointers before the conversion<br /> to ptdescs. Since crst_table_free() can be called with a NULL pointer<br /> (error handling in crst_table_upgrade() add an explicit check.<br /> <br /> Also add the same check to base_crst_free() for consistency reasons.<br /> <br /> In real life this should not happen, since order two GFP_KERNEL<br /> allocations will not fail, unless FAIL_PAGE_ALLOC is enabled and used.