Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xfrm: move policy_bydst RCU sync from per-netns .exit to .pre_exit<br /> <br /> The struct pernet_operations docstring in include/net/net_namespace.h<br /> explicitly warns against blocking RCU primitives in .exit handlers:<br /> <br /> Exit methods using blocking RCU primitives, such as<br /> synchronize_rcu(), should be implemented via exit_batch.<br /> [...]<br /> Please, avoid synchronize_rcu() at all, where it&amp;#39;s possible.<br /> <br /> Note that a combination of pre_exit() and exit() can<br /> be used, since a synchronize_rcu() is guaranteed between<br /> the calls.<br /> <br /> xfrm_policy_fini() violates this: it calls synchronize_rcu() before<br /> freeing the policy_bydst hash tables (so no RCU reader is mid-<br /> traversal at free time), but runs from xfrm_net_ops.exit -- once per<br /> namespace -- so a cleanup_net() of N namespaces pays N full RCU<br /> grace periods serially.<br /> <br /> Use the documented pre_exit/exit split. Move the policy flush (and<br /> the workqueue drains it depends on) into a new .pre_exit handler;<br /> xfrm_policy_fini() then runs in .exit and frees the hash tables<br /> after the synchronize_rcu_expedited() that cleanup_net() guarantees<br /> between the two phases. Providing O(1) RCU grace periods per batch<br /> instead of O(N).<br /> <br /> Observed on Linux 6.18 with a workload doing unshare(CLONE_NEWNET)<br /> at ~13/sec sustained: cleanup_net() and the netns_wq rescuer kthread<br /> both stuck in xfrm_policy_fini()&amp;#39;s synchronize_rcu(), &gt;300k struct<br /> net accumulated in the cleanup queue, Percpu in /proc/meminfo climbed<br /> to 130+ GB on 256-CPU hosts, and memcg OOMs followed. setup_net and<br /> __put_net counts were balanced, ruling out a refcount leak.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ethtool: tsconfig: fix missing ethnl_ops_complete()<br /> <br /> tsconfig_prepare_data() calls ethnl_ops_begin(), we need to call<br /> ethnl_ops_complete() before returning the error.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> firmware: arm_ffa: Bound PARTITION_INFO_GET_REGS copies<br /> <br /> The register-based PARTITION_INFO_GET path trusted the firmware-provided<br /> indices when copying partition descriptors into the caller buffer.<br /> Reject inconsistent counts or index progressions so the copy loop cannot<br /> write past the allocated array.<br /> <br /> (fixed cur_idx when exactly one descriptor in the first fragment)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5e: Fix eswitch mode block underflow on IPsec acquire SA<br /> <br /> mlx5e_xfrm_add_state() handles acquire-flow temporary SAs by allocating<br /> software state and skipping hardware offload setup.<br /> <br /> That path jumps to the common success label before taking the eswitch mode<br /> block. After tunnel-mode validation was moved earlier, the common success<br /> label unconditionally calls mlx5_eswitch_unblock_mode(). For acquire SAs,<br /> this decrements esw-&gt;offloads.num_block_mode without a matching increment.<br /> <br /> Return directly after installing the acquire SA offload handle, so only the<br /> paths that successfully called mlx5_eswitch_block_mode() call the matching<br /> unblock.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/hyperv: validate resolution_count and fix WIN8 fallback<br /> <br /> A SYNTHVID_RESOLUTION_RESPONSE with resolution_count &gt; 64 walks past<br /> the supported_resolution[SYNTHVID_MAX_RESOLUTION_COUNT] array in the<br /> parse loop. Bound resolution_count against the array size, folded<br /> into the existing zero-check.<br /> <br /> When the WIN10 resolution probe fails, the caller in<br /> hyperv_connect_vsp() left hv-&gt;screen_*_max / preferred_* unpopulated,<br /> which sets mode_config.max_width / max_height to 0 and makes<br /> drm_internal_framebuffer_create() reject every userspace framebuffer<br /> with -EINVAL. The pre-WIN10 branch had the same gap for<br /> preferred_width / preferred_height. Use a single post-probe fallback<br /> guarded by screen_width_max == 0 so both paths converge on the WIN8<br /> defaults.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/handshake: Take a long-lived file reference at submit<br /> <br /> handshake_nl_accept_doit() needs the file pointer backing<br /> req-&gt;hr_sk-&gt;sk_socket to survive the window between<br /> handshake_req_next() and the subsequent FD_PREPARE() and get_file().<br /> The submit-side sock_hold() does not provide that. sk_refcnt keeps<br /> struct sock alive, but struct socket is owned by sock-&gt;file: when<br /> the consumer fputs the last file reference, sock_release() tears<br /> the socket down regardless of any sock_hold.<br /> <br /> Add an hr_file pointer to struct handshake_req and acquire an<br /> explicit reference on sock-&gt;file during handshake_req_submit().<br /> handshake_complete() and handshake_req_cancel() release the<br /> reference on the completion-bit-winning path.<br /> <br /> The submit error path must also release the file reference, but<br /> after rhashtable insertion a concurrent handshake_req_cancel() can<br /> discover the request and race the error path. Gate the error-path<br /> cleanup -- sk_destruct restoration, fput, and request destruction<br /> -- with test_and_set_bit(HANDSHAKE_F_REQ_COMPLETED), the same<br /> serialization handshake_complete() and handshake_req_cancel()<br /> already use. When cancel has already claimed ownership, the submit<br /> error path returns without touching the request; socket teardown<br /> handles final destruction.<br /> <br /> The accept-side dereferences are not yet retargeted; that change<br /> comes in the next patch.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/xe/gsc: Fix double-free of managed BO in error path<br /> <br /> The error path in xe_gsc_init_post_hwconfig() explicitly frees a BO<br /> allocated with xe_managed_bo_create_pin_map() via<br /> xe_bo_unpin_map_no_vm(). Since the managed BO already has a devm<br /> cleanup action registered, this causes a double-free when devm<br /> unwinds during probe failure.<br /> <br /> Remove the explicit free and let devm handle it, consistent with<br /> all other xe_managed_bo_create_pin_map() callers.<br /> <br /> (cherry picked from commit 71d61e3e299a17139e47f980a4d6f425b2c59bf7)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mac80211: fix MLE defragmentation<br /> <br /> If either reconf or EPCS multi-link element (MLE) is contained in<br /> a non-transmitted profile, the defragmentation routine is called<br /> with a pointer to the defragmented copy, but the original elements.<br /> <br /> This is incorrect for two reasons:<br /> - if the original defragmentation was needed, it will not find the<br /> correct data<br /> - if the original frame is at a higher address, the parsing will<br /> potentially overrun the heap data (though given the layout of<br /> the buffers, only into the new defragmentation buffer, and then<br /> it has to stop and fail once that&amp;#39;s filled with copied data.<br /> <br /> Fix it by tracking the container along with the pointer and in<br /> doing so also unify the two almost identical defragmentation<br /> routines.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu/vce1: Fix VCE 1 firmware size and offsets<br /> <br /> The VCPU BO contains the actual FW at an offset, but<br /> it was not calculated into the VCPU BO size.<br /> Subtract this from the FW size to make sure there is<br /> no out of bounds access.<br /> <br /> Make sure the stack and data offsets are aligned to<br /> the 32K TLB size.<br /> <br /> Check that the FW microcode actually fits in the<br /> space that is reserved for it.<br /> <br /> (cherry picked from commit c16fe59f622a080fc457a57b3e8f14c780699449)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rust: block: fix GenDisk cleanup paths<br /> <br /> GenDiskBuilder::build() still has fallible work after<br /> __blk_mq_alloc_disk(), but its error path only recovers the<br /> foreign queue data. That leaks the temporary gendisk and<br /> request_queue until later teardown. If the caller moved the last<br /> Arc into build(), the leaked queue can retain blk-mq<br /> state after the tag set is dropped.<br /> <br /> Fix the pre-registration failure path by dropping the temporary<br /> gendisk reference with put_disk() before recovering queue_data,<br /> so disk_release() can tear down the owned queue.<br /> <br /> Also pair GenDisk::drop() with put_disk() after del_gendisk().<br /> Once a Rust GenDisk has been added with device_add_disk(),<br /> del_gendisk() only unregisters it; the final gendisk reference<br /> still has to be dropped to complete the release path.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ACPI: NFIT: core: Fix acpi_nfit_init() error cleanup<br /> <br /> If acpi_nfit_init() fails after adding the acpi_desc object to the<br /> acpi_descs list, that object is never removed from that list because<br /> the acpi_nfit_shutdown() devm action is not added for the NFIT device<br /> in that case. Next, the acpi_nfit_init() failure causes<br /> acpi_nfit_probe() to fail, the acpi_desc object is freed, and a<br /> dangling pointer is left behind in the acpi_descs. Any subsequent<br /> ACPI Machine Check Exception will trigger nfit_handle_mce() which<br /> iterates over acpi_descs and so a use-after-free will occur.<br /> <br /> Moreover, if acpi_nfit_probe() returns 0 after installing a notify<br /> handler for the NFIT device and without allocating the acpi_desc<br /> object and setting the NFIT device&amp;#39;s driver data pointer, the<br /> acpi_desc object will be allocated by acpi_nfit_update_notify()<br /> and acpi_nfit_init() will be called to initialize it. Regardless<br /> of whether or not acpi_nfit_init() fails in that case, the<br /> acpi_nfit_shutdown() devm action is not added for the NFIT device<br /> and acpi_desc is never removed from the acpi_descs list. If the<br /> acpi_desc object is freed subsequently on driver removal, any<br /> subsequent ACPI MCE will lead to a use-after-free like in the<br /> previous case.<br /> <br /> To address the first issue mentioned above, make acpi_nfit_probe()<br /> call acpi_nfit_shutdown() directly on acpi_nfit_init() failures and<br /> to address the other one, add a remove callback to the driver and<br /> make it call acpi_nfit_shutdown(). Also, since it is now possible to<br /> pass NULL to acpi_nfit_shutdown() or the acpi_desc object passed to it<br /> may not have been initialized, add checks against NULL for acpi_desc and<br /> its nvdimm_bus field to that function and make acpi_nfit_unregister()<br /> clear the latter after unregistering the NVDIMM bus.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ACPI: NFIT: core: Fix possible NULL pointer dereference<br /> <br /> After commit 9b311b7313d6 ("ACPI: NFIT: Install Notify() handler before<br /> getting NFIT table"), acpi_nfit_probe() installs an ACPI notify handler<br /> for the NFIT device before checking the presence of the NFIT table. If<br /> that table is not there, 0 is returned without allocating the acpi_desc<br /> object and setting the driver data pointer of the NFIT device. If the<br /> platform firmware triggers an NFIT_NOTIFY_UC_MEMORY_ERROR notification<br /> on the NFIT device at that point, acpi_nfit_uc_error_notify() will<br /> dereference a NULL pointer.<br /> <br /> Prevent that from occurring by adding an acpi_desc check against NULL<br /> to acpi_nfit_uc_error_notify().