Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tcp: Fix out-of-bounds access for twsk in tcp_ao_established_key().<br /> <br /> lockdep_sock_is_held() was added in tcp_ao_established_key()<br /> by the cited commit.<br /> <br /> It can be called from tcp_v[46]_timewait_ack() with twsk.<br /> <br /> Since it does not have sk-&gt;sk_lock, the lockdep annotation<br /> results in out-of-bound access.<br /> <br /> $ pahole -C tcp_timewait_sock vmlinux | grep size<br /> /* size: 288, cachelines: 5, members: 8 */<br /> $ pahole -C sock vmlinux | grep sk_lock<br /> socket_lock_t sk_lock; /* 440 192 */<br /> <br /> Let&amp;#39;s not use lockdep_sock_is_held() for TCP_TIME_WAIT.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> NFSD: Fix infinite loop in layout state revocation<br /> <br /> find_one_sb_stid() skips stids whose sc_status is non-zero, but the<br /> SC_TYPE_LAYOUT case in nfsd4_revoke_states() never sets sc_status<br /> before calling nfsd4_close_layout(). The retry loop therefore finds<br /> the same layout stid on every iteration, hanging the revoker<br /> indefinitely.

*** Pendiente de traducción *** 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)

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> pinctrl: meson: amlogic-a4: fix deadlock issue<br /> <br /> Accessing the pinconf-pins sysfs node may deadlock.<br /> <br /> pinconf_pins_show() holds pctldev-&gt;mutex, and the platform driver<br /> calls pinctrl_find_gpio_range_from_pin(), which tries to acquire<br /> the same mutex again, leading to a deadlock.<br /> <br /> Use pinctrl_find_gpio_range_from_pin_nolock() to fix this issue.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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().