Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xfrm: account XFRMA_IF_ID in aevent size calculation<br /> <br /> xfrm_get_ae() allocates the reply skb with xfrm_aevent_msgsize(), then<br /> build_aevent() appends attributes including XFRMA_IF_ID when x-&gt;if_id is<br /> set.<br /> <br /> xfrm_aevent_msgsize() does not include space for XFRMA_IF_ID. For states<br /> with if_id, build_aevent() can fail with -EMSGSIZE and hit BUG_ON(err

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cachefiles: fix incorrect dentry refcount in cachefiles_cull()<br /> <br /> The patch mentioned below changed cachefiles_bury_object() to expect 2<br /> references to the &amp;#39;rep&amp;#39; dentry. Three of the callers were changed to<br /> use start_removing_dentry() which takes an extra reference so in those<br /> cases the call gets the expected references.<br /> <br /> However there is another call to cachefiles_bury_object() in<br /> cachefiles_cull() which did not need to be changed to use<br /> start_removing_dentry() and so was not properly considered.<br /> It still passed the dentry with just one reference so the net result is<br /> that a reference is lost.<br /> <br /> To meet the expectations of cachefiles_bury_object(), cachefiles_cull()<br /> must take an extra reference before the call. It will be dropped by<br /> cachefiles_bury_object().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/vc4: Fix memory leak of BO array in hang state<br /> <br /> The hang state&amp;#39;s BO array is allocated separately with kzalloc() in<br /> vc4_save_hang_state() but never freed in vc4_free_hang_state(). Add the<br /> missing kfree() for the BO array before freeing the hang state struct.

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.

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.

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.

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.

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.

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.

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().

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

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.