Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: airoha: Fix memory leak in airoha_qdma_rx_process()<br /> <br /> If an error occurs on the subsequents buffers belonging to the<br /> non-linear part of the skb (e.g. due to an error in the payload length<br /> reported by the NIC or if we consumed all the available fragments for<br /> the skb), the page_pool fragment will not be linked to the skb so it will<br /> not return to the pool in the airoha_qdma_rx_process() error path. Fix the<br /> memory leak partially reverting commit &amp;#39;d6d2b0e1538d ("net: airoha: Fix<br /> page recycling in airoha_qdma_rx_process()")&amp;#39; and always running<br /> page_pool_put_full_page routine in the airoha_qdma_rx_process() error<br /> path.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipv6: ioam: fix potential NULL dereferences in __ioam6_fill_trace_data()<br /> <br /> We need to check __in6_dev_get() for possible NULL value, as<br /> suggested by Yiming Qian.<br /> <br /> Also add skb_dst_dev_rcu() instead of skb_dst_dev(),<br /> and two missing READ_ONCE().<br /> <br /> Note that @dev can&amp;#39;t be NULL.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bridge: guard local VLAN-0 FDB helpers against NULL vlan group<br /> <br /> When CONFIG_BRIDGE_VLAN_FILTERING is not set, br_vlan_group() and<br /> nbp_vlan_group() return NULL (br_private.h stub definitions). The<br /> BR_BOOLOPT_FDB_LOCAL_VLAN_0 toggle code is compiled unconditionally and<br /> reaches br_fdb_delete_locals_per_vlan_port() and<br /> br_fdb_insert_locals_per_vlan_port(), where the NULL vlan group pointer<br /> is dereferenced via list_for_each_entry(v, &amp;vg-&gt;vlan_list, vlist).<br /> <br /> The observed crash is in the delete path, triggered when creating a<br /> bridge with IFLA_BR_MULTI_BOOLOPT containing BR_BOOLOPT_FDB_LOCAL_VLAN_0<br /> via RTM_NEWLINK. The insert helper has the same bug pattern.<br /> <br /> Oops: general protection fault, probably for non-canonical address 0xdffffc0000000056: 0000 [#1] KASAN NOPTI<br /> KASAN: null-ptr-deref in range [0x00000000000002b0-0x00000000000002b7]<br /> RIP: 0010:br_fdb_delete_locals_per_vlan+0x2b9/0x310<br /> Call Trace:<br /> br_fdb_toggle_local_vlan_0+0x452/0x4c0<br /> br_toggle_fdb_local_vlan_0+0x31/0x80 net/bridge/br.c:276<br /> br_boolopt_toggle net/bridge/br.c:313<br /> br_boolopt_multi_toggle net/bridge/br.c:364<br /> br_changelink net/bridge/br_netlink.c:1542<br /> br_dev_newlink net/bridge/br_netlink.c:1575<br /> <br /> Add NULL checks for the vlan group pointer in both helpers, returning<br /> early when there are no VLANs to iterate. This matches the existing<br /> pattern used by other bridge FDB functions such as br_fdb_add() and<br /> br_fdb_delete().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipv4: icmp: fix null-ptr-deref in icmp_build_probe()<br /> <br /> ipv6_stub-&gt;ipv6_dev_find() may return ERR_PTR(-EAFNOSUPPORT) when the<br /> IPv6 stack is not active (CONFIG_IPV6=m and not loaded), and passing<br /> this error pointer to dev_hold() will cause a kernel crash with<br /> null-ptr-deref.<br /> <br /> Instead, silently discard the request. RFC 8335 does not appear to<br /> define a specific response for the case where an IPv6 interface<br /> identifier is syntactically valid but the implementation cannot perform<br /> the lookup at runtime, and silently dropping the request may safer than<br /> misreporting "No Such Interface".

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nfc: s3fwrn5: allocate rx skb before consuming bytes<br /> <br /> s3fwrn82_uart_read() reports the number of accepted bytes to the serdev<br /> core. The current code consumes bytes into recv_skb and may already<br /> deliver a complete frame before allocating a fresh receive buffer.<br /> <br /> If that alloc_skb() fails, the callback returns 0 even though it has<br /> already consumed bytes, and it leaves recv_skb as NULL for the next<br /> receive callback. That breaks the receive_buf() accounting contract and<br /> can also lead to a NULL dereference on the next skb_put_u8().<br /> <br /> Allocate the receive skb lazily before consuming the next byte instead.<br /> If allocation fails, return the number of bytes already accepted.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> PCI: hv: Fix double ida_free in hv_pci_probe error path<br /> <br /> If hv_pci_probe() fails after storing the domain number in<br /> hbus-&gt;bridge-&gt;domain_nr, there is a call to free this domain_nr via<br /> pci_bus_release_emul_domain_nr(), however, during cleanup, the bridge<br /> release callback pci_release_host_bridge_dev() also frees the domain_nr<br /> causing ida_free to be called on same ID twice and triggering following<br /> warning:<br /> <br /> ida_free called for id=28971 which is not allocated.<br /> WARNING: lib/idr.c:594 at ida_free+0xdf/0x160, CPU#0: kworker/0:2/198<br /> Call Trace:<br /> pci_bus_release_emul_domain_nr+0x17/0x20<br /> pci_release_host_bridge_dev+0x4b/0x60<br /> device_release+0x3b/0xa0<br /> kobject_put+0x8e/0x220<br /> devm_pci_alloc_host_bridge_release+0xe/0x20<br /> devres_release_all+0x9a/0xd0<br /> device_unbind_cleanup+0x12/0xa0<br /> really_probe+0x1c5/0x3f0<br /> vmbus_add_channel_work+0x135/0x1a0<br /> <br /> Fix this by letting pci core handle the free domain_nr and remove<br /> the explicit free called in pci-hyperv driver.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xfrm_user: fix info leak in build_mapping()<br /> <br /> struct xfrm_usersa_id has a one-byte padding hole after the proto<br /> field, which ends up never getting set to zero before copying out to<br /> userspace. Fix that up by zeroing out the whole structure before<br /> setting individual variables.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xfrm: fix refcount leak in xfrm_migrate_policy_find<br /> <br /> syzkaller reported a memory leak in xfrm_policy_alloc:<br /> <br /> BUG: memory leak<br /> unreferenced object 0xffff888114d79000 (size 1024):<br /> comm "syz.1.17", pid 931<br /> ...<br /> xfrm_policy_alloc+0xb3/0x4b0 net/xfrm/xfrm_policy.c:432<br /> <br /> The root cause is a double call to xfrm_pol_hold_rcu() in<br /> xfrm_migrate_policy_find(). The lookup function already returns<br /> a policy with held reference, making the second call redundant.<br /> <br /> Remove the redundant xfrm_pol_hold_rcu() call to fix the refcount<br /> imbalance and prevent the memory leak.<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with Syzkaller.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xsk: validate MTU against usable frame size on bind<br /> <br /> AF_XDP bind currently accepts zero-copy pool configurations without<br /> verifying that the device MTU fits into the usable frame space provided<br /> by the UMEM chunk.<br /> <br /> This becomes a problem since we started to respect tailroom which is<br /> subtracted from chunk_size (among with headroom). 2k chunk size might<br /> not provide enough space for standard 1500 MTU, so let us catch such<br /> settings at bind time. Furthermore, validate whether underlying HW will<br /> be able to satisfy configured MTU wrt XSK&amp;#39;s frame size multiplied by<br /> supported Rx buffer chain length (that is exposed via<br /> net_device::xdp_zc_max_segs).

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ixgbevf: add missing negotiate_features op to Hyper-V ops table<br /> <br /> Commit a7075f501bd3 ("ixgbevf: fix mailbox API compatibility by<br /> negotiating supported features") added the .negotiate_features callback<br /> to ixgbe_mac_operations and populated it in ixgbevf_mac_ops, but forgot<br /> to add it to ixgbevf_hv_mac_ops. This leaves the function pointer NULL<br /> on Hyper-V VMs.<br /> <br /> During probe, ixgbevf_negotiate_api() calls ixgbevf_set_features(),<br /> which unconditionally dereferences hw-&gt;mac.ops.negotiate_features().<br /> On Hyper-V this results in a NULL pointer dereference:<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000000<br /> [...]<br /> Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine [...]<br /> Workqueue: events work_for_cpu_fn<br /> RIP: 0010:0x0<br /> [...]<br /> Call Trace:<br /> ixgbevf_negotiate_api+0x66/0x160 [ixgbevf]<br /> ixgbevf_sw_init+0xe4/0x1f0 [ixgbevf]<br /> ixgbevf_probe+0x20f/0x4a0 [ixgbevf]<br /> local_pci_probe+0x50/0xa0<br /> work_for_cpu_fn+0x1a/0x30<br /> [...]<br /> <br /> Add ixgbevf_hv_negotiate_features_vf() that returns -EOPNOTSUPP and<br /> wire it into ixgbevf_hv_mac_ops. The caller already handles -EOPNOTSUPP<br /> gracefully.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: SDCA: Fix errors in IRQ cleanup<br /> <br /> IRQs are enabled through sdca_irq_populate() from component probe<br /> using devm_request_threaded_irq(), this however means the IRQs can<br /> persist if the sound card is torn down. Some of the IRQ handlers<br /> store references to the card and the kcontrols which can then<br /> fail. Some detail of the crash was explained in [1].<br /> <br /> Generally it is not advised to use devm outside of bus probe, so<br /> the code is updated to not use devm. The IRQ requests are not moved<br /> to bus probe time as it makes passing the snd_soc_component into<br /> the IRQs very awkward and would the require a second step once the<br /> component is available, so it is simpler to just register the IRQs<br /> at this point, even though that necessitates some manual cleanup.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xfrm: Wait for RCU readers during policy netns exit<br /> <br /> xfrm_policy_fini() frees the policy_bydst hash tables after flushing the<br /> policy work items and deleting all policies, but it does not wait for<br /> concurrent RCU readers to leave their read-side critical sections first.<br /> <br /> The policy_bydst tables are published via rcu_assign_pointer() and are<br /> looked up through rcu_dereference_check(), so netns teardown must also<br /> wait for an RCU grace period before freeing the table memory.<br /> <br /> Fix this by adding synchronize_rcu() before freeing the policy hash tables.