Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: airoha: Move ndesc initialization at end of airoha_qdma_init_tx()<br /> <br /> If queue entry list allocation fails in airoha_qdma_init_tx_queue routine,<br /> airoha_qdma_cleanup_tx_queue() will trigger a NULL pointer dereference<br /> accessing the queue entry array. The issue is due to the early ndesc<br /> initialization in airoha_qdma_init_tx_queue(). Fix the issue moving ndesc<br /> initialization at end of airoha_qdma_init_tx routine.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: airoha: Move ndesc initialization at end of airoha_qdma_init_rx_queue()<br /> <br /> If queue entry or DMA descriptor list allocation fails in<br /> airoha_qdma_init_rx_queue routine, airoha_qdma_cleanup() will trigger a<br /> NULL pointer dereference running netif_napi_del() for RX queue NAPIs<br /> since netif_napi_add() has never been executed to this particular RX NAPI.<br /> The issue is due to the early ndesc initialization in<br /> airoha_qdma_init_rx_queue() since airoha_qdma_cleanup() relies on ndesc<br /> value to check if the queue is properly initialized. Fix the issue moving<br /> ndesc initialization at end of airoha_qdma_init_tx routine.<br /> Move page_pool allocation after descriptor list allocation in order to<br /> avoid memory leaks if desc allocation fails.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: mana: Guard mana_remove against double invocation<br /> <br /> If PM resume fails (e.g., mana_attach() returns an error), mana_probe()<br /> calls mana_remove(), which tears down the device and sets<br /> gd-&gt;gdma_context = NULL and gd-&gt;driver_data = NULL.<br /> <br /> However, a failed resume callback does not automatically unbind the<br /> driver. When the device is eventually unbound, mana_remove() is invoked<br /> a second time. Without a NULL check, it dereferences gc-&gt;dev with<br /> gc == NULL, causing a kernel panic.<br /> <br /> Add an early return if gdma_context or driver_data is NULL so the second<br /> invocation is harmless. Move the dev = gc-&gt;dev assignment after the<br /> guard so it cannot dereference NULL.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mailbox: mailbox-test: free channels on probe error<br /> <br /> On probe error, free the previously obtained channels. This not only<br /> prevents a leak, but also UAF scenarios because the client structure<br /> will be removed nonetheless because it was allocated with devm.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mailbox: add sanity check for channel array<br /> <br /> Fail gracefully if there is no channel array attached to the mailbox<br /> controller. Otherwise the later dereference will cause an OOPS which<br /> might not be seen because mailbox controllers might instantiate very<br /> early. Remove the comment explaining the obvious while here.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu: fix AMDGPU_INFO_READ_MMR_REG<br /> <br /> There were multiple issues in that code.<br /> <br /> First of all the order between the reset semaphore and the mm_lock was<br /> wrong (e.g. copy_to_user) was called while holding the lock.<br /> <br /> Then we allocated memory while holding the reset semaphore which is also<br /> a pretty big bug and can deadlock.<br /> <br /> Then we used down_read_trylock() instead of waiting for the reset to<br /> finish.<br /> <br /> (cherry picked from commit 361b6e6b303d4b691f6c5974d3eaab67ca6dd90e)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mailbox: mailbox-test: don&amp;#39;t free the reused channel<br /> <br /> The RX channel can be aliased to the TX channel if it has a different<br /> MMIO. This special case needs to be handled when freeing the channels<br /> otherwise a double-free occurs.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: phonet: do not BUG_ON() in pn_socket_autobind() on failed bind<br /> <br /> syzbot reported a kernel BUG triggered from pn_socket_sendmsg() via<br /> pn_socket_autobind():<br /> <br /> kernel BUG at net/phonet/socket.c:213!<br /> RIP: 0010:pn_socket_autobind net/phonet/socket.c:213 [inline]<br /> RIP: 0010:pn_socket_sendmsg+0x240/0x250 net/phonet/socket.c:421<br /> Call Trace:<br /> sock_sendmsg_nosec+0x112/0x150 net/socket.c:797<br /> __sock_sendmsg net/socket.c:812 [inline]<br /> __sys_sendto+0x402/0x590 net/socket.c:2280<br /> ...<br /> <br /> pn_socket_autobind() calls pn_socket_bind() with port 0 and, on<br /> -EINVAL, assumes the socket was already bound and asserts that the<br /> port is non-zero:<br /> <br /> err = pn_socket_bind(sock, ..., sizeof(struct sockaddr_pn));<br /> if (err != -EINVAL)<br /> return err;<br /> BUG_ON(!pn_port(pn_sk(sock-&gt;sk)-&gt;sobject));<br /> return 0; /* socket was already bound */<br /> <br /> However pn_socket_bind() also returns -EINVAL when sk-&gt;sk_state is not<br /> TCP_CLOSE, even when the socket has never been bound and pn_port() is<br /> still 0. In that case the BUG_ON() fires and panics the kernel from a<br /> user-triggerable path.<br /> <br /> Treat the "bind returned -EINVAL but pn_port() is still 0" case as a<br /> regular error and propagate -EINVAL to the caller instead of crashing.<br /> Existing callers already translate a non-zero return from<br /> pn_socket_autobind() into -ENOBUFS/-EAGAIN, so returning -EINVAL here<br /> only changes behaviour from panic to a normal errno.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: hda/conexant: Fix missing error check for jack detection<br /> <br /> In cx_probe(), the return value of snd_hda_jack_detect_enable_callback()<br /> is ignored. This function returns a pointer, and if it fails (e.g., due<br /> to memory allocation failure), it returns an error pointer which must<br /> be checked using IS_ERR().<br /> <br /> If the registration fails, the driver continues to probe, but the jack<br /> detection callback will not be registered. This can lead to a kernel<br /> crash later when the driver attempts to handle jack events or accesses<br /> the uninitialized structure.<br /> <br /> Check the return value using IS_ERR() and propagate the error via<br /> PTR_ERR() to the probe caller.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/xe/eustall: Fix drm_dev_put called before stream disable in close<br /> <br /> In xe_eu_stall_stream_close(), drm_dev_put() is called before the<br /> stream is disabled and its resources are freed. If this drops the<br /> last reference, the device structures could be freed while the<br /> subsequent cleanup code still accesses them, leading to a<br /> use-after-free.<br /> <br /> Fix this by moving drm_dev_put() after all device accesses are<br /> complete. This matches the ordering in xe_oa_release().<br /> <br /> (cherry picked from commit 35aff528f7297e949e5e19c9cd7fd748cf1cf21c)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> arm64: Reserve an extra page for early kernel mapping<br /> <br /> The final part of [data, end) segment may overflow into the next page of<br /> init_pg_end[1] which is the gap page before early_init_stack[2]:<br /> <br /> [1]<br /> crash_arm64_v9.0.1&gt; vtop ffffffed00601000<br /> VIRTUAL PHYSICAL<br /> ffffffed00601000 83401000<br /> <br /> PAGE DIRECTORY: ffffffecffd62000<br /> PGD: ffffffecffd62da0 =&gt; 10000000833fb003<br /> PMD: ffffff80033fb018 =&gt; 10000000833fe003<br /> PTE: ffffff80033fe008 =&gt; 68000083401f03<br /> PAGE: 83401000<br /> <br /> PTE PHYSICAL FLAGS<br /> 68000083401f03 83401000 (VALID|SHARED|AF|NG|PXN|UXN)<br /> <br /> PAGE PHYSICAL MAPPING INDEX CNT FLAGS<br /> fffffffec00d0040 83401000 0 0 1 4000 reserved<br /> <br /> [2]<br /> ffffffed002c8000 (r) __pi__data<br /> ffffffed0054e000 (d) __pi___bss_start<br /> ffffffed005f5000 (b) __pi_init_pg_dir<br /> ffffffed005fe000 (b) __pi_init_pg_end<br /> ffffffed005ff000 (B) early_init_stack<br /> ffffffed00608000 (b) __pi__end<br /> <br /> For 4K pages, the early kernel mapping may use 2MB block entries but the<br /> kernel segments are only 64KB aligned. Segment boundaries that fall<br /> within a 2MB block therefore require a PTE table so that different<br /> attributes can be applied on either side of the boundary.<br /> <br /> KERNEL_SEGMENT_COUNT still correctly counts the five permanent kernel<br /> VMAs registered by declare_kernel_vmas(). However, since commit<br /> 5973a62efa34 ("arm64: map [_text, _stext) virtual address range<br /> non-executable+read-only"), the early mapper also maps [_text, _stext)<br /> separately from [_stext, _etext). This adds one more early-only split<br /> and can require one more page-table page than the existing<br /> EARLY_SEGMENT_EXTRA_PAGES allowance reserves.<br /> <br /> Increase the 4K-page early mapping allowance by one page to cover that<br /> additional split.<br /> <br /> [catalin.marinas@arm.com: rewrote part of the commit log]<br /> [catalin.marinas@arm.com: expanded the code comment]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ice: fix NULL pointer dereference in ice_reset_all_vfs()<br /> <br /> ice_reset_all_vfs() ignores the return value of ice_vf_rebuild_vsi().<br /> When the VSI rebuild fails (e.g. during NVM firmware update via<br /> nvmupdate64e), ice_vsi_rebuild() tears down the VSI on its error path,<br /> leaving txq_map and rxq_map as NULL. The subsequent unconditional call<br /> to ice_vf_post_vsi_rebuild() leads to a NULL pointer dereference in<br /> ice_ena_vf_q_mappings() when it accesses vsi-&gt;txq_map[0].<br /> <br /> The single-VF reset path in ice_reset_vf() already handles this<br /> correctly by checking the return value of ice_vf_reconfig_vsi() and<br /> skipping ice_vf_post_vsi_rebuild() on failure.<br /> <br /> Apply the same pattern to ice_reset_all_vfs(): check the return value<br /> of ice_vf_rebuild_vsi() and skip ice_vf_post_vsi_rebuild() and<br /> ice_eswitch_attach_vf() on failure. The VF is left safely disabled<br /> (ICE_VF_STATE_INIT not set, VFGEN_RSTAT not set to VFACTIVE) and can<br /> be recovered via a VFLR triggered by a PCI reset of the VF<br /> (sysfs reset or driver rebind).<br /> <br /> Note that this patch does not prevent the VF VSI rebuild from failing<br /> during NVM update — the underlying cause is firmware being in a<br /> transitional state while the EMP reset is processed, which can cause<br /> Admin Queue commands (ice_add_vsi, ice_cfg_vsi_lan) to fail. This<br /> patch only prevents the subsequent NULL pointer dereference that<br /> crashes the kernel when the rebuild does fail.<br /> <br /> crash&gt; bt<br /> PID: 50795 TASK: ff34c9ee708dc680 CPU: 1 COMMAND: "kworker/u512:5"<br /> #0 [ff72159bcfe5bb50] machine_kexec at ffffffffaa8850ee<br /> #1 [ff72159bcfe5bba8] __crash_kexec at ffffffffaaa15fba<br /> #2 [ff72159bcfe5bc68] crash_kexec at ffffffffaaa16540<br /> #3 [ff72159bcfe5bc70] oops_end at ffffffffaa837eda<br /> #4 [ff72159bcfe5bc90] page_fault_oops at ffffffffaa893997<br /> #5 [ff72159bcfe5bce8] exc_page_fault at ffffffffab528595<br /> #6 [ff72159bcfe5bd10] asm_exc_page_fault at ffffffffab600bb2<br /> [exception RIP: ice_ena_vf_q_mappings+0x79]<br /> RIP: ffffffffc0a85b29 RSP: ff72159bcfe5bdc8 RFLAGS: 00010206<br /> RAX: 00000000000f0000 RBX: ff34c9efc9c00000 RCX: 0000000000000000<br /> RDX: 0000000000000000 RSI: 0000000000000010 RDI: ff34c9efc9c00000<br /> RBP: ff34c9efc27d4828 R8: 0000000000000093 R9: 0000000000000040<br /> R10: ff34c9efc27d4828 R11: 0000000000000040 R12: 0000000000100000<br /> R13: 0000000000000010 R14: R15:<br /> ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018<br /> #7 [ff72159bcfe5bdf8] ice_sriov_post_vsi_rebuild at ffffffffc0a85e2e [ice]<br /> #8 [ff72159bcfe5be08] ice_reset_all_vfs at ffffffffc0a920b4 [ice]<br /> #9 [ff72159bcfe5be48] ice_service_task at ffffffffc0a31519 [ice]<br /> #10 [ff72159bcfe5be88] process_one_work at ffffffffaa93dca4<br /> #11 [ff72159bcfe5bec8] worker_thread at ffffffffaa93e9de<br /> #12 [ff72159bcfe5bf18] kthread at ffffffffaa946663<br /> #13 [ff72159bcfe5bf50] ret_from_fork at ffffffffaa8086b9<br /> <br /> The panic occurs attempting to dereference the NULL pointer in RDX at<br /> ice_sriov.c:294, which loads vsi-&gt;txq_map (offset 0x4b8 in ice_vsi).<br /> <br /> The faulting VSI is an allocated slab object but not fully initialized<br /> after a failed ice_vsi_rebuild():<br /> <br /> crash&gt; struct ice_vsi 0xff34c9efc27d4828<br /> netdev = 0x0,<br /> rx_rings = 0x0,<br /> tx_rings = 0x0,<br /> q_vectors = 0x0,<br /> txq_map = 0x0,<br /> rxq_map = 0x0,<br /> alloc_txq = 0x10,<br /> num_txq = 0x10,<br /> alloc_rxq = 0x10,<br /> num_rxq = 0x10,<br /> <br /> The nvmupdate64e process was performing NVM firmware update:<br /> <br /> crash&gt; bt 0xff34c9edd1a30000<br /> PID: 49858 TASK: ff34c9edd1a30000 CPU: 1 COMMAND: "nvmupdate64e"<br /> #0 [ff72159bcd617618] __schedule at ffffffffab5333f8<br /> #4 [ff72159bcd617750] ice_sq_send_cmd at ffffffffc0a35347 [ice]<br /> #5 [ff72159bcd6177a8] ice_sq_send_cmd_retry at ffffffffc0a35b47 [ice]<br /> #6 [ff72159bcd617810] ice_aq_send_cmd at ffffffffc0a38018 [ice]<br /> #7 [ff72159bcd617848] ice_aq_read_nvm at ffffffffc0a40254 [ice]<br /> #8 <br /> ---truncated---