Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mt76: mt7996: add missing check for rx wcid entries<br /> <br /> Non-station wcid entries must not be passed to the rx functions.<br /> In case of the global wcid entry, it could even lead to corruption in the wcid<br /> array due to pointer being casted to struct mt7996_sta_link using container_of.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> spi: microchip-core-qspi: stop checking viability of op-&gt;max_freq in supports_op callback<br /> <br /> In commit 13529647743d9 ("spi: microchip-core-qspi: Support per spi-mem<br /> operation frequency switches") the logic for checking the viability of<br /> op-&gt;max_freq in mchp_coreqspi_setup_clock() was copied into<br /> mchp_coreqspi_supports_op(). Unfortunately, op-&gt;max_freq is not valid<br /> when this function is called during probe but is instead zero.<br /> Accordingly, baud_rate_val is calculated to be INT_MAX due to division<br /> by zero, causing probe of the attached memory device to fail.<br /> <br /> Seemingly spi-microchip-core-qspi was the only driver that had such a<br /> modification made to its supports_op callback when the per_op_freq<br /> capability was added, so just remove it to restore prior functionality.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ixgbe: fix incorrect map used in eee linkmode<br /> <br /> incorrectly used ixgbe_lp_map in loops intended to populate the<br /> supported and advertised EEE linkmode bitmaps based on ixgbe_ls_map.<br /> This results in incorrect bit setting and potential out-of-bounds<br /> access, since ixgbe_lp_map and ixgbe_ls_map have different sizes<br /> and purposes.<br /> <br /> ixgbe_lp_map[i] -&gt; ixgbe_ls_map[i]<br /> <br /> Use ixgbe_ls_map for supported and advertised linkmodes, and keep<br /> ixgbe_lp_map usage only for link partner (lp_advertised) mapping.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> erofs: fix invalid algorithm for encoded extents<br /> <br /> The current algorithm sanity checks do not properly apply to new<br /> encoded extents.<br /> <br /> Unify the algorithm check with Z_EROFS_COMPRESSION(_RUNTIME)_MAX<br /> and ensure consistency with sbi-&gt;available_compr_algs.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> can: j1939: implement NETDEV_UNREGISTER notification handler<br /> <br /> syzbot is reporting<br /> <br /> unregister_netdevice: waiting for vcan0 to become free. Usage count = 2<br /> <br /> problem, for j1939 protocol did not have NETDEV_UNREGISTER notification<br /> handler for undoing changes made by j1939_sk_bind().<br /> <br /> Commit 25fe97cb7620 ("can: j1939: move j1939_priv_put() into sk_destruct<br /> callback") expects that a call to j1939_priv_put() can be unconditionally<br /> delayed until j1939_sk_sock_destruct() is called. But we need to call<br /> j1939_priv_put() against an extra ref held by j1939_sk_bind() call<br /> (as a part of undoing changes made by j1939_sk_bind()) as soon as<br /> NETDEV_UNREGISTER notification fires (i.e. before j1939_sk_sock_destruct()<br /> is called via j1939_sk_release()). Otherwise, the extra ref on "struct<br /> j1939_priv" held by j1939_sk_bind() call prevents "struct net_device" from<br /> dropping the usage count to 1; making it impossible for<br /> unregister_netdevice() to continue.<br /> <br /> [mkl: remove space in front of label]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> genetlink: fix genl_bind() invoking bind() after -EPERM<br /> <br /> Per family bind/unbind callbacks were introduced to allow families<br /> to track multicast group consumer presence, e.g. to start or stop<br /> producing events depending on listeners.<br /> <br /> However, in genl_bind() the bind() callback was invoked even if<br /> capability checks failed and ret was set to -EPERM. This means that<br /> callbacks could run on behalf of unauthorized callers while the<br /> syscall still returned failure to user space.<br /> <br /> Fix this by only invoking bind() after "if (ret) break;" check<br /> i.e. after permission checks have succeeded.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> pcmcia: Add error handling for add_interval() in do_validate_mem()<br /> <br /> In the do_validate_mem(), the call to add_interval() does not<br /> handle errors. If kmalloc() fails in add_interval(), it could<br /> result in a null pointer being inserted into the linked list,<br /> leading to illegal memory access when sub_interval() is called<br /> next.<br /> <br /> This patch adds an error handling for the add_interval(). If<br /> add_interval() returns an error, the function will return early<br /> with the error code.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dmaengine: qcom: bam_dma: Fix DT error handling for num-channels/ees<br /> <br /> When we don&amp;#39;t have a clock specified in the device tree, we have no way to<br /> ensure the BAM is on. This is often the case for remotely-controlled or<br /> remotely-powered BAM instances. In this case, we need to read num-channels<br /> from the DT to have all the necessary information to complete probing.<br /> <br /> However, at the moment invalid device trees without clock and without<br /> num-channels still continue probing, because the error handling is missing<br /> return statements. The driver will then later try to read the number of<br /> channels from the registers. This is unsafe, because it relies on boot<br /> firmware and lucky timing to succeed. Unfortunately, the lack of proper<br /> error handling here has been abused for several Qualcomm SoCs upstream,<br /> causing early boot crashes in several situations [1, 2].<br /> <br /> Avoid these early crashes by erroring out when any of the required DT<br /> properties are missing. Note that this will break some of the existing DTs<br /> upstream (mainly BAM instances related to the crypto engine). However,<br /> clearly these DTs have never been tested properly, since the error in the<br /> kernel log was just ignored. It&amp;#39;s safer to disable the crypto engine for<br /> these broken DTBs.<br /> <br /> [1]: https://lore.kernel.org/r/CY01EKQVWE36.B9X5TDXAREPF@fairphone.com/<br /> [2]: https://lore.kernel.org/r/20230626145959.646747-1-krzysztof.kozlowski@linaro.org/

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nfs/localio: restore creds before releasing pageio data<br /> <br /> Otherwise if the nfsd filecache code releases the nfsd_file<br /> immediately, it can trigger the BUG_ON(cred == current-&gt;cred) in<br /> __put_cred() when it puts the nfsd_file-&gt;nf_file-&gt;f-cred.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: phy: transfer phy_config_inband() locking responsibility to phylink<br /> <br /> Problem description<br /> ===================<br /> <br /> Lockdep reports a possible circular locking dependency (AB/BA) between<br /> &amp;pl-&gt;state_mutex and &amp;phy-&gt;lock, as follows.<br /> <br /> phylink_resolve() // acquires &amp;pl-&gt;state_mutex<br /> -&gt; phylink_major_config()<br /> -&gt; phy_config_inband() // acquires &amp;pl-&gt;phydev-&gt;lock<br /> <br /> whereas all the other call sites where &amp;pl-&gt;state_mutex and<br /> &amp;pl-&gt;phydev-&gt;lock have the locking scheme reversed. Everywhere else,<br /> &amp;pl-&gt;phydev-&gt;lock is acquired at the top level, and &amp;pl-&gt;state_mutex at<br /> the lower level. A clear example is phylink_bringup_phy().<br /> <br /> The outlier is the newly introduced phy_config_inband() and the existing<br /> lock order is the correct one. To understand why it cannot be the other<br /> way around, it is sufficient to consider phylink_phy_change(), phylink&amp;#39;s<br /> callback from the PHY device&amp;#39;s phy-&gt;phy_link_change() virtual method,<br /> invoked by the PHY state machine.<br /> <br /> phy_link_up() and phy_link_down(), the (indirect) callers of<br /> phylink_phy_change(), are called with &amp;phydev-&gt;lock acquired.<br /> Then phylink_phy_change() acquires its own &amp;pl-&gt;state_mutex, to<br /> serialize changes made to its pl-&gt;phy_state and pl-&gt;link_config.<br /> So all other instances of &amp;pl-&gt;state_mutex and &amp;phydev-&gt;lock must be<br /> consistent with this order.<br /> <br /> Problem impact<br /> ==============<br /> <br /> I think the kernel runs a serious deadlock risk if an existing<br /> phylink_resolve() thread, which results in a phy_config_inband() call,<br /> is concurrent with a phy_link_up() or phy_link_down() call, which will<br /> deadlock on &amp;pl-&gt;state_mutex in phylink_phy_change(). Practically<br /> speaking, the impact may be limited by the slow speed of the medium<br /> auto-negotiation protocol, which makes it unlikely for the current state<br /> to still be unresolved when a new one is detected, but I think the<br /> problem is there. Nonetheless, the problem was discovered using lockdep.<br /> <br /> Proposed solution<br /> =================<br /> <br /> Practically speaking, the phy_config_inband() requirement of having<br /> phydev-&gt;lock acquired must transfer to the caller (phylink is the only<br /> caller). There, it must bubble up until immediately before<br /> &amp;pl-&gt;state_mutex is acquired, for the cases where that takes place.<br /> <br /> Solution details, considerations, notes<br /> =======================================<br /> <br /> This is the phy_config_inband() call graph:<br /> <br /> sfp_upstream_ops :: connect_phy()<br /> |<br /> v<br /> phylink_sfp_connect_phy()<br /> |<br /> v<br /> phylink_sfp_config_phy()<br /> |<br /> | sfp_upstream_ops :: module_insert()<br /> | |<br /> | v<br /> | phylink_sfp_module_insert()<br /> | |<br /> | | sfp_upstream_ops :: module_start()<br /> | | |<br /> | | v<br /> | | phylink_sfp_module_start()<br /> | | |<br /> | v v<br /> | phylink_sfp_config_optical()<br /> phylink_start() | |<br /> | phylink_resume() v v<br /> | | phylink_sfp_set_config()<br /> | | |<br /> v v v<br /> phylink_mac_initial_config()<br /> | phylink_resolve()<br /> | | phylink_ethtool_ksettings_set()<br /> v v v<br /> phylink_major_config()<br /> |<br /> v<br /> phy_config_inband()<br /> <br /> phylink_major_config() caller #1, phylink_mac_initial_config(), does not<br /> acquire &amp;pl-&gt;state_mutex nor do its callers. It must acquire<br /> &amp;pl-&gt;phydev-&gt;lock prior to calling phylink_major_config().<br /> <br /> phylink_major_config() caller #2, phylink_resolve() acquires<br /> &amp;pl-&gt;state_mutex, thus also needs to acquire &amp;pl-&gt;phydev-&gt;lock.<br /> <br /> phylink_major_config() caller #3, phylink_ethtool_ksettings_set(), is<br /> completely uninteresting, because it only call<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Fix out-of-bounds dynptr write in bpf_crypto_crypt<br /> <br /> Stanislav reported that in bpf_crypto_crypt() the destination dynptr&amp;#39;s<br /> size is not validated to be at least as large as the source dynptr&amp;#39;s<br /> size before calling into the crypto backend with &amp;#39;len = src_len&amp;#39;. This<br /> can result in an OOB write when the destination is smaller than the<br /> source.<br /> <br /> Concretely, in mentioned function, psrc and pdst are both linear<br /> buffers fetched from each dynptr:<br /> <br /> psrc = __bpf_dynptr_data(src, src_len);<br /> [...]<br /> pdst = __bpf_dynptr_data_rw(dst, dst_len);<br /> [...]<br /> err = decrypt ?<br /> ctx-&gt;type-&gt;decrypt(ctx-&gt;tfm, psrc, pdst, src_len, piv) :<br /> ctx-&gt;type-&gt;encrypt(ctx-&gt;tfm, psrc, pdst, src_len, piv);<br /> <br /> The crypto backend expects pdst to be large enough with a src_len length<br /> that can be written. Add an additional src_len &gt; dst_len check and bail<br /> out if it&amp;#39;s the case. Note that these kfuncs are accessible under root<br /> privileges only.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> i40e: fix IRQ freeing in i40e_vsi_request_irq_msix error path<br /> <br /> If request_irq() in i40e_vsi_request_irq_msix() fails in an iteration<br /> later than the first, the error path wants to free the IRQs requested<br /> so far. However, it uses the wrong dev_id argument for free_irq(), so<br /> it does not free the IRQs correctly and instead triggers the warning:<br /> <br /> Trying to free already-free IRQ 173<br /> WARNING: CPU: 25 PID: 1091 at kernel/irq/manage.c:1829 __free_irq+0x192/0x2c0<br /> Modules linked in: i40e(+) [...]<br /> CPU: 25 UID: 0 PID: 1091 Comm: NetworkManager Not tainted 6.17.0-rc1+ #1 PREEMPT(lazy)<br /> Hardware name: [...]<br /> RIP: 0010:__free_irq+0x192/0x2c0<br /> [...]<br /> Call Trace:<br /> <br /> free_irq+0x32/0x70<br /> i40e_vsi_request_irq_msix.cold+0x63/0x8b [i40e]<br /> i40e_vsi_request_irq+0x79/0x80 [i40e]<br /> i40e_vsi_open+0x21f/0x2f0 [i40e]<br /> i40e_open+0x63/0x130 [i40e]<br /> __dev_open+0xfc/0x210<br /> __dev_change_flags+0x1fc/0x240<br /> netif_change_flags+0x27/0x70<br /> do_setlink.isra.0+0x341/0xc70<br /> rtnl_newlink+0x468/0x860<br /> rtnetlink_rcv_msg+0x375/0x450<br /> netlink_rcv_skb+0x5c/0x110<br /> netlink_unicast+0x288/0x3c0<br /> netlink_sendmsg+0x20d/0x430<br /> ____sys_sendmsg+0x3a2/0x3d0<br /> ___sys_sendmsg+0x99/0xe0<br /> __sys_sendmsg+0x8a/0xf0<br /> do_syscall_64+0x82/0x2c0<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> [...]<br /> <br /> ---[ end trace 0000000000000000 ]---<br /> <br /> Use the same dev_id for free_irq() as for request_irq().<br /> <br /> I tested this with inserting code to fail intentionally.