Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> HID: asus: fix UAF via HID_CLAIMED_INPUT validation<br /> <br /> After hid_hw_start() is called hidinput_connect() will eventually be<br /> called to set up the device with the input layer since the<br /> HID_CONNECT_DEFAULT connect mask is used. During hidinput_connect()<br /> all input and output reports are processed and corresponding hid_inputs<br /> are allocated and configured via hidinput_configure_usages(). This<br /> process involves slot tagging report fields and configuring usages<br /> by setting relevant bits in the capability bitmaps. However it is possible<br /> that the capability bitmaps are not set at all leading to the subsequent<br /> hidinput_has_been_populated() check to fail leading to the freeing of the<br /> hid_input and the underlying input device.<br /> <br /> This becomes problematic because a malicious HID device like a<br /> ASUS ROG N-Key keyboard can trigger the above scenario via a<br /> specially crafted descriptor which then leads to a user-after-free<br /> when the name of the freed input device is written to later on after<br /> hid_hw_start(). Below, report 93 intentionally utilises the<br /> HID_UP_UNDEFINED Usage Page which is skipped during usage<br /> configuration, leading to the frees.<br /> <br /> 0x05, 0x0D, // Usage Page (Digitizer)<br /> 0x09, 0x05, // Usage (Touch Pad)<br /> 0xA1, 0x01, // Collection (Application)<br /> 0x85, 0x0D, // Report ID (13)<br /> 0x06, 0x00, 0xFF, // Usage Page (Vendor Defined 0xFF00)<br /> 0x09, 0xC5, // Usage (0xC5)<br /> 0x15, 0x00, // Logical Minimum (0)<br /> 0x26, 0xFF, 0x00, // Logical Maximum (255)<br /> 0x75, 0x08, // Report Size (8)<br /> 0x95, 0x04, // Report Count (4)<br /> 0xB1, 0x02, // Feature (Data,Var,Abs)<br /> 0x85, 0x5D, // Report ID (93)<br /> 0x06, 0x00, 0x00, // Usage Page (Undefined)<br /> 0x09, 0x01, // Usage (0x01)<br /> 0x15, 0x00, // Logical Minimum (0)<br /> 0x26, 0xFF, 0x00, // Logical Maximum (255)<br /> 0x75, 0x08, // Report Size (8)<br /> 0x95, 0x1B, // Report Count (27)<br /> 0x81, 0x02, // Input (Data,Var,Abs)<br /> 0xC0, // End Collection<br /> <br /> Below is the KASAN splat after triggering the UAF:<br /> <br /> [ 21.672709] ==================================================================<br /> [ 21.673700] BUG: KASAN: slab-use-after-free in asus_probe+0xeeb/0xf80<br /> [ 21.673700] Write of size 8 at addr ffff88810a0ac000 by task kworker/1:2/54<br /> [ 21.673700]<br /> [ 21.673700] CPU: 1 UID: 0 PID: 54 Comm: kworker/1:2 Not tainted 6.16.0-rc4-g9773391cf4dd-dirty #36 PREEMPT(voluntary)<br /> [ 21.673700] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014<br /> [ 21.673700] Call Trace:<br /> [ 21.673700] <br /> [ 21.673700] dump_stack_lvl+0x5f/0x80<br /> [ 21.673700] print_report+0xd1/0x660<br /> [ 21.673700] kasan_report+0xe5/0x120<br /> [ 21.673700] __asan_report_store8_noabort+0x1b/0x30<br /> [ 21.673700] asus_probe+0xeeb/0xf80<br /> [ 21.673700] hid_device_probe+0x2ee/0x700<br /> [ 21.673700] really_probe+0x1c6/0x6b0<br /> [ 21.673700] __driver_probe_device+0x24f/0x310<br /> [ 21.673700] driver_probe_device+0x4e/0x220<br /> [...]<br /> [ 21.673700]<br /> [ 21.673700] Allocated by task 54:<br /> [ 21.673700] kasan_save_stack+0x3d/0x60<br /> [ 21.673700] kasan_save_track+0x18/0x40<br /> [ 21.673700] kasan_save_alloc_info+0x3b/0x50<br /> [ 21.673700] __kasan_kmalloc+0x9c/0xa0<br /> [ 21.673700] __kmalloc_cache_noprof+0x139/0x340<br /> [ 21.673700] input_allocate_device+0x44/0x370<br /> [ 21.673700] hidinput_connect+0xcb6/0x2630<br /> [ 21.673700] hid_connect+0xf74/0x1d60<br /> [ 21.673700] hid_hw_start+0x8c/0x110<br /> [ 21.673700] asus_probe+0x5a3/0xf80<br /> [ 21.673700] hid_device_probe+0x2ee/0x700<br /> [ 21.673700] really_probe+0x1c6/0x6b0<br /> [ 21.673700] __driver_probe_device+0x24f/0x310<br /> [ 21.673700] driver_probe_device+0x4e/0x220<br /> [...]<br /> [ 21.673700]<br /> [ 21.673700] Freed by task 54:<br /> [ 21.673700] kasan_save_stack+0x3d/0x60<br /> [ 21.673700] kasan_save_track+0x18/0x40<br /> [ 21.673700] kasan_save_free_info+0x3f/0x60<br /> [ 21.673700] __kasan_slab_free+0x3c/0x50<br /> [ 21.673700] kfre<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: x86: use array_index_nospec with indices that come from guest<br /> <br /> min and dest_id are guest-controlled indices. Using array_index_nospec()<br /> after the bounds checks clamps these values to mitigate speculative execution<br /> side-channels.

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:

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.

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/

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.

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.

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.

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.

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.

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().

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.