Vulnerabilidades

*** 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 /> 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 /> 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 /> net: lapbether: handle NETDEV_PRE_TYPE_CHANGE<br /> <br /> lapbeth_data_transmit() expects the underlying device type<br /> to be ARPHRD_ETHER.<br /> <br /> Returning NOTIFY_BAD from lapbeth_device_event() makes sure<br /> bonding driver can not break this expectation.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/vc4: Fix a memory leak in hang state error path<br /> <br /> When vc4_save_hang_state() encounters an early return condition, it<br /> returns without freeing the previously allocated `kernel_state`,<br /> leaking memory.<br /> <br /> Add the missing kfree() calls by consolidating the early return paths<br /> into a single place.

*** 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.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xsk: tighten UMEM headroom validation to account for tailroom and min frame<br /> <br /> The current headroom validation in xdp_umem_reg() could leave us with<br /> insufficient space dedicated to even receive minimum-sized ethernet<br /> frame. Furthermore if multi-buffer would come to play then<br /> skb_shared_info stored at the end of XSK frame would be corrupted.<br /> <br /> HW typically works with 128-aligned sizes so let us provide this value<br /> as bare minimum.<br /> <br /> Multi-buffer setting is known later in the configuration process so<br /> besides accounting for 128 bytes, let us also take care of tailroom space<br /> upfront.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: af_key: zero aligned sockaddr tail in PF_KEY exports<br /> <br /> PF_KEY export paths use `pfkey_sockaddr_size()` when reserving sockaddr<br /> payload space, so IPv6 addresses occupy 32 bytes on the wire. However,<br /> `pfkey_sockaddr_fill()` initializes only the first 28 bytes of<br /> `struct sockaddr_in6`, leaving the final 4 aligned bytes uninitialized.<br /> <br /> Not every PF_KEY message is affected. The state and policy dump builders<br /> already zero the whole message buffer before filling the sockaddr<br /> payloads. Keep the fix to the export paths that still append aligned<br /> sockaddr payloads with plain `skb_put()`:<br /> <br /> - `SADB_ACQUIRE`<br /> - `SADB_X_NAT_T_NEW_MAPPING`<br /> - `SADB_X_MIGRATE`<br /> <br /> Fix those paths by clearing only the aligned sockaddr tail after<br /> `pfkey_sockaddr_fill()`.

*** 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.