Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: ti: icssg-prueth: fix use-after-free of CPPI descriptor in RX path<br /> <br /> cppi5_hdesc_get_psdata() returns a pointer into the CPPI descriptor.<br /> In both emac_rx_packet() and emac_rx_packet_zc(), the descriptor is<br /> freed via k3_cppi_desc_pool_free() before the psdata pointer is used<br /> by emac_rx_timestamp(), which dereferences psdata[0] and psdata[1].<br /> This constitutes a use-after-free on every received packet that goes<br /> through the timestamp path.<br /> <br /> Defer the descriptor free until after all accesses through the psdata<br /> pointer are complete. For emac_rx_packet(), move the free into the<br /> requeue label so both early-exit and success paths free the descriptor<br /> after all accesses are done. For emac_rx_packet_zc(), move the free to<br /> the end of the loop body after emac_dispatch_skb_zc() (which calls<br /> emac_rx_timestamp()) has returned.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> team: fix header_ops type confusion with non-Ethernet ports<br /> <br /> Similar to commit 950803f72547 ("bonding: fix type confusion in<br /> bond_setup_by_slave()") team has the same class of header_ops type<br /> confusion.<br /> <br /> For non-Ethernet ports, team_setup_by_port() copies port_dev-&gt;header_ops<br /> directly. When the team device later calls dev_hard_header() or<br /> dev_parse_header(), these callbacks can run with the team net_device<br /> instead of the real lower device, so netdev_priv(dev) is interpreted as<br /> the wrong private type and can crash.<br /> <br /> The syzbot report shows a crash in bond_header_create(), but the root<br /> cause is in team: the topology is gre -&gt; bond -&gt; team, and team calls<br /> the inherited header_ops with its own net_device instead of the lower<br /> device, so bond_header_create() receives a team device and interprets<br /> netdev_priv() as bonding private data, causing a type confusion crash.<br /> <br /> Fix this by introducing team header_ops wrappers for create/parse,<br /> selecting a team port under RCU, and calling the lower device callbacks<br /> with port-&gt;dev, so each callback always sees the correct net_device<br /> context.<br /> <br /> Also pass the selected lower device to the lower parse callback, so<br /> recursion is bounded in stacked non-Ethernet topologies and parse<br /> callbacks always run with the correct device context.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> udp: Fix wildcard bind conflict check when using hash2<br /> <br /> When binding a udp_sock to a local address and port, UDP uses<br /> two hashes (udptable-&gt;hash and udptable-&gt;hash2) for collision<br /> detection. The current code switches to "hash2" when<br /> hslot-&gt;count &gt; 10.<br /> <br /> "hash2" is keyed by local address and local port.<br /> "hash" is keyed by local port only.<br /> <br /> The issue can be shown in the following bind sequence (pseudo code):<br /> <br /> bind(fd1, "[fd00::1]:8888")<br /> bind(fd2, "[fd00::2]:8888")<br /> bind(fd3, "[fd00::3]:8888")<br /> bind(fd4, "[fd00::4]:8888")<br /> bind(fd5, "[fd00::5]:8888")<br /> bind(fd6, "[fd00::6]:8888")<br /> bind(fd7, "[fd00::7]:8888")<br /> bind(fd8, "[fd00::8]:8888")<br /> bind(fd9, "[fd00::9]:8888")<br /> bind(fd10, "[fd00::10]:8888")<br /> <br /> /* Correctly return -EADDRINUSE because "hash" is used<br /> * instead of "hash2". udp_lib_lport_inuse() detects the<br /> * conflict.<br /> */<br /> bind(fail_fd, "[::]:8888")<br /> <br /> /* After one more socket is bound to "[fd00::11]:8888",<br /> * hslot-&gt;count exceeds 10 and "hash2" is used instead.<br /> */<br /> bind(fd11, "[fd00::11]:8888")<br /> bind(fail_fd, "[::]:8888") /* succeeds unexpectedly */<br /> <br /> The same issue applies to the IPv4 wildcard address "0.0.0.0"<br /> and the IPv4-mapped wildcard address "::ffff:0.0.0.0". For<br /> example, if there are existing sockets bound to<br /> "192.168.1.[1-11]:8888", then binding "0.0.0.0:8888" or<br /> "[::ffff:0.0.0.0]:8888" can also miss the conflict when<br /> hslot-&gt;count &gt; 10.<br /> <br /> TCP inet_csk_get_port() already has the correct check in<br /> inet_use_bhash2_on_bind(). Rename it to<br /> inet_use_hash2_on_bind() and move it to inet_hashtables.h<br /> so udp.c can reuse it in this fix.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/irdma: Initialize free_qp completion before using it<br /> <br /> In irdma_create_qp, if ib_copy_to_udata fails, it will call<br /> irdma_destroy_qp to clean up which will attempt to wait on<br /> the free_qp completion, which is not initialized yet. Fix this<br /> by initializing the completion before the ib_copy_to_udata call.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/efa: Fix use of completion ctx after free<br /> <br /> On admin queue completion handling, if the admin command completed with<br /> error we print data from the completion context. The issue is that we<br /> already freed the completion context in polling/interrupts handler which<br /> means we print data from context in an unknown state (it might be<br /> already used again).<br /> Change the admin submission flow so alloc/dealloc of the context will be<br /> symmetric and dealloc will be called after any potential use of the<br /> context.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: macb: use the current queue number for stats<br /> <br /> There&amp;#39;s a potential mismatch between the memory reserved for statistics<br /> and the amount of memory written.<br /> <br /> gem_get_sset_count() correctly computes the number of stats based on the<br /> active queues, whereas gem_get_ethtool_stats() indiscriminately copies<br /> data using the maximum number of queues, and in the case the number of<br /> active queues is less than MACB_MAX_QUEUES, this results in a OOB write<br /> as observed in the KASAN splat.<br /> <br /> ==================================================================<br /> BUG: KASAN: vmalloc-out-of-bounds in gem_get_ethtool_stats+0x54/0x78<br /> [macb]<br /> Write of size 760 at addr ffff80008080b000 by task ethtool/1027<br /> <br /> CPU: [...]<br /> Tainted: [E]=UNSIGNED_MODULE<br /> Hardware name: raspberrypi rpi/rpi, BIOS 2025.10 10/01/2025<br /> Call trace:<br /> show_stack+0x20/0x38 (C)<br /> dump_stack_lvl+0x80/0xf8<br /> print_report+0x384/0x5e0<br /> kasan_report+0xa0/0xf0<br /> kasan_check_range+0xe8/0x190<br /> __asan_memcpy+0x54/0x98<br /> gem_get_ethtool_stats+0x54/0x78 [macb<br /> 926c13f3af83b0c6fe64badb21ec87d5e93fcf65]<br /> dev_ethtool+0x1220/0x38c0<br /> dev_ioctl+0x4ac/0xca8<br /> sock_do_ioctl+0x170/0x1d8<br /> sock_ioctl+0x484/0x5d8<br /> __arm64_sys_ioctl+0x12c/0x1b8<br /> invoke_syscall+0xd4/0x258<br /> el0_svc_common.constprop.0+0xb4/0x240<br /> do_el0_svc+0x48/0x68<br /> el0_svc+0x40/0xf8<br /> el0t_64_sync_handler+0xa0/0xe8<br /> el0t_64_sync+0x1b0/0x1b8<br /> <br /> The buggy address belongs to a 1-page vmalloc region starting at<br /> 0xffff80008080b000 allocated at dev_ethtool+0x11f0/0x38c0<br /> The buggy address belongs to the physical page:<br /> page: refcount:1 mapcount:0 mapping:0000000000000000<br /> index:0xffff00000a333000 pfn:0xa333<br /> flags: 0x7fffc000000000(node=0|zone=0|lastcpupid=0x1ffff)<br /> raw: 007fffc000000000 0000000000000000 dead000000000122 0000000000000000<br /> raw: ffff00000a333000 0000000000000000 00000001ffffffff 0000000000000000<br /> page dumped because: kasan: bad access detected<br /> <br /> Memory state around the buggy address:<br /> ffff80008080b080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00<br /> ffff80008080b100: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00<br /> &gt;ffff80008080b180: 00 00 00 00 00 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8<br /> ^<br /> ffff80008080b200: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8<br /> ffff80008080b280: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8<br /> ==================================================================<br /> <br /> Fix it by making sure the copied size only considers the active number of<br /> queues.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: ctnetlink: use netlink policy range checks<br /> <br /> Replace manual range and mask validations with netlink policy<br /> annotations in ctnetlink code paths, so that the netlink core rejects<br /> invalid values early and can generate extack errors.<br /> <br /> - CTA_PROTOINFO_TCP_STATE: reject values &gt; TCP_CONNTRACK_SYN_SENT2 at<br /> policy level, removing the manual &gt;= TCP_CONNTRACK_MAX check.<br /> - CTA_PROTOINFO_TCP_WSCALE_ORIGINAL/REPLY: reject values &gt; TCP_MAX_WSCALE<br /> (14). The normal TCP option parsing path already clamps to this value,<br /> but the ctnetlink path accepted 0-255, causing undefined behavior when<br /> used as a u32 shift count.<br /> - CTA_FILTER_ORIG_FLAGS/REPLY_FLAGS: use NLA_POLICY_MASK with<br /> CTA_FILTER_F_ALL, removing the manual mask checks.<br /> - CTA_EXPECT_FLAGS: use NLA_POLICY_MASK with NF_CT_EXPECT_MASK, adding<br /> a new mask define grouping all valid expect flags.<br /> <br /> Extracted from a broader nf-next patch by Florian Westphal, scoped to<br /> ctnetlink for the fixes tree.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nf_conntrack_expect: skip expectations in other netns via proc<br /> <br /> Skip expectations that do not reside in this netns.<br /> <br /> Similar to e77e6ff502ea ("netfilter: conntrack: do not dump other netns&amp;#39;s<br /> conntrack entries via proc").

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: btusb: clamp SCO altsetting table indices<br /> <br /> btusb_work() maps the number of active SCO links to USB alternate<br /> settings through a three-entry lookup table when CVSD traffic uses<br /> transparent voice settings. The lookup currently indexes alts[] with<br /> data-&gt;sco_num - 1 without first constraining sco_num to the number of<br /> available table entries.<br /> <br /> While the table only defines alternate settings for up to three SCO<br /> links, data-&gt;sco_num comes from hci_conn_num() and is used directly.<br /> Cap the lookup to the last table entry before indexing it so the<br /> driver keeps selecting the highest supported alternate setting without<br /> reading past alts[].

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> hwmon: (pmbus/core) Protect regulator operations with mutex<br /> <br /> The regulator operations pmbus_regulator_get_voltage(),<br /> pmbus_regulator_set_voltage(), and pmbus_regulator_list_voltage()<br /> access PMBus registers and shared data but were not protected by<br /> the update_lock mutex. This could lead to race conditions.<br /> <br /> However, adding mutex protection directly to these functions causes<br /> a deadlock because pmbus_regulator_notify() (which calls<br /> regulator_notifier_call_chain()) is often called with the mutex<br /> already held (e.g., from pmbus_fault_handler()). If a regulator<br /> callback then calls one of the now-protected voltage functions,<br /> it will attempt to acquire the same mutex.<br /> <br /> Rework pmbus_regulator_notify() to utilize a worker function to<br /> send notifications outside of the mutex protection. Events are<br /> stored as atomics in a per-page bitmask and processed by the worker.<br /> <br /> Initialize the worker and its associated data during regulator<br /> registration, and ensure it is cancelled on device removal using<br /> devm_add_action_or_reset().<br /> <br /> While at it, remove the unnecessary include of linux/of.h.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> spi: use generic driver_override infrastructure<br /> <br /> When a driver is probed through __driver_attach(), the bus&amp;#39; match()<br /> callback is called without the device lock held, thus accessing the<br /> driver_override field without a lock, which can cause a UAF.<br /> <br /> Fix this by using the driver-core driver_override infrastructure taking<br /> care of proper locking internally.<br /> <br /> Note that calling match() from __driver_attach() without the device lock<br /> held is intentional. [1]<br /> <br /> Also note that we do not enable the driver_override feature of struct<br /> bus_type, as SPI - in contrast to most other buses - passes "" to<br /> sysfs_emit() when the driver_override pointer is NULL. Thus, printing<br /> "\n" instead of "(null)\n".

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Do not skip unrelated mode changes in DSC validation<br /> <br /> Starting with commit 17ce8a6907f7 ("drm/amd/display: Add dsc pre-validation in<br /> atomic check"), amdgpu resets the CRTC state mode_changed flag to false when<br /> recomputing the DSC configuration results in no timing change for a particular<br /> stream.<br /> <br /> However, this is incorrect in scenarios where a change in MST/DSC configuration<br /> happens in the same KMS commit as another (unrelated) mode change. For example,<br /> the integrated panel of a laptop may be configured differently (e.g., HDR<br /> enabled/disabled) depending on whether external screens are attached. In this<br /> case, plugging in external DP-MST screens may result in the mode_changed flag<br /> being dropped incorrectly for the integrated panel if its DSC configuration<br /> did not change during precomputation in pre_validate_dsc().<br /> <br /> At this point, however, dm_update_crtc_state() has already created new streams<br /> for CRTCs with DSC-independent mode changes. In turn,<br /> amdgpu_dm_commit_streams() will never release the old stream, resulting in a<br /> memory leak. amdgpu_dm_atomic_commit_tail() will never acquire a reference to<br /> the new stream either, which manifests as a use-after-free when the stream gets<br /> disabled later on:<br /> <br /> BUG: KASAN: use-after-free in dc_stream_release+0x25/0x90 [amdgpu]<br /> Write of size 4 at addr ffff88813d836524 by task kworker/9:9/29977<br /> <br /> Workqueue: events drm_mode_rmfb_work_fn<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x6e/0xa0<br /> print_address_description.constprop.0+0x88/0x320<br /> ? dc_stream_release+0x25/0x90 [amdgpu]<br /> print_report+0xfc/0x1ff<br /> ? srso_alias_return_thunk+0x5/0xfbef5<br /> ? __virt_addr_valid+0x225/0x4e0<br /> ? dc_stream_release+0x25/0x90 [amdgpu]<br /> kasan_report+0xe1/0x180<br /> ? dc_stream_release+0x25/0x90 [amdgpu]<br /> kasan_check_range+0x125/0x200<br /> dc_stream_release+0x25/0x90 [amdgpu]<br /> dc_state_destruct+0x14d/0x5c0 [amdgpu]<br /> dc_state_release.part.0+0x4e/0x130 [amdgpu]<br /> dm_atomic_destroy_state+0x3f/0x70 [amdgpu]<br /> drm_atomic_state_default_clear+0x8ee/0xf30<br /> ? drm_mode_object_put.part.0+0xb1/0x130<br /> __drm_atomic_state_free+0x15c/0x2d0<br /> atomic_remove_fb+0x67e/0x980<br /> <br /> Since there is no reliable way of figuring out whether a CRTC has unrelated<br /> mode changes pending at the time of DSC validation, remember the value of the<br /> mode_changed flag from before the point where a CRTC was marked as potentially<br /> affected by a change in DSC configuration. Reset the mode_changed flag to this<br /> earlier value instead in pre_validate_dsc().<br /> <br /> (cherry picked from commit cc7c7121ae082b7b82891baa7280f1ff2608f22b)