Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tunnels: fix out of bounds access when building IPv6 PMTU error<br /> <br /> If the ICMPv6 error is built from a non-linear skb we get the following<br /> splat,<br /> <br /> BUG: KASAN: slab-out-of-bounds in do_csum+0x220/0x240<br /> Read of size 4 at addr ffff88811d402c80 by task netperf/820<br /> CPU: 0 PID: 820 Comm: netperf Not tainted 6.8.0-rc1+ #543<br /> ...<br /> kasan_report+0xd8/0x110<br /> do_csum+0x220/0x240<br /> csum_partial+0xc/0x20<br /> skb_tunnel_check_pmtu+0xeb9/0x3280<br /> vxlan_xmit_one+0x14c2/0x4080<br /> vxlan_xmit+0xf61/0x5c00<br /> dev_hard_start_xmit+0xfb/0x510<br /> __dev_queue_xmit+0x7cd/0x32a0<br /> br_dev_queue_push_xmit+0x39d/0x6a0<br /> <br /> Use skb_checksum instead of csum_partial who cannot deal with non-linear<br /> SKBs.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mac80211: fix RCU use in TDLS fast-xmit<br /> <br /> This looks up the link under RCU protection, but isn&amp;#39;t<br /> guaranteed to actually have protection. Fix that.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/msm/dpu: check for valid hw_pp in dpu_encoder_helper_phys_cleanup<br /> <br /> The commit 8b45a26f2ba9 ("drm/msm/dpu: reserve cdm blocks for writeback<br /> in case of YUV output") introduced a smatch warning about another<br /> conditional block in dpu_encoder_helper_phys_cleanup() which had assumed<br /> hw_pp will always be valid which may not necessarily be true.<br /> <br /> Lets fix the other conditional block by making sure hw_pp is valid<br /> before dereferencing it.<br /> <br /> Patchwork: https://patchwork.freedesktop.org/patch/574878/

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nft_limit: reject configurations that cause integer overflow<br /> <br /> Reject bogus configs where internal token counter wraps around.<br /> This only occurs with very very large requests, such as 17gbyte/s.<br /> <br /> Its better to reject this rather than having incorrect ratelimit.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/sched: flower: Fix chain template offload<br /> <br /> When a qdisc is deleted from a net device the stack instructs the<br /> underlying driver to remove its flow offload callback from the<br /> associated filter block using the &amp;#39;FLOW_BLOCK_UNBIND&amp;#39; command. The stack<br /> then continues to replay the removal of the filters in the block for<br /> this driver by iterating over the chains in the block and invoking the<br /> &amp;#39;reoffload&amp;#39; operation of the classifier being used. In turn, the<br /> classifier in its &amp;#39;reoffload&amp;#39; operation prepares and emits a<br /> &amp;#39;FLOW_CLS_DESTROY&amp;#39; command for each filter.<br /> <br /> However, the stack does not do the same for chain templates and the<br /> underlying driver never receives a &amp;#39;FLOW_CLS_TMPLT_DESTROY&amp;#39; command when<br /> a qdisc is deleted. This results in a memory leak [1] which can be<br /> reproduced using [2].<br /> <br /> Fix by introducing a &amp;#39;tmplt_reoffload&amp;#39; operation and have the stack<br /> invoke it with the appropriate arguments as part of the replay.<br /> Implement the operation in the sole classifier that supports chain<br /> templates (flower) by emitting the &amp;#39;FLOW_CLS_TMPLT_{CREATE,DESTROY}&amp;#39;<br /> command based on whether a flow offload callback is being bound to a<br /> filter block or being unbound from one.<br /> <br /> As far as I can tell, the issue happens since cited commit which<br /> reordered tcf_block_offload_unbind() before tcf_block_flush_all_chains()<br /> in __tcf_block_put(). The order cannot be reversed as the filter block<br /> is expected to be freed after flushing all the chains.<br /> <br /> [1]<br /> unreferenced object 0xffff888107e28800 (size 2048):<br /> comm "tc", pid 1079, jiffies 4294958525 (age 3074.287s)<br /> hex dump (first 32 bytes):<br /> b1 a6 7c 11 81 88 ff ff e0 5b b3 10 81 88 ff ff ..|......[......<br /> 01 00 00 00 00 00 00 00 e0 aa b0 84 ff ff ff ff ................<br /> backtrace:<br /> [] __kmem_cache_alloc_node+0x1e8/0x320<br /> [] __kmalloc+0x4e/0x90<br /> [] mlxsw_sp_acl_ruleset_get+0x34d/0x7a0<br /> [] mlxsw_sp_flower_tmplt_create+0x145/0x180<br /> [] mlxsw_sp_flow_block_cb+0x1ea/0x280<br /> [] tc_setup_cb_call+0x183/0x340<br /> [] fl_tmplt_create+0x3da/0x4c0<br /> [] tc_ctl_chain+0xa15/0x1170<br /> [] rtnetlink_rcv_msg+0x3cc/0xed0<br /> [] netlink_rcv_skb+0x170/0x440<br /> [] netlink_unicast+0x540/0x820<br /> [] netlink_sendmsg+0x8d8/0xda0<br /> [] ____sys_sendmsg+0x30f/0xa80<br /> [] ___sys_sendmsg+0x13a/0x1e0<br /> [] __sys_sendmsg+0x11c/0x1f0<br /> [] do_syscall_64+0x40/0xe0<br /> unreferenced object 0xffff88816d2c0400 (size 1024):<br /> comm "tc", pid 1079, jiffies 4294958525 (age 3074.287s)<br /> hex dump (first 32 bytes):<br /> 40 00 00 00 00 00 00 00 57 f6 38 be 00 00 00 00 @.......W.8.....<br /> 10 04 2c 6d 81 88 ff ff 10 04 2c 6d 81 88 ff ff ..,m......,m....<br /> backtrace:<br /> [] __kmem_cache_alloc_node+0x1e8/0x320<br /> [] __kmalloc_node+0x51/0x90<br /> [] kvmalloc_node+0xa6/0x1f0<br /> [] bucket_table_alloc.isra.0+0x83/0x460<br /> [] rhashtable_init+0x43b/0x7c0<br /> [] mlxsw_sp_acl_ruleset_get+0x428/0x7a0<br /> [] mlxsw_sp_flower_tmplt_create+0x145/0x180<br /> [] mlxsw_sp_flow_block_cb+0x1ea/0x280<br /> [] tc_setup_cb_call+0x183/0x340<br /> [] fl_tmplt_create+0x3da/0x4c0<br /> [] tc_ctl_chain+0xa15/0x1170<br /> [] rtnetlink_rcv_msg+0x3cc/0xed0<br /> [] netlink_rcv_skb+0x170/0x440<br /> [] netlink_unicast+0x540/0x820<br /> [] netlink_sendmsg+0x8d8/0xda0<br /> [] ____sys_sendmsg+0x30f/0xa80<br /> <br /> [2]<br /> # tc qdisc add dev swp1 clsact<br /> # tc chain add dev swp1 ingress proto ip chain 1 flower dst_ip 0.0.0.0/32<br /> # tc qdisc del dev<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> arm64: entry: fix ARM64_WORKAROUND_SPECULATIVE_UNPRIV_LOAD<br /> <br /> Currently the ARM64_WORKAROUND_SPECULATIVE_UNPRIV_LOAD workaround isn&amp;#39;t<br /> quite right, as it is supposed to be applied after the last explicit<br /> memory access, but is immediately followed by an LDR.<br /> <br /> The ARM64_WORKAROUND_SPECULATIVE_UNPRIV_LOAD workaround is used to<br /> handle Cortex-A520 erratum 2966298 and Cortex-A510 erratum 3117295,<br /> which are described in:<br /> <br /> * https://developer.arm.com/documentation/SDEN2444153/0600/?lang=en<br /> * https://developer.arm.com/documentation/SDEN1873361/1600/?lang=en<br /> <br /> In both cases the workaround is described as:<br /> <br /> | If pagetable isolation is disabled, the context switch logic in the<br /> | kernel can be updated to execute the following sequence on affected<br /> | cores before exiting to EL0, and after all explicit memory accesses:<br /> |<br /> | 1. A non-shareable TLBI to any context and/or address, including<br /> | unused contexts or addresses, such as a `TLBI VALE1 Xzr`.<br /> |<br /> | 2. A DSB NSH to guarantee completion of the TLBI.<br /> <br /> The important part being that the TLBI+DSB must be placed "after all<br /> explicit memory accesses".<br /> <br /> Unfortunately, as-implemented, the TLBI+DSB is immediately followed by<br /> an LDR, as we have:<br /> <br /> | alternative_if ARM64_WORKAROUND_SPECULATIVE_UNPRIV_LOAD<br /> | tlbi vale1, xzr<br /> | dsb nsh<br /> | alternative_else_nop_endif<br /> | alternative_if_not ARM64_UNMAP_KERNEL_AT_EL0<br /> | ldr lr, [sp, #S_LR]<br /> | add sp, sp, #PT_REGS_SIZE // restore sp<br /> | eret<br /> | alternative_else_nop_endif<br /> |<br /> | [ ... KPTI exception return path ... ]<br /> <br /> This patch fixes this by reworking the logic to place the TLBI+DSB<br /> immediately before the ERET, after all explicit memory accesses.<br /> <br /> The ERET is currently in a separate alternative block, and alternatives<br /> cannot be nested. To account for this, the alternative block for<br /> ARM64_UNMAP_KERNEL_AT_EL0 is replaced with a single alternative branch<br /> to skip the KPTI logic, with the new shape of the logic being:<br /> <br /> | alternative_insn "b .L_skip_tramp_exit_\@", nop, ARM64_UNMAP_KERNEL_AT_EL0<br /> | [ ... KPTI exception return path ... ]<br /> | .L_skip_tramp_exit_\@:<br /> |<br /> | ldr lr, [sp, #S_LR]<br /> | add sp, sp, #PT_REGS_SIZE // restore sp<br /> |<br /> | alternative_if ARM64_WORKAROUND_SPECULATIVE_UNPRIV_LOAD<br /> | tlbi vale1, xzr<br /> | dsb nsh<br /> | alternative_else_nop_endif<br /> | eret<br /> <br /> The new structure means that the workaround is only applied when KPTI is<br /> not in use; this is fine as noted in the documented implications of the<br /> erratum:<br /> <br /> | Pagetable isolation between EL0 and higher level ELs prevents the<br /> | issue from occurring.<br /> <br /> ... and as per the workaround description quoted above, the workaround<br /> is only necessary "If pagetable isolation is disabled".

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> blk-mq: fix IO hang from sbitmap wakeup race<br /> <br /> In blk_mq_mark_tag_wait(), __add_wait_queue() may be re-ordered<br /> with the following blk_mq_get_driver_tag() in case of getting driver<br /> tag failure.<br /> <br /> Then in __sbitmap_queue_wake_up(), waitqueue_active() may not observe<br /> the added waiter in blk_mq_mark_tag_wait() and wake up nothing, meantime<br /> blk_mq_mark_tag_wait() can&amp;#39;t get driver tag successfully.<br /> <br /> This issue can be reproduced by running the following test in loop, and<br /> fio hang can be observed in

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu: Fix variable &amp;#39;mca_funcs&amp;#39; dereferenced before NULL check in &amp;#39;amdgpu_mca_smu_get_mca_entry()&amp;#39;<br /> <br /> Fixes the below:<br /> <br /> drivers/gpu/drm/amd/amdgpu/amdgpu_mca.c:377 amdgpu_mca_smu_get_mca_entry() warn: variable dereferenced before check &amp;#39;mca_funcs&amp;#39; (see line 368)<br /> <br /> 357 int amdgpu_mca_smu_get_mca_entry(struct amdgpu_device *adev,<br /> enum amdgpu_mca_error_type type,<br /> 358 int idx, struct mca_bank_entry *entry)<br /> 359 {<br /> 360 const struct amdgpu_mca_smu_funcs *mca_funcs =<br /> adev-&gt;mca.mca_funcs;<br /> 361 int count;<br /> 362<br /> 363 switch (type) {<br /> 364 case AMDGPU_MCA_ERROR_TYPE_UE:<br /> 365 count = mca_funcs-&gt;max_ue_count;<br /> <br /> mca_funcs is dereferenced here.<br /> <br /> 366 break;<br /> 367 case AMDGPU_MCA_ERROR_TYPE_CE:<br /> 368 count = mca_funcs-&gt;max_ce_count;<br /> <br /> mca_funcs is dereferenced here.<br /> <br /> 369 break;<br /> 370 default:<br /> 371 return -EINVAL;<br /> 372 }<br /> 373<br /> 374 if (idx &gt;= count)<br /> 375 return -EINVAL;<br /> 376<br /> 377 if (mca_funcs &amp;&amp; mca_funcs-&gt;mca_get_mca_entry)<br /> ^^^^^^^^^<br /> <br /> Checked too late!

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nft_ct: sanitize layer 3 and 4 protocol number in custom expectations<br /> <br /> - Disallow families other than NFPROTO_{IPV4,IPV6,INET}.<br /> - Disallow layer 4 protocol with no ports, since destination port is a<br /> mandatory attribute for this object.

in OpenHarmony v3.2.4 and prior versions allow a local attacker cause apps crash through get permission.

in OpenHarmony v4.0.0 and prior versions allow a local attacker cause DOS through use after free.

in OpenHarmony v4.0.0 and prior versions allow a local attacker arbitrary code execution through out-of-bounds write.