Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/ptdump: always stabilise against page table freeing using init_mm<br /> <br /> Previous commits have established the invariant that kernel page table<br /> freeing is performed while an mmap read lock on init_mm is held, which<br /> fixes races between ptdump and kernel page table freeing over init_mm.<br /> <br /> However, x86 and arm64 can perform a ptdump over an mm other than init_mm<br /> via ptdump_walk_pgd() and since kernel memory ranges are shared across<br /> non-kernel mm&amp;#39;s, this means that the race still exists for these cases.<br /> <br /> Fix this by acquiring a nested mmap write lock for init_mm in<br /> ptdump_walk_pgd().<br /> <br /> This is safe as we take this after mmap write locking the mm, and nothing<br /> acquires the init_mm lock first before locking an arbitrary mm, so no<br /> deadlock is possible.<br /> <br /> Also update walk_page_range_debug() to assert that init_mm is write<br /> locked, add a comment explaining why and remove some redundant code, and<br /> eliminate the unnecessary and confusing invocation of<br /> walk_kernel_page_table_range().<br /> <br /> We can safely remove the non-NULL check for walk.mm, as the mmap lock<br /> asserts would NULL pointer deref if it was (and of course no callers do<br /> this).<br /> <br /> The first point at which ptdump can race kernel page table freeing is<br /> commit b6bdb7517c3d ("mm/vmalloc: add interfaces to free unmapped page<br /> table"), so we target this in the Fixes tag.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/page_table_check: skip special zero mappings<br /> <br /> page_table_check_set() and page_table_check_clear() account mappings based<br /> on PageAnon(). Shared zero-page PTEs and huge zero PMDs are special<br /> mappings, but page_table_check can still account them as file-backed<br /> pages.<br /> <br /> An unprivileged process can populate enough zero mappings to overflow<br /> file_map_count and hit the existing BUG_ON(). The PTE path can do this<br /> with the shared zero page, and the PMD path can do the same with huge zero<br /> mappings.<br /> <br /> Skip special zero mappings in the user page-table accounting paths. Keep<br /> the PTE-side pte_special() check, and identify huge zero PMDs from the<br /> mapped folio instead of pmd_special(). That covers architectures where<br /> pmd_special() is a no-op without adding huge_zero_pfn checks to the<br /> generic counter helpers.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ring-buffer: Use current_context for safe per-CPU buffer swap<br /> <br /> The ring_buffer_swap_cpu() function currently checks the per-CPU<br /> committing counter to determine if a buffer is actively being written to<br /> before performing the swap. However, there exists a race window where<br /> this check can be bypassed:<br /> <br /> ring_buffer_lock_reserve<br /> cpu_buffer = buffer-&gt;buffers[cpu]; // cpu_buffer_a<br /> rb_reserve_next_event<br /> rb_start_commit // inc committing<br /> if (unlikely(READ_ONCE(cpu_buffer-&gt;buffer) != buffer)) {...}<br /> __rb_reserve_next<br /> rb_move_tail<br /> rb_end_commit(cpu_buffer); // dec committing =&gt; 0<br /> /* interrupt hits here, successfully swaps! */<br /> local_inc(&amp;cpu_buffer-&gt;committing);<br /> <br /> ring_buffer_unlock_commit<br /> cpu_buffer = buffer-&gt;buffers[cpu]; // cpu_buffer_b<br /> rb_commit<br /> rb_end_commit<br /> RB_WARN_ON(cpu_buffer, !local_read(&amp;cpu_buffer-&gt;committing))<br /> // triggers warning<br /> <br /> The committing counter can temporarily drop to 0 during a single write<br /> operation (within rb_move_tail), creating a window where swap can<br /> succeed even though the write is still in progress. This leads to<br /> inconsistent buffer state and triggers the RB_WARN_ON in rb_commit().<br /> <br /> Replace the committing counter check with current_context checks, which<br /> are set at the entry of ring_buffer_lock_reserve() and remain valid<br /> throughout the entire write operation, providing a reliable indicator of<br /> buffer busy state during swap.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ring-buffer: Initialise reader page order in rb_allocate_cpu_buffer()<br /> <br /> In rb_allocate_cpu_buffer(), bpage-&gt;order was omitted, leaving it as 0.<br /> This is an issue for a ring-buffer with subbufs bigger than PAGE_SIZE if<br /> when freed: free_buffer_page() relies on this value. Align the value<br /> with the actual allocation size (buffer::subbuf_order).

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ip6_tunnel: clear skb2-&gt;cb[] in ip6ip6_err()<br /> <br /> ip6ip6_err() clones an outer IPv6 ICMP error skb, pulls it to the<br /> quoted inner IPv6 packet, and then passes the clone to icmpv6_send().<br /> The clone still carries the outer packet&amp;#39;s inet6_skb_parm in skb-&gt;cb.<br /> <br /> If the outer packet had a Home Address Option, IP6CB(skb2)-&gt;dsthao<br /> remains non-zero after skb_pull(). icmpv6_send() later calls<br /> mip6_addr_swap(), which uses that stale dsthao offset against the quoted<br /> inner packet. A malformed inner destination-options header can then make<br /> the HAO lookup and address swap run past the end of the quoted packet<br /> and corrupt skb_shared_info.<br /> <br /> Clear skb2-&gt;cb[] before pulling the quoted inner IPv6 packet so the<br /> reply path does not reuse metadata left by the outer IPv6 stack.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipv6: fix Route Information option length validation<br /> <br /> rt6_route_rcv() validates the Route Information option (RFC 4191) length<br /> against the prefix length, but both checks are off by one.<br /> <br /> rinfo-&gt;length is the ND option length in units of 8 octets and it<br /> *includes* the 8-byte option header, so an option carrying N bytes of<br /> prefix has length == 1 + N/8. RFC 4191 section 2.3 requires length 3<br /> when Prefix Length is greater than 64, and 2 or 3 when it is greater<br /> than 0. The code accepts length &gt;= 2 and length &gt;= 1 respectively.<br /> <br /> ipv6_addr_prefix() then copies prefix_len/8 bytes out of rinfo-&gt;prefix,<br /> so a Router Advertisement with (prefix_len=128, length=2) or<br /> (prefix_len=64, length=1) makes the kernel read up to 8 bytes past the<br /> end of the option. Those bytes end up in the prefix of the route that<br /> gets installed, so they are visible to userspace:<br /> <br /> # RA with a Route Information option (prefix_len=128, length=2)<br /> # followed by a source link-layer address option, 01 01 de ad be ef ca fe<br /> $ ip -6 route show<br /> 2001:db8:dead:beef:101:dead:beef:cafe via fe80::1234 dev veth0 proto ra<br /> ^^^^^^^^^^^^^^^^^^ the next option, read out of bounds<br /> <br /> When the Route Information option is the last one in the packet, those<br /> eight bytes come from the skb tail room instead.<br /> <br /> Reject the option lengths RFC 4191 does not allow.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ptp: ocp: Fix board ID over-read<br /> <br /> The EEPROM board ID is a fixed 13-byte field and is not guaranteed to<br /> contain a NUL terminator. Passing it directly to<br /> devlink_info_version_fixed_put() treats it as a C string and may read<br /> beyond the field.<br /> <br /> Format at most OCP_BOARD_ID_LEN bytes into the existing local buffer<br /> before reporting the ID. Use a precision limit because the snprintf()<br /> output size alone does not bound the source string scan.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Revert "thermal/drivers/hwmon: Cleanup coding style a bit"<br /> <br /> Revert commit 030a48b0f6ce ("thermal/drivers/hwmon: Cleanup coding style<br /> a bit") that introduced a use-after-free into the error path of<br /> thermal_add_hwmon_sysfs() by removing a valid check from it.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> eventfs: Use children field for rcu head and add memory barriers<br /> <br /> When an eventfs inode is freed, it sets ei-&gt;is_freed and then uses its<br /> ei-&gt;list to add it to the srcu link list as the list field is a union with<br /> the rcu list head. As the ei-&gt;list is used to iterate over an SRCU<br /> protected list without taking the eventfs_mutex, there&amp;#39;s nothing stopping<br /> the iteration over that list to see the ei-&gt;rcu instead of the ei-&gt;list<br /> and it will read a corrupt target.<br /> <br /> To fix this, change the union of the rcu list head with the children list.<br /> On freeing the eventfs inode, set the is_free and execute a smp_wmb()<br /> before adding the eventfs inode to the SRCU list.<br /> <br /> On iteration of the ei-&gt;children list, at the start, execute a smp_rmb()<br /> and then read the is_freed of the ei to see if the children list is still<br /> valid. If is_freed is set, then the ei_child read is not valid and the<br /> loop should exit immediately.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sched_ext: Take cgroup_lock() first in scx_cgroup_lock()<br /> <br /> scx_cgroup_lock() write-locks scx_cgroup_ops_rwsem and then takes<br /> cgroup_lock(), which can deadlock through kernfs:<br /> <br /> scx enable/disable cgroup rmdir cpu.weight write<br /> ------------------ ------------ ----------------<br /> cgroup_lock()<br /> percpu_down_write(rwsem)<br /> cgroup_lock()<br /> kernfs_get_active()<br /> percpu_down_read(rwsem)<br /> kernfs_drain()<br /> <br /> The enable path waits for the rmdir to release cgroup_mutex. The rmdir,<br /> deactivating the cpu controller&amp;#39;s files, waits in kernfs_drain() for the<br /> write&amp;#39;s active reference. The write, in scx_group_set_weight(), waits for<br /> the rwsem behind the pending writer.<br /> <br /> Take cgroup_lock() first. The set_* paths take no cgroup locks inside the<br /> read side, so a pending write-lock then only waits for read sections that<br /> always run to completion, and no dependency from the rwsem back to<br /> cgroup_mutex remains.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sched/psi: Shut down rtpoll_timer in psi_cgroup_free()<br /> <br /> psi_schedule_rtpoll_work() is called locklessly from the scheduler hotpath<br /> and can race psi_trigger_destroy() taking down the last rtpoll trigger under<br /> rtpoll_trigger_lock:<br /> <br /> psi_schedule_rtpoll_work() psi_trigger_destroy()<br /> <br /> rcu_read_lock();<br /> task = rcu_dereference(rtpoll_task);<br /> rcu_assign_pointer(rtpoll_task, NULL);<br /> timer_delete(&amp;rtpoll_timer);<br /> mod_timer(&amp;rtpoll_timer, ...);<br /> rcu_read_unlock();<br /> synchronize_rcu();<br /> kthread_stop(task_to_destroy);<br /> <br /> The group can then be freed with the re-armed timer still pending, and<br /> poll_timer_fn() runs on freed memory.<br /> <br /> 461daba06bdc ("psi: eliminate kthread_worker from psi trigger scheduling<br /> mechanism") deleted the timer synchronously after the synchronize_rcu(),<br /> which prevented this but raced trigger creation instead: the deletion could<br /> cancel the timer that a new trigger set armed during the grace period and,<br /> as creation also reinitialized the timer at the time, corrupt it.<br /> 8f91efd870ea ("psi: Fix race between psi_trigger_create/destroy") moved the<br /> initialization into group_init() and the deletion into the locked section,<br /> trading the creation races for the window above.<br /> <br /> Neither placement in the destruction path works. A pending timer firing<br /> while the group is alive is harmless though. poll_timer_fn() just wakes the<br /> rtpoll waitqueue and doesn&amp;#39;t re-arm itself. Bind the timer to the group&amp;#39;s<br /> lifetime instead and shut it down in psi_cgroup_free(). Nothing can arm it<br /> by then. timer_shutdown_sync() because the timer is never armed again.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fscrypt: use the mount idmap for the owner check in fscrypt_ioctl_set_policy()<br /> <br /> fscrypt_ioctl_set_policy() calls inode_owner_or_capable() with<br /> &amp;nop_mnt_idmap before allowing an encryption policy to be set, instead<br /> of the idmap of the mount the ioctl was issued on.<br /> <br /> fscrypt is used by filesystems that support idmapped mounts (e.g. ext4,<br /> f2fs), so on such a mount this compares the caller&amp;#39;s fsuid against the<br /> unmapped on-disk owner rather than the mapped owner: the actual owner<br /> can be wrongly denied with -EACCES and an unrelated caller wrongly<br /> allowed. Use file_mnt_idmap(filp) instead.