Vulnerabilities

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.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mount: handle NULL values in mnt_ns_release()<br /> <br /> When calling in listmount() mnt_ns_release() may be passed a NULL<br /> pointer. Handle that case gracefully.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs: quota: create dedicated workqueue for quota_release_work<br /> <br /> There is a kernel panic due to WARN_ONCE when panic_on_warn is set.<br /> <br /> This issue occurs when writeback is triggered due to sync call for an<br /> opened file(ie, writeback reason is WB_REASON_SYNC). When f2fs balance<br /> is needed at sync path, flush for quota_release_work is triggered.<br /> By default quota_release_work is queued to "events_unbound" queue which<br /> does not have WQ_MEM_RECLAIM flag. During f2fs balance "writeback"<br /> workqueue tries to flush quota_release_work causing kernel panic due to<br /> MEM_RECLAIM flag mismatch errors.<br /> <br /> This patch creates dedicated workqueue with WQ_MEM_RECLAIM flag<br /> for work quota_release_work.<br /> <br /> ------------[ cut here ]------------<br /> WARNING: CPU: 4 PID: 14867 at kernel/workqueue.c:3721 check_flush_dependency+0x13c/0x148<br /> Call trace:<br /> check_flush_dependency+0x13c/0x148<br /> __flush_work+0xd0/0x398<br /> flush_delayed_work+0x44/0x5c<br /> dquot_writeback_dquots+0x54/0x318<br /> f2fs_do_quota_sync+0xb8/0x1a8<br /> f2fs_write_checkpoint+0x3cc/0x99c<br /> f2fs_gc+0x190/0x750<br /> f2fs_balance_fs+0x110/0x168<br /> f2fs_write_single_data_page+0x474/0x7dc<br /> f2fs_write_data_pages+0x7d0/0xd0c<br /> do_writepages+0xe0/0x2f4<br /> __writeback_single_inode+0x44/0x4ac<br /> writeback_sb_inodes+0x30c/0x538<br /> wb_writeback+0xf4/0x440<br /> wb_workfn+0x128/0x5d4<br /> process_scheduled_works+0x1c4/0x45c<br /> worker_thread+0x32c/0x3e8<br /> kthread+0x11c/0x1b0<br /> ret_from_fork+0x10/0x20<br /> Kernel panic - not syncing: kernel: panic_on_warn set ...