Vulnerabilities

Tuleap is an Open Source Suite to improve management of software developments and collaboration. Tuleap Community Edition prior to version 16.13.99.1762267347 and Tuleap Enterprise Edition prior to versions 17.01-, 16.13-6, and 16.12-9 don't have cross-site request forgery protections in the file release system. An attacker could use this vulnerability to trick victims into changing the commit rules or immutable tags of a SVN repo. Tuleap Community Edition 16.13.99.1762267347, Tuleap Enterprise Edition 17.0-1, Tuleap Enterprise Edition 16.13-6, and Tuleap Enterprise Edition 16.12-9 fix the issue.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: v4l2-subdev: Fix alloc failure check in v4l2_subdev_call_state_try()<br /> <br /> v4l2_subdev_call_state_try() macro allocates a subdev state with<br /> __v4l2_subdev_state_alloc(), but does not check the returned value. If<br /> __v4l2_subdev_state_alloc fails, it returns an ERR_PTR, and that would<br /> cause v4l2_subdev_call_state_try() to crash.<br /> <br /> Add proper error handling to v4l2_subdev_call_state_try().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: iris: fix module removal if firmware download failed<br /> <br /> Fix remove if firmware failed to load:<br /> qcom-iris aa00000.video-codec: Direct firmware load for qcom/vpu/vpu33_p4.mbn failed with error -2<br /> qcom-iris aa00000.video-codec: firmware download failed<br /> qcom-iris aa00000.video-codec: core init failed<br /> <br /> then:<br /> $ echo aa00000.video-codec &gt; /sys/bus/platform/drivers/qcom-iris/unbind<br /> <br /> Triggers:<br /> genpd genpd:1:aa00000.video-codec: Runtime PM usage count underflow!<br /> ------------[ cut here ]------------<br /> video_cc_mvs0_clk already disabled<br /> WARNING: drivers/clk/clk.c:1206 at clk_core_disable+0xa4/0xac, CPU#1: sh/542<br /> <br /> pc : clk_core_disable+0xa4/0xac<br /> lr : clk_core_disable+0xa4/0xac<br /> <br /> Call trace:<br /> clk_core_disable+0xa4/0xac (P)<br /> clk_disable+0x30/0x4c<br /> iris_disable_unprepare_clock+0x20/0x48 [qcom_iris]<br /> iris_vpu_power_off_hw+0x48/0x58 [qcom_iris]<br /> iris_vpu33_power_off_hardware+0x44/0x230 [qcom_iris]<br /> iris_vpu_power_off+0x34/0x84 [qcom_iris]<br /> iris_core_deinit+0x44/0xc8 [qcom_iris]<br /> iris_remove+0x20/0x48 [qcom_iris]<br /> platform_remove+0x20/0x30<br /> device_remove+0x4c/0x80<br /> <br /> ---[ end trace 0000000000000000 ]---<br /> ------------[ cut here ]------------<br /> video_cc_mvs0_clk already unprepared<br /> WARNING: drivers/clk/clk.c:1065 at clk_core_unprepare+0xf0/0x110, CPU#2: sh/542<br /> <br /> pc : clk_core_unprepare+0xf0/0x110<br /> lr : clk_core_unprepare+0xf0/0x110<br /> <br /> Call trace:<br /> clk_core_unprepare+0xf0/0x110 (P)<br /> clk_unprepare+0x2c/0x44<br /> iris_disable_unprepare_clock+0x28/0x48 [qcom_iris]<br /> iris_vpu_power_off_hw+0x48/0x58 [qcom_iris]<br /> iris_vpu33_power_off_hardware+0x44/0x230 [qcom_iris]<br /> iris_vpu_power_off+0x34/0x84 [qcom_iris]<br /> iris_core_deinit+0x44/0xc8 [qcom_iris]<br /> iris_remove+0x20/0x48 [qcom_iris]<br /> platform_remove+0x20/0x30<br /> device_remove+0x4c/0x80<br /> <br /> ---[ end trace 0000000000000000 ]---<br /> genpd genpd:0:aa00000.video-codec: Runtime PM usage count underflow!<br /> ------------[ cut here ]------------<br /> gcc_video_axi0_clk already disabled<br /> WARNING: drivers/clk/clk.c:1206 at clk_core_disable+0xa4/0xac, CPU#4: sh/542<br /> <br /> pc : clk_core_disable+0xa4/0xac<br /> lr : clk_core_disable+0xa4/0xac<br /> <br /> Call trace:<br /> clk_core_disable+0xa4/0xac (P)<br /> clk_disable+0x30/0x4c<br /> iris_disable_unprepare_clock+0x20/0x48 [qcom_iris]<br /> iris_vpu33_power_off_controller+0x17c/0x428 [qcom_iris]<br /> iris_vpu_power_off+0x48/0x84 [qcom_iris]<br /> iris_core_deinit+0x44/0xc8 [qcom_iris]<br /> iris_remove+0x20/0x48 [qcom_iris]<br /> platform_remove+0x20/0x30<br /> device_remove+0x4c/0x80<br /> <br /> ------------[ cut here ]------------<br /> gcc_video_axi0_clk already unprepared<br /> WARNING: drivers/clk/clk.c:1065 at clk_core_unprepare+0xf0/0x110, CPU#4: sh/542<br /> <br /> pc : clk_core_unprepare+0xf0/0x110<br /> lr : clk_core_unprepare+0xf0/0x110<br /> <br /> Call trace:<br /> clk_core_unprepare+0xf0/0x110 (P)<br /> clk_unprepare+0x2c/0x44<br /> iris_disable_unprepare_clock+0x28/0x48 [qcom_iris]<br /> iris_vpu33_power_off_controller+0x17c/0x428 [qcom_iris]<br /> iris_vpu_power_off+0x48/0x84 [qcom_iris]<br /> iris_core_deinit+0x44/0xc8 [qcom_iris]<br /> iris_remove+0x20/0x48 [qcom_iris]<br /> platform_remove+0x20/0x30<br /> device_remove+0x4c/0x80<br /> <br /> ---[ end trace 0000000000000000 ]---<br /> <br /> Skip deinit if initialization never succeeded.

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.