Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> x86/efistub: Use 1:1 file:memory mapping for PE/COFF .compat section<br /> <br /> The .compat section is a dummy PE section that contains the address of<br /> the 32-bit entrypoint of the 64-bit kernel image if it is bootable from<br /> 32-bit firmware (i.e., CONFIG_EFI_MIXED=y)<br /> <br /> This section is only 8 bytes in size and is only referenced from the<br /> loader, and so it is placed at the end of the memory view of the image,<br /> to avoid the need for padding it to 4k, which is required for sections<br /> appearing in the middle of the image.<br /> <br /> Unfortunately, this violates the PE/COFF spec, and even if most EFI<br /> loaders will work correctly (including the Tianocore reference<br /> implementation), PE loaders do exist that reject such images, on the<br /> basis that both the file and memory views of the file contents should be<br /> described by the section headers in a monotonically increasing manner<br /> without leaving any gaps.<br /> <br /> So reorganize the sections to avoid this issue. This results in a slight<br /> padding overhead (

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> inet: read sk-&gt;sk_family once in inet_recv_error()<br /> <br /> inet_recv_error() is called without holding the socket lock.<br /> <br /> IPv6 socket could mutate to IPv4 with IPV6_ADDRFORM<br /> socket option and trigger a KCSAN warning.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: atlantic: Fix DMA mapping for PTP hwts ring<br /> <br /> Function aq_ring_hwts_rx_alloc() maps extra AQ_CFG_RXDS_DEF bytes<br /> for PTP HWTS ring but then generic aq_ring_free() does not take this<br /> into account.<br /> Create and use a specific function to free HWTS ring to fix this<br /> issue.<br /> <br /> Trace:<br /> [ 215.351607] ------------[ cut here ]------------<br /> [ 215.351612] DMA-API: atlantic 0000:4b:00.0: device driver frees DMA memory with different size [device address=0x00000000fbdd0000] [map size=34816 bytes] [unmap size=32768 bytes]<br /> [ 215.351635] WARNING: CPU: 33 PID: 10759 at kernel/dma/debug.c:988 check_unmap+0xa6f/0x2360<br /> ...<br /> [ 215.581176] Call Trace:<br /> [ 215.583632] <br /> [ 215.585745] ? show_trace_log_lvl+0x1c4/0x2df<br /> [ 215.590114] ? show_trace_log_lvl+0x1c4/0x2df<br /> [ 215.594497] ? debug_dma_free_coherent+0x196/0x210<br /> [ 215.599305] ? check_unmap+0xa6f/0x2360<br /> [ 215.603147] ? __warn+0xca/0x1d0<br /> [ 215.606391] ? check_unmap+0xa6f/0x2360<br /> [ 215.610237] ? report_bug+0x1ef/0x370<br /> [ 215.613921] ? handle_bug+0x3c/0x70<br /> [ 215.617423] ? exc_invalid_op+0x14/0x50<br /> [ 215.621269] ? asm_exc_invalid_op+0x16/0x20<br /> [ 215.625480] ? check_unmap+0xa6f/0x2360<br /> [ 215.629331] ? mark_lock.part.0+0xca/0xa40<br /> [ 215.633445] debug_dma_free_coherent+0x196/0x210<br /> [ 215.638079] ? __pfx_debug_dma_free_coherent+0x10/0x10<br /> [ 215.643242] ? slab_free_freelist_hook+0x11d/0x1d0<br /> [ 215.648060] dma_free_attrs+0x6d/0x130<br /> [ 215.651834] aq_ring_free+0x193/0x290 [atlantic]<br /> [ 215.656487] aq_ptp_ring_free+0x67/0x110 [atlantic]<br /> ...<br /> [ 216.127540] ---[ end trace 6467e5964dd2640b ]---<br /> [ 216.132160] DMA-API: Mapped at:<br /> [ 216.132162] debug_dma_alloc_coherent+0x66/0x2f0<br /> [ 216.132165] dma_alloc_attrs+0xf5/0x1b0<br /> [ 216.132168] aq_ring_hwts_rx_alloc+0x150/0x1f0 [atlantic]<br /> [ 216.132193] aq_ptp_ring_alloc+0x1bb/0x540 [atlantic]<br /> [ 216.132213] aq_nic_init+0x4a1/0x760 [atlantic]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netdevsim: avoid potential loop in nsim_dev_trap_report_work()<br /> <br /> Many syzbot reports include the following trace [1]<br /> <br /> If nsim_dev_trap_report_work() can not grab the mutex,<br /> it should rearm itself at least one jiffie later.<br /> <br /> [1]<br /> Sending NMI from CPU 1 to CPUs 0:<br /> NMI backtrace for cpu 0<br /> CPU: 0 PID: 32383 Comm: kworker/0:2 Not tainted 6.8.0-rc2-syzkaller-00031-g861c0981648f #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023<br /> Workqueue: events nsim_dev_trap_report_work<br /> RIP: 0010:bytes_is_nonzero mm/kasan/generic.c:89 [inline]<br /> RIP: 0010:memory_is_nonzero mm/kasan/generic.c:104 [inline]<br /> RIP: 0010:memory_is_poisoned_n mm/kasan/generic.c:129 [inline]<br /> RIP: 0010:memory_is_poisoned mm/kasan/generic.c:161 [inline]<br /> RIP: 0010:check_region_inline mm/kasan/generic.c:180 [inline]<br /> RIP: 0010:kasan_check_range+0x101/0x190 mm/kasan/generic.c:189<br /> Code: 07 49 39 d1 75 0a 45 3a 11 b8 01 00 00 00 7c 0b 44 89 c2 e8 21 ed ff ff 83 f0 01 5b 5d 41 5c c3 48 85 d2 74 4f 48 01 ea eb 09 83 c0 01 48 39 d0 74 41 80 38 00 74 f2 eb b6 41 bc 08 00 00 00<br /> RSP: 0018:ffffc90012dcf998 EFLAGS: 00000046<br /> RAX: fffffbfff258af1e RBX: fffffbfff258af1f RCX: ffffffff8168eda3<br /> RDX: fffffbfff258af1f RSI: 0000000000000004 RDI: ffffffff92c578f0<br /> RBP: fffffbfff258af1e R08: 0000000000000000 R09: fffffbfff258af1e<br /> R10: ffffffff92c578f3 R11: ffffffff8acbcbc0 R12: 0000000000000002<br /> R13: ffff88806db38400 R14: 1ffff920025b9f42 R15: ffffffff92c578e8<br /> FS: 0000000000000000(0000) GS:ffff8880b9800000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 000000c00994e078 CR3: 000000002c250000 CR4: 00000000003506f0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> <br /> <br /> instrument_atomic_read include/linux/instrumented.h:68 [inline]<br /> atomic_read include/linux/atomic/atomic-instrumented.h:32 [inline]<br /> queued_spin_is_locked include/asm-generic/qspinlock.h:57 [inline]<br /> debug_spin_unlock kernel/locking/spinlock_debug.c:101 [inline]<br /> do_raw_spin_unlock+0x53/0x230 kernel/locking/spinlock_debug.c:141<br /> __raw_spin_unlock_irqrestore include/linux/spinlock_api_smp.h:150 [inline]<br /> _raw_spin_unlock_irqrestore+0x22/0x70 kernel/locking/spinlock.c:194<br /> debug_object_activate+0x349/0x540 lib/debugobjects.c:726<br /> debug_work_activate kernel/workqueue.c:578 [inline]<br /> insert_work+0x30/0x230 kernel/workqueue.c:1650<br /> __queue_work+0x62e/0x11d0 kernel/workqueue.c:1802<br /> __queue_delayed_work+0x1bf/0x270 kernel/workqueue.c:1953<br /> queue_delayed_work_on+0x106/0x130 kernel/workqueue.c:1989<br /> queue_delayed_work include/linux/workqueue.h:563 [inline]<br /> schedule_delayed_work include/linux/workqueue.h:677 [inline]<br /> nsim_dev_trap_report_work+0x9c0/0xc80 drivers/net/netdevsim/dev.c:842<br /> process_one_work+0x886/0x15d0 kernel/workqueue.c:2633<br /> process_scheduled_works kernel/workqueue.c:2706 [inline]<br /> worker_thread+0x8b9/0x1290 kernel/workqueue.c:2787<br /> kthread+0x2c6/0x3a0 kernel/kthread.c:388<br /> ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147<br /> ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:242<br />

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mac80211: improve CSA/ECSA connection refusal<br /> <br /> As mentioned in the previous commit, we pretty quickly found<br /> that some APs have ECSA elements stuck in their probe response,<br /> so using that to not attempt to connect while CSA is happening<br /> we never connect to such an AP.<br /> <br /> Improve this situation by checking more carefully and ignoring<br /> the ECSA if cfg80211 has previously detected the ECSA element<br /> being stuck in the probe response.<br /> <br /> Additionally, allow connecting to an AP that&amp;#39;s switching to a<br /> channel it&amp;#39;s already using, unless it&amp;#39;s using quiet mode. In<br /> this case, we may just have to adjust bandwidth later. If it&amp;#39;s<br /> actually switching channels, it&amp;#39;s better not to try to connect<br /> in the middle of that.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: cfg80211: detect stuck ECSA element in probe resp<br /> <br /> We recently added some validation that we don&amp;#39;t try to<br /> connect to an AP that is currently in a channel switch<br /> process, since that might want the channel to be quiet<br /> or we might not be able to connect in time to hear the<br /> switching in a beacon. This was in commit c09c4f31998b<br /> ("wifi: mac80211: don&amp;#39;t connect to an AP while it&amp;#39;s in<br /> a CSA process").<br /> <br /> However, we promptly got a report that this caused new<br /> connection failures, and it turns out that the AP that<br /> we now cannot connect to is permanently advertising an<br /> extended channel switch announcement, even with quiet.<br /> The AP in question was an Asus RT-AC53, with firmware<br /> 3.0.0.4.380_10760-g21a5898.<br /> <br /> As a first step, attempt to detect that we&amp;#39;re dealing<br /> with such a situation, so mac80211 can use this later.

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