Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: stmmac: xgmac: fix handling of DPP safety error for DMA channels<br /> <br /> Commit 56e58d6c8a56 ("net: stmmac: Implement Safety Features in<br /> XGMAC core") checks and reports safety errors, but leaves the<br /> Data Path Parity Errors for each channel in DMA unhandled at all, lead to<br /> a storm of interrupt.<br /> Fix it by checking and clearing the DMA_DPP_Interrupt_Status register.

in OpenHarmony v4.0.0 and prior versions allow a remote attacker cause DOS through improper input.

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 /> drm/amd/display: Add NULL test for &amp;#39;timing generator&amp;#39; in &amp;#39;dcn21_set_pipe()&amp;#39;<br /> <br /> In "u32 otg_inst = pipe_ctx-&gt;stream_res.tg-&gt;inst;"<br /> pipe_ctx-&gt;stream_res.tg could be NULL, it is relying on the caller to<br /> ensure the tg is not NULL.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Fix &amp;#39;panel_cntl&amp;#39; could be null in &amp;#39;dcn21_set_backlight_level()&amp;#39;<br /> <br /> &amp;#39;panel_cntl&amp;#39; structure used to control the display panel could be null,<br /> dereferencing it could lead to a null pointer access.<br /> <br /> Fixes the below:<br /> drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn21/dcn21_hwseq.c:269 dcn21_set_backlight_level() error: we previously assumed &amp;#39;panel_cntl&amp;#39; could be null (see line 250)

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