Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> perf: Avoid undefined behavior from stopping/starting inactive events<br /> <br /> Calling pmu-&gt;start()/stop() on perf events in PERF_EVENT_STATE_OFF can<br /> leave event-&gt;hw.idx at -1. When PMU drivers later attempt to use this<br /> negative index as a shift exponent in bitwise operations, it leads to UBSAN<br /> shift-out-of-bounds reports.<br /> <br /> The issue is a logical flaw in how event groups handle throttling when some<br /> members are intentionally disabled. Based on the analysis and the<br /> reproducer provided by Mark Rutland (this issue on both arm64 and x86-64).<br /> <br /> The scenario unfolds as follows:<br /> <br /> 1. A group leader event is configured with a very aggressive sampling<br /> period (e.g., sample_period = 1). This causes frequent interrupts and<br /> triggers the throttling mechanism.<br /> 2. A child event in the same group is created in a disabled state<br /> (.disabled = 1). This event remains in PERF_EVENT_STATE_OFF.<br /> Since it hasn&amp;#39;t been scheduled onto the PMU, its event-&gt;hw.idx remains<br /> initialized at -1.<br /> 3. When throttling occurs, perf_event_throttle_group() and later<br /> perf_event_unthrottle_group() iterate through all siblings, including<br /> the disabled child event.<br /> 4. perf_event_throttle()/unthrottle() are called on this inactive child<br /> event, which then call event-&gt;pmu-&gt;start()/stop().<br /> 5. The PMU driver receives the event with hw.idx == -1 and attempts to<br /> use it as a shift exponent. e.g., in macros like PMCNTENSET(idx),<br /> leading to the UBSAN report.<br /> <br /> The throttling mechanism attempts to start/stop events that are not<br /> actively scheduled on the hardware.<br /> <br /> Move the state check into perf_event_throttle()/perf_event_unthrottle() so<br /> that inactive events are skipped entirely. This ensures only active events<br /> with a valid hw.idx are processed, preventing undefined behavior and<br /> silencing UBSAN warnings. The corrected check ensures true before<br /> proceeding with PMU operations.<br /> <br /> The problem can be reproduced with the syzkaller reproducer:

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> io_uring/kbuf: fix signedness in this_len calculation<br /> <br /> When importing and using buffers, buf-&gt;len is considered unsigned.<br /> However, buf-&gt;len is converted to signed int when committing. This can<br /> lead to unexpected behavior if the buffer is large enough to be<br /> interpreted as a negative value. Make min_t calculation unsigned.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs/smb: Fix inconsistent refcnt update<br /> <br /> A possible inconsistent update of refcount was identified in `smb2_compound_op`.<br /> Such inconsistent update could lead to possible resource leaks.<br /> <br /> Why it is a possible bug:<br /> 1. In the comment section of the function, it clearly states that the<br /> reference to `cfile` should be dropped after calling this function.<br /> 2. Every control flow path would check and drop the reference to<br /> `cfile`, except the patched one.<br /> 3. Existing callers would not handle refcount update of `cfile` if<br /> -ENOMEM is returned.<br /> <br /> To fix the bug, an extra goto label "out" is added, to make sure that the<br /> cleanup logic would always be respected. As the problem is caused by the<br /> allocation failure of `vars`, the cleanup logic between label "finished"<br /> and "out" can be safely ignored. According to the definition of function<br /> `is_replayable_error`, the error code of "-ENOMEM" is not recoverable.<br /> Therefore, the replay logic also gets ignored.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/msm/dpu: Add a null ptr check for dpu_encoder_needs_modeset<br /> <br /> The drm_atomic_get_new_connector_state() can return NULL if the<br /> connector is not part of the atomic state. Add a check to prevent<br /> a NULL pointer dereference.<br /> <br /> This follows the same pattern used in dpu_encoder_update_topology()<br /> within the same file, which checks for NULL before using conn_state.<br /> <br /> Patchwork: https://patchwork.freedesktop.org/patch/665188/

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> HID: intel-thc-hid: intel-thc: Fix incorrect pointer arithmetic in I2C regs save<br /> <br /> Improper use of secondary pointer (&amp;dev-&gt;i2c_subip_regs) caused<br /> kernel crash and out-of-bounds error:<br /> <br /> BUG: KASAN: slab-out-of-bounds in _regmap_bulk_read+0x449/0x510<br /> Write of size 4 at addr ffff888136005dc0 by task kworker/u33:5/5107<br /> <br /> CPU: 3 UID: 0 PID: 5107 Comm: kworker/u33:5 Not tainted 6.16.0+ #3 PREEMPT(voluntary)<br /> Workqueue: async async_run_entry_fn<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x76/0xa0<br /> print_report+0xd1/0x660<br /> ? __pfx__raw_spin_lock_irqsave+0x10/0x10<br /> ? kasan_complete_mode_report_info+0x26/0x200<br /> kasan_report+0xe1/0x120<br /> ? _regmap_bulk_read+0x449/0x510<br /> ? _regmap_bulk_read+0x449/0x510<br /> __asan_report_store4_noabort+0x17/0x30<br /> _regmap_bulk_read+0x449/0x510<br /> ? __pfx__regmap_bulk_read+0x10/0x10<br /> regmap_bulk_read+0x270/0x3d0<br /> pio_complete+0x1ee/0x2c0 [intel_thc]<br /> ? __pfx_pio_complete+0x10/0x10 [intel_thc]<br /> ? __pfx_pio_wait+0x10/0x10 [intel_thc]<br /> ? regmap_update_bits_base+0x13b/0x1f0<br /> thc_i2c_subip_pio_read+0x117/0x270 [intel_thc]<br /> thc_i2c_subip_regs_save+0xc2/0x140 [intel_thc]<br /> ? __pfx_thc_i2c_subip_regs_save+0x10/0x10 [intel_thc]<br /> [...]<br /> The buggy address belongs to the object at ffff888136005d00<br /> which belongs to the cache kmalloc-rnd-12-192 of size 192<br /> The buggy address is located 0 bytes to the right of<br /> allocated 192-byte region [ffff888136005d00, ffff888136005dc0)<br /> <br /> Replaced with direct array indexing (&amp;dev-&gt;i2c_subip_regs[i]) to ensure<br /> safe memory access.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> efivarfs: Fix slab-out-of-bounds in efivarfs_d_compare<br /> <br /> Observed on kernel 6.6 (present on master as well):<br /> <br /> BUG: KASAN: slab-out-of-bounds in memcmp+0x98/0xd0<br /> Call trace:<br /> kasan_check_range+0xe8/0x190<br /> __asan_loadN+0x1c/0x28<br /> memcmp+0x98/0xd0<br /> efivarfs_d_compare+0x68/0xd8<br /> __d_lookup_rcu_op_compare+0x178/0x218<br /> __d_lookup_rcu+0x1f8/0x228<br /> d_alloc_parallel+0x150/0x648<br /> lookup_open.isra.0+0x5f0/0x8d0<br /> open_last_lookups+0x264/0x828<br /> path_openat+0x130/0x3f8<br /> do_filp_open+0x114/0x248<br /> do_sys_openat2+0x340/0x3c0<br /> __arm64_sys_openat+0x120/0x1a0<br /> <br /> If dentry-&gt;d_name.len lookup<br /> simple_lookup<br /> d_add<br /> // invalid dentry is added to hash list<br /> <br /> lookup_open<br /> d_alloc_parallel<br /> __d_lookup_rcu<br /> __d_lookup_rcu_op_compare<br /> hlist_bl_for_each_entry_rcu<br /> // invalid dentry can be retrieved<br /> -&gt;d_compare<br /> efivarfs_d_compare<br /> // oob<br /> <br /> Fix it by checking &amp;#39;guid&amp;#39; before cmp.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> io_uring/kbuf: always use READ_ONCE() to read ring provided buffer lengths<br /> <br /> Since the buffers are mapped from userspace, it is prudent to use<br /> READ_ONCE() to read the value into a local variable, and use that for<br /> any other actions taken. Having a stable read of the buffer length<br /> avoids worrying about it changing after checking, or being read multiple<br /> times.<br /> <br /> Similarly, the buffer may well change in between it being picked and<br /> being committed. Ensure the looping for incremental ring buffer commit<br /> stops if it hits a zero sized buffer, as no further progress can be made<br /> at that point.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RISC-V: KVM: fix stack overrun when loading vlenb<br /> <br /> The userspace load can put up to 2048 bits into an xlen bit stack<br /> buffer. We want only xlen bits, so check the size beforehand.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ftrace: Fix potential warning in trace_printk_seq during ftrace_dump<br /> <br /> When calling ftrace_dump_one() concurrently with reading trace_pipe,<br /> a WARN_ON_ONCE() in trace_printk_seq() can be triggered due to a race<br /> condition.<br /> <br /> The issue occurs because:<br /> <br /> CPU0 (ftrace_dump) CPU1 (reader)<br /> echo z &gt; /proc/sysrq-trigger<br /> <br /> !trace_empty(&amp;iter)<br /> trace_iterator_reset(&amp;iter) = s-&gt;seq.size)<br /> <br /> In the context between trace_empty() and trace_find_next_entry_inc()<br /> during ftrace_dump, the ring buffer data was consumed by other readers.<br /> This caused trace_find_next_entry_inc to return NULL, failing to populate<br /> `iter.seq`. At this point, due to the prior trace_iterator_reset, both<br /> `iter.seq.len` and `iter.seq.size` were set to 0. Since they are equal,<br /> the WARN_ON_ONCE condition is triggered.<br /> <br /> Move the trace_printk_seq() into the if block that checks to make sure the<br /> return value of trace_find_next_entry_inc() is non-NULL in<br /> ftrace_dump_one(), ensuring the &amp;#39;iter.seq&amp;#39; is properly populated before<br /> subsequent operations.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ice: fix NULL pointer dereference in ice_unplug_aux_dev() on reset<br /> <br /> Issuing a reset when the driver is loaded without RDMA support, will<br /> results in a crash as it attempts to remove RDMA&amp;#39;s non-existent auxbus<br /> device:<br /> echo 1 &gt; /sys/class/net//device/reset<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000008<br /> ...<br /> RIP: 0010:ice_unplug_aux_dev+0x29/0x70 [ice]<br /> ...<br /> Call Trace:<br /> <br /> ice_prepare_for_reset+0x77/0x260 [ice]<br /> pci_dev_save_and_disable+0x2c/0x70<br /> pci_reset_function+0x88/0x130<br /> reset_store+0x5a/0xa0<br /> kernfs_fop_write_iter+0x15e/0x210<br /> vfs_write+0x273/0x520<br /> ksys_write+0x6b/0xe0<br /> do_syscall_64+0x79/0x3b0<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> <br /> ice_unplug_aux_dev() checks pf-&gt;cdev_info-&gt;adev for NULL pointer, but<br /> pf-&gt;cdev_info will also be NULL, leading to the deref in the trace above.<br /> <br /> Introduce a flag to be set when the creation of the auxbus device is<br /> successful, to avoid multiple NULL pointer checks in ice_unplug_aux_dev().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/xe/vm: Clear the scratch_pt pointer on error<br /> <br /> Avoid triggering a dereference of an error pointer on cleanup in<br /> xe_vm_free_scratch() by clearing any scratch_pt error pointer.<br /> <br /> (cherry picked from commit 358ee50ab565f3c8ea32480e9d03127a81ba32f8)

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sctp: initialize more fields in sctp_v6_from_sk()<br /> <br /> syzbot found that sin6_scope_id was not properly initialized,<br /> leading to undefined behavior.<br /> <br /> Clear sin6_scope_id and sin6_flowinfo.<br /> <br /> BUG: KMSAN: uninit-value in __sctp_v6_cmp_addr+0x887/0x8c0 net/sctp/ipv6.c:649<br /> __sctp_v6_cmp_addr+0x887/0x8c0 net/sctp/ipv6.c:649<br /> sctp_inet6_cmp_addr+0x4f2/0x510 net/sctp/ipv6.c:983<br /> sctp_bind_addr_conflict+0x22a/0x3b0 net/sctp/bind_addr.c:390<br /> sctp_get_port_local+0x21eb/0x2440 net/sctp/socket.c:8452<br /> sctp_get_port net/sctp/socket.c:8523 [inline]<br /> sctp_listen_start net/sctp/socket.c:8567 [inline]<br /> sctp_inet_listen+0x710/0xfd0 net/sctp/socket.c:8636<br /> __sys_listen_socket net/socket.c:1912 [inline]<br /> __sys_listen net/socket.c:1927 [inline]<br /> __do_sys_listen net/socket.c:1932 [inline]<br /> __se_sys_listen net/socket.c:1930 [inline]<br /> __x64_sys_listen+0x343/0x4c0 net/socket.c:1930<br /> x64_sys_call+0x271d/0x3e20 arch/x86/include/generated/asm/syscalls_64.h:51<br /> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]<br /> do_syscall_64+0xd9/0x210 arch/x86/entry/syscall_64.c:94<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> Local variable addr.i.i created at:<br /> sctp_get_port net/sctp/socket.c:8515 [inline]<br /> sctp_listen_start net/sctp/socket.c:8567 [inline]<br /> sctp_inet_listen+0x650/0xfd0 net/sctp/socket.c:8636<br /> __sys_listen_socket net/socket.c:1912 [inline]<br /> __sys_listen net/socket.c:1927 [inline]<br /> __do_sys_listen net/socket.c:1932 [inline]<br /> __se_sys_listen net/socket.c:1930 [inline]<br /> __x64_sys_listen+0x343/0x4c0 net/socket.c:1930