Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> x86: shadow stacks: proper error handling for mmap lock<br /> <br /> 김영민 reports that shstk_pop_sigframe() doesn&amp;#39;t check for errors from<br /> mmap_read_lock_killable(), which is a silly oversight, and also shows<br /> that we haven&amp;#39;t marked those functions with "__must_check", which would<br /> have immediately caught it.<br /> <br /> So let&amp;#39;s fix both issues.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mshv: Fix infinite fault loop on permission-denied GPA intercepts<br /> <br /> Prevent infinite fault loops when guests access memory regions without<br /> proper permissions. Currently, mshv_handle_gpa_intercept() attempts to<br /> remap pages for all faults on movable memory regions, regardless of<br /> whether the access type is permitted. When a guest writes to a read-only<br /> region, the remap succeeds but the region remains read-only, causing<br /> immediate re-fault and spinning the vCPU indefinitely.<br /> <br /> Validate intercept access type against region permissions before<br /> attempting remaps. Reject writes to non-writable regions and executes to<br /> non-executable regions early, returning false to let the VMM handle the<br /> intercept appropriately.<br /> <br /> This also closes a potential DoS vector where malicious guests could<br /> intentionally trigger these fault loops to consume host resources.

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