Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> page_pool: Fix PP_MAGIC_MASK to avoid crashing on some 32-bit arches<br /> <br /> Helge reported that the introduction of PP_MAGIC_MASK let to crashes on<br /> boot on his 32-bit parisc machine. The cause of this is the mask is set<br /> too wide, so the page_pool_page_is_pp() incurs false positives which<br /> crashes the machine.<br /> <br /> Just disabling the check in page_pool_is_pp() will lead to the page_pool<br /> code itself malfunctioning; so instead of doing this, this patch changes<br /> the define for PP_DMA_INDEX_BITS to avoid mistaking arbitrary kernel<br /> pointers for page_pool-tagged pages.<br /> <br /> The fix relies on the kernel pointers that alias with the pp_magic field<br /> always being above PAGE_OFFSET. With this assumption, we can use the<br /> lowest bit of the value of PAGE_OFFSET as the upper bound of the<br /> PP_DMA_INDEX_MASK, which should avoid the false positives.<br /> <br /> Because we cannot rely on PAGE_OFFSET always being a compile-time<br /> constant, nor on it always being &gt;0, we fall back to disabling the<br /> dma_index storage when there are not enough bits available. This leaves<br /> us in the situation we were in before the patch in the Fixes tag, but<br /> only on a subset of architecture configurations. This seems to be the<br /> best we can do until the transition to page types in complete for<br /> page_pool pages.<br /> <br /> v2:<br /> - Make sure there&amp;#39;s at least 8 bits available and that the PAGE_OFFSET<br /> bit calculation doesn&amp;#39;t wrap

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Squashfs: reject negative file sizes in squashfs_read_inode()<br /> <br /> Syskaller reports a "WARNING in ovl_copy_up_file" in overlayfs.<br /> <br /> This warning is ultimately caused because the underlying Squashfs file<br /> system returns a file with a negative file size.<br /> <br /> This commit checks for a negative file size and returns EINVAL.<br /> <br /> [phillip@squashfs.org.uk: only need to check 64 bit quantity]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> kernel/sys.c: fix the racy usage of task_lock(tsk-&gt;group_leader) in sys_prlimit64() paths<br /> <br /> The usage of task_lock(tsk-&gt;group_leader) in sys_prlimit64()-&gt;do_prlimit()<br /> path is very broken.<br /> <br /> sys_prlimit64() does get_task_struct(tsk) but this only protects task_struct<br /> itself. If tsk != current and tsk is not a leader, this process can exit/exec<br /> and task_lock(tsk-&gt;group_leader) may use the already freed task_struct.<br /> <br /> Another problem is that sys_prlimit64() can race with mt-exec which changes<br /> -&gt;group_leader. In this case do_prlimit() may take the wrong lock, or (worse)<br /> -&gt;group_leader may change between task_lock() and task_unlock().<br /> <br /> Change sys_prlimit64() to take tasklist_lock when necessary. This is not<br /> nice, but I don&amp;#39;t see a better fix for -stable.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipmi: Rework user message limit handling<br /> <br /> The limit on the number of user messages had a number of issues,<br /> improper counting in some cases and a use after free.<br /> <br /> Restructure how this is all done to handle more in the receive message<br /> allocation routine, so all refcouting and user message limit counts<br /> are done in that routine. It&amp;#39;s a lot cleaner and safer.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> listmount: don&amp;#39;t call path_put() under namespace semaphore<br /> <br /> Massage listmount() and make sure we don&amp;#39;t call path_put() under the<br /> namespace semaphore. If we put the last reference we&amp;#39;re fscked.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sctp: Fix MAC comparison to be constant-time<br /> <br /> To prevent timing attacks, MACs need to be compared in constant time.<br /> Use the appropriate helper function for this.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: avoid potential out-of-bounds in btrfs_encode_fh()<br /> <br /> The function btrfs_encode_fh() does not properly account for the three<br /> cases it handles.<br /> <br /> Before writing to the file handle (fh), the function only returns to the<br /> user BTRFS_FID_SIZE_NON_CONNECTABLE (5 dwords, 20 bytes) or<br /> BTRFS_FID_SIZE_CONNECTABLE (8 dwords, 32 bytes).<br /> <br /> However, when a parent exists and the root ID of the parent and the<br /> inode are different, the function writes BTRFS_FID_SIZE_CONNECTABLE_ROOT<br /> (10 dwords, 40 bytes).<br /> <br /> If *max_len is not large enough, this write goes out of bounds because<br /> BTRFS_FID_SIZE_CONNECTABLE_ROOT is greater than<br /> BTRFS_FID_SIZE_CONNECTABLE originally returned.<br /> <br /> This results in an 8-byte out-of-bounds write at<br /> fid-&gt;parent_root_objectid = parent_root_id.<br /> <br /> A previous attempt to fix this issue was made but was lost.<br /> <br /> https://lore.kernel.org/all/4CADAEEC020000780001B32C@vpn.id2.novell.com/<br /> <br /> Although this issue does not seem to be easily triggerable, it is a<br /> potential memory corruption bug that should be fixed. This patch<br /> resolves the issue by ensuring the function returns the appropriate size<br /> for all three cases and validates that *max_len is large enough before<br /> writing any data.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nft_objref: validate objref and objrefmap expressions<br /> <br /> Referencing a synproxy stateful object from OUTPUT hook causes kernel<br /> crash due to infinite recursive calls:<br /> <br /> BUG: TASK stack guard page was hit at 000000008bda5b8c (stack is 000000003ab1c4a5..00000000494d8b12)<br /> [...]<br /> Call Trace:<br /> __find_rr_leaf+0x99/0x230<br /> fib6_table_lookup+0x13b/0x2d0<br /> ip6_pol_route+0xa4/0x400<br /> fib6_rule_lookup+0x156/0x240<br /> ip6_route_output_flags+0xc6/0x150<br /> __nf_ip6_route+0x23/0x50<br /> synproxy_send_tcp_ipv6+0x106/0x200<br /> synproxy_send_client_synack_ipv6+0x1aa/0x1f0<br /> nft_synproxy_do_eval+0x263/0x310<br /> nft_do_chain+0x5a8/0x5f0 [nf_tables<br /> nft_do_chain_inet+0x98/0x110<br /> nf_hook_slow+0x43/0xc0<br /> __ip6_local_out+0xf0/0x170<br /> ip6_local_out+0x17/0x70<br /> synproxy_send_tcp_ipv6+0x1a2/0x200<br /> synproxy_send_client_synack_ipv6+0x1aa/0x1f0<br /> [...]<br /> <br /> Implement objref and objrefmap expression validate functions.<br /> <br /> Currently, only NFT_OBJECT_SYNPROXY object type requires validation.<br /> This will also handle a jump to a chain using a synproxy object from the<br /> OUTPUT hook.<br /> <br /> Now when trying to reference a synproxy object in the OUTPUT hook, nft<br /> will produce the following error:<br /> <br /> synproxy_crash.nft: Error: Could not process rule: Operation not supported<br /> synproxy name mysynproxy<br /> ^^^^^^^^^^^^^^^^^^^^^^^^

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdkfd: Fix kfd process ref leaking when userptr unmapping<br /> <br /> kfd_lookup_process_by_pid hold the kfd process reference to ensure it<br /> doesn&amp;#39;t get destroyed while sending the segfault event to user space.<br /> <br /> Calling kfd_lookup_process_by_pid as function parameter leaks the kfd<br /> process refcount and miss the NULL pointer check if app process is<br /> already destroyed.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Revert "ipmi: fix msg stack when IPMI is disconnected"<br /> <br /> This reverts commit c608966f3f9c2dca596967501d00753282b395fc.<br /> <br /> This patch has a subtle bug that can cause the IPMI driver to go into an<br /> infinite loop if the BMC misbehaves in a certain way. Apparently<br /> certain BMCs do misbehave this way because several reports have come in<br /> recently about this.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xtensa: simdisk: add input size check in proc_write_simdisk<br /> <br /> A malicious user could pass an arbitrarily bad value<br /> to memdup_user_nul(), potentially causing kernel crash.<br /> <br /> This follows the same pattern as commit ee76746387f6<br /> ("netdevsim: prevent bad user input in nsim_dev_health_break_write()")

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cpufreq: intel_pstate: Fix object lifecycle issue in update_qos_request()<br /> <br /> The cpufreq_cpu_put() call in update_qos_request() takes place too early<br /> because the latter subsequently calls freq_qos_update_request() that<br /> indirectly accesses the policy object in question through the QoS request<br /> object passed to it.<br /> <br /> Fortunately, update_qos_request() is called under intel_pstate_driver_lock,<br /> so this issue does not matter for changing the intel_pstate operation<br /> mode, but it theoretically can cause a crash to occur on CPU device hot<br /> removal (which currently can only happen in virt, but it is formally<br /> supported nevertheless).<br /> <br /> Address this issue by modifying update_qos_request() to drop the<br /> reference to the policy later.