Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ethtool: eeprom: add more safeties to EEPROM Netlink fallback<br /> <br /> The Netlink fallback path for reading module EEPROM<br /> (fallback_set_params()) validates that offset total_len)<br /> return -EINVAL;<br /> <br /> This could lead to surprises in both drivers and device FW.<br /> Add the missing offset + length validation to fallback_set_params(),<br /> mirroring the ioctl.<br /> <br /> Similarly - ethtool core in general, and ethtool_get_any_eeprom()<br /> in particular tries to zero-init all buffers passed to the drivers<br /> to avoid any extra work of zeroing things out. eeprom_fallback()<br /> uses a plain kmalloc(), change it to zalloc.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ethtool: tsinfo: don&amp;#39;t pass ERR_PTR to genlmsg_cancel on prepare failure<br /> <br /> The goto err label leads to:<br /> <br /> genlmsg_cancel(skb, ehdr);<br /> return ret;<br /> <br /> If ethnl_tsinfo_prepare_dump() failed, it has not started a genlmsg.<br /> There&amp;#39;s nothing to cancel, and passing an error pointer to<br /> genlmsg_cancel() would cause a crash.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ethtool: coalesce: cap profile updates at NET_DIM_PARAMS_NUM_PROFILES<br /> <br /> ethnl_update_profile() walks the ETHTOOL_A_PROFILE_IRQ_MODERATION<br /> nest list with an index &amp;#39;i&amp;#39; and writes new_profile[i++] without<br /> bounding i. The destination is kmemdup()&amp;#39;d at NET_DIM_PARAMS_NUM_PROFILES<br /> entries (5), but the Netlink nest count is entirely user-controlled.<br /> Netlink policies do not have support for constraining the number<br /> of nested entries (or number of multi-attr entries).

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vsock/virtio: bind uarg before filling zerocopy skb<br /> <br /> virtio_transport_send_pkt_info() allocates or reuses the zerocopy uarg<br /> before entering the send loop, but virtio_transport_alloc_skb() still<br /> fills the skb before it inherits that uarg. When fixed-buffer vectored<br /> zerocopy hits MAX_SKB_FRAGS, io_sg_from_iter() may partially attach<br /> managed frags and return -EMSGSIZE. The rollback path call kfree_skb()<br /> to free an skb that carries SKBFL_MANAGED_FRAG_REFS but no uarg, so<br /> skb_release_data() falls through to ordinary frag unref.<br /> <br /> Pass the uarg into virtio_transport_alloc_skb() and bind it immediately<br /> before virtio_transport_fill_skb(). This keeps control or no-payload skbs<br /> untouched while ensuring success and rollback share one lifetime rule.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sctp: fix race between sctp_wait_for_connect and peeloff<br /> <br /> sctp_wait_for_connect() drops and re-acquires the socket lock while<br /> waiting for the association to reach ESTABLISHED state. During this<br /> window, another thread can peeloff the association to a new socket via<br /> getsockopt(SCTP_SOCKOPT_PEELOFF), changing asoc-&gt;base.sk. After<br /> re-acquiring the old socket lock, sctp_wait_for_connect() returns<br /> success without noticing the migration — the caller then accesses<br /> the association under the wrong lock in sctp_datamsg_from_user().<br /> <br /> Add the same sk != asoc-&gt;base.sk check that sctp_wait_for_sndbuf()<br /> already has, returning an error if the association was migrated while<br /> we slept.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: mana: Skip redundant detach on already-detached port<br /> <br /> When mana_per_port_queue_reset_work_handler() runs after a previous<br /> detach succeeded but attach failed, the port is left in a detached<br /> state with apc-&gt;tx_qp and apc-&gt;rxqs already freed. Calling<br /> mana_detach() again unconditionally leads to NULL pointer dereferences<br /> during queue teardown.<br /> <br /> Add an early exit in mana_detach() when the port is already in<br /> detached state (!netif_device_present) for non-close callers, making<br /> it safe to call idempotently. This allows the queue reset handler and<br /> other recovery paths to simply retry mana_attach() without redundant<br /> teardown.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: mana: Add NULL guards in teardown path to prevent panic on attach failure<br /> <br /> When queue allocation fails partway through, the error cleanup frees<br /> and NULLs apc-&gt;tx_qp and apc-&gt;rxqs. Multiple teardown paths such as<br /> mana_remove(), mana_change_mtu() recovery, and internal error handling<br /> in mana_alloc_queues() can subsequently call into functions that<br /> dereference these pointers without NULL checks:<br /> <br /> - mana_chn_setxdp() dereferences apc-&gt;rxqs[0], causing a NULL pointer<br /> dereference panic (CR2: 0000000000000000 at mana_chn_setxdp+0x26).<br /> - mana_destroy_vport() iterates apc-&gt;rxqs without a NULL check.<br /> - mana_fence_rqs() iterates apc-&gt;rxqs without a NULL check.<br /> - mana_dealloc_queues() iterates apc-&gt;tx_qp without a NULL check.<br /> <br /> Add NULL guards for apc-&gt;rxqs in mana_fence_rqs(),<br /> mana_destroy_vport(), and before the mana_chn_setxdp() call. Add a<br /> NULL guard for apc-&gt;tx_qp in mana_dealloc_queues() to skip TX queue<br /> draining when TX queues were never allocated or already freed.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: hci_sync: Set HCI_CMD_DRAIN_WORKQUEUE during device close<br /> <br /> Since hci_dev_close_sync() can now be called during the reset path, we<br /> should also set HCI_CMD_DRAIN_WORKQUEUE. This avoids queuing timeouts<br /> while the hdev workqueue is being drained.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: L2CAP: Fix possible crash on l2cap_ecred_conn_rsp<br /> <br /> If dcid is received for an already-assigned destination CID the spec<br /> requires that both channels to be discarded, but calling l2cap_chan_del<br /> may invalidate the tmp cursor created by list_for_each_entry_safe and<br /> in fact it is the wrong procedure as the chan-&gt;dcid may be assigned<br /> previously it really needs to be disconnected.<br /> <br /> Calling l2cap_chan_clone directly may still lead to l2cap_chan_del so<br /> instead schedule l2cap_chan_timeout with delay 0 to close the channel<br /> asynchronously.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: l2cap: clear chan-&gt;ident on ECRED reconfiguration success<br /> <br /> l2cap_ecred_reconf_rsp() returns early on success without clearing<br /> chan-&gt;ident. Every other L2CAP response handler (l2cap_ecred_conn_rsp,<br /> l2cap_le_connect_rsp, l2cap_config_rsp) clears chan-&gt;ident after a<br /> successful transaction to prevent the channel from matching subsequent<br /> responses with the recycled ident value.<br /> <br /> A remote attacker that completed a reconfiguration as the peer can<br /> replay a failure response with the stale ident, causing the kernel to<br /> match and destroy the already-established channel via<br /> l2cap_chan_del(chan, ECONNRESET).<br /> <br /> Clear chan-&gt;ident for all matching channels on success, and harden the<br /> failure path by using l2cap_chan_hold_unless_zero() consistent with<br /> other L2CAP handlers (l2cap_le_command_rej, __l2cap_get_chan_by_ident).

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dpll: zl3073x: use __dpll_device_change_ntf() and remove change_work<br /> <br /> The change_work was introduced to send device change notifications<br /> from DPLL device callbacks without deadlocking on dpll_lock, since<br /> the callbacks are already invoked under that lock. Now that<br /> __dpll_device_change_ntf() is exported for callers that already<br /> hold dpll_lock, use it directly and remove the change_work<br /> infrastructure entirely.<br /> <br /> This eliminates a race condition where change_work could be<br /> re-scheduled after cancel_work_sync() during device teardown,<br /> potentially causing the handler to dereference a freed or NULL<br /> dpll_dev pointer.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/handshake: Drain pending requests at net namespace exit<br /> <br /> The arguments to list_splice_init() in handshake_net_exit() are<br /> reversed. The call moves the local empty "requests" list onto<br /> hn-&gt;hn_requests, leaving the local list empty, so the subsequent<br /> drain loop runs zero iterations. Pending handshake requests that<br /> had not yet been accepted are not torn down when the net namespace<br /> is destroyed; each one keeps a reference on a socket file and on<br /> the handshake_req allocation.<br /> <br /> Pass the source and destination in the documented order<br /> (list_splice_init(list, head) moves list onto head) so the pending<br /> list is transferred to the local scratch list and drained through<br /> handshake_complete().<br /> <br /> Fixing the splice direction exposes a list-corruption race. After<br /> the splice each req-&gt;hr_list still has non-empty link pointers,<br /> threading the stack-local scratch list rather than hn_requests.<br /> A concurrent handshake_req_cancel() -- for example, from sunrpc&amp;#39;s<br /> TLS timeout on a kernel socket whose netns reference was not<br /> taken -- finds the request through the rhashtable, calls<br /> remove_pending(), and sees !list_empty(&amp;req-&gt;hr_list).<br /> __remove_pending_locked() then list_del_init()s an entry off the<br /> scratch list while the drain iterates, corrupting it. The same<br /> call arriving after the drain loop has run list_del() on an<br /> entry hits LIST_POISON instead.<br /> <br /> Have remove_pending() check HANDSHAKE_F_NET_DRAINING under<br /> hn_lock and report not-found when drain is in progress. The<br /> drain has already taken ownership; handshake_complete()&amp;#39;s existing<br /> test_and_set on HANDSHAKE_F_REQ_COMPLETED still arbitrates<br /> between drain and cancel for who calls the consumer&amp;#39;s hp_done. Use<br /> list_del_init() rather than list_del() in the drain so req-&gt;hr_list<br /> does not carry LIST_POISON after drain releases the entry.<br /> <br /> The DRAINING guard in remove_pending() makes cancel return false,<br /> but cancel still falls through to test_and_set_bit on<br /> HANDSHAKE_F_REQ_COMPLETED and drops the request&amp;#39;s hr_file reference.<br /> Without another pin, if that is the last reference, sk_destruct frees<br /> the request while it is still linked on the drain loop&amp;#39;s local list.<br /> Pin each request&amp;#39;s hr_file under hn_lock before releasing the list,<br /> and drop that drain pin after the loop finishes with the request.