Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> i2c: rtl9300: ensure data length is within supported range<br /> <br /> Add an explicit check for the xfer length to &amp;#39;rtl9300_i2c_config_xfer&amp;#39;<br /> to ensure the data length isn&amp;#39;t within the supported range. In<br /> particular a data length of 0 is not supported by the hardware and<br /> causes unintended or destructive behaviour.<br /> <br /> This limitation becomes obvious when looking at the register<br /> documentation [1]. 4 bits are reserved for DATA_WIDTH and the value<br /> of these 4 bits is used as N + 1, allowing a data length range of<br /> 1

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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/

*** Pendiente de traducción *** 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]

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mt76: fix linked list corruption<br /> <br /> Never leave scheduled wcid entries on the temporary on-stack list

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.