Vulnerabilities

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 the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Implement bounds check for stream encoder creation in DCN301<br /> <br /> &amp;#39;stream_enc_regs&amp;#39; array is an array of dcn10_stream_enc_registers<br /> structures. The array is initialized with four elements, corresponding<br /> to the four calls to stream_enc_regs() in the array initializer. This<br /> means that valid indices for this array are 0, 1, 2, and 3.<br /> <br /> The error message &amp;#39;stream_enc_regs&amp;#39; 4

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tipc: Check the bearer type before calling tipc_udp_nl_bearer_add()<br /> <br /> syzbot reported the following general protection fault [1]:<br /> <br /> general protection fault, probably for non-canonical address 0xdffffc0000000010: 0000 [#1] PREEMPT SMP KASAN<br /> KASAN: null-ptr-deref in range [0x0000000000000080-0x0000000000000087]<br /> ...<br /> RIP: 0010:tipc_udp_is_known_peer+0x9c/0x250 net/tipc/udp_media.c:291<br /> ...<br /> Call Trace:<br /> <br /> tipc_udp_nl_bearer_add+0x212/0x2f0 net/tipc/udp_media.c:646<br /> tipc_nl_bearer_add+0x21e/0x360 net/tipc/bearer.c:1089<br /> genl_family_rcv_msg_doit+0x1fc/0x2e0 net/netlink/genetlink.c:972<br /> genl_family_rcv_msg net/netlink/genetlink.c:1052 [inline]<br /> genl_rcv_msg+0x561/0x800 net/netlink/genetlink.c:1067<br /> netlink_rcv_skb+0x16b/0x440 net/netlink/af_netlink.c:2544<br /> genl_rcv+0x28/0x40 net/netlink/genetlink.c:1076<br /> netlink_unicast_kernel net/netlink/af_netlink.c:1341 [inline]<br /> netlink_unicast+0x53b/0x810 net/netlink/af_netlink.c:1367<br /> netlink_sendmsg+0x8b7/0xd70 net/netlink/af_netlink.c:1909<br /> sock_sendmsg_nosec net/socket.c:730 [inline]<br /> __sock_sendmsg+0xd5/0x180 net/socket.c:745<br /> ____sys_sendmsg+0x6ac/0x940 net/socket.c:2584<br /> ___sys_sendmsg+0x135/0x1d0 net/socket.c:2638<br /> __sys_sendmsg+0x117/0x1e0 net/socket.c:2667<br /> do_syscall_x64 arch/x86/entry/common.c:52 [inline]<br /> do_syscall_64+0x40/0x110 arch/x86/entry/common.c:83<br /> entry_SYSCALL_64_after_hwframe+0x63/0x6b<br /> <br /> The cause of this issue is that when tipc_nl_bearer_add() is called with<br /> the TIPC_NLA_BEARER_UDP_OPTS attribute, tipc_udp_nl_bearer_add() is called<br /> even if the bearer is not UDP.<br /> <br /> tipc_udp_is_known_peer() called by tipc_udp_nl_bearer_add() assumes that<br /> the media_ptr field of the tipc_bearer has an udp_bearer type object, so<br /> the function goes crazy for non-UDP bearers.<br /> <br /> This patch fixes the issue by checking the bearer type before calling<br /> tipc_udp_nl_bearer_add() in tipc_nl_bearer_add().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> hwmon: (coretemp) Fix out-of-bounds memory access<br /> <br /> Fix a bug that pdata-&gt;cpu_map[] is set before out-of-bounds check.<br /> The problem might be triggered on systems with more than 128 cores per<br /> package.

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 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.