Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vsock/virtio: fix empty payload in tap skb for non-linear buffers<br /> <br /> For non-linear skbs, virtio_transport_build_skb() goes through<br /> virtio_transport_copy_nonlinear_skb() to copy the original payload<br /> in the new skb to be delivered to the vsockmon tap device.<br /> This manually initializes an iov_iter but does not set iov_iter.count.<br /> Since the iov_iter is zero-initialized, the copy length is zero and no<br /> payload is actually copied to the monitor interface, leaving data<br /> un-initialized.<br /> <br /> Fix this by removing the linear vs non-linear split and using<br /> skb_copy_datagram_iter() with iov_iter_kvec() for all cases, as<br /> vhost-vsock already does. This handles both linear and non-linear skbs,<br /> properly initializes the iov_iter, and removes the now unused<br /> virtio_transport_copy_nonlinear_skb().<br /> <br /> While touching this code, let&amp;#39;s also check the return value of<br /> skb_copy_datagram_iter(), even though it&amp;#39;s unlikely to fail.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> batman-adv: reject new tp_meter sessions during teardown<br /> <br /> Prevent tp_meter from starting new sender or receiver sessions after<br /> mesh_state has left BATADV_MESH_ACTIVE.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> staging: media: atomisp: Disallow all private IOCTLs<br /> <br /> Disallow all private IOCTLs. These aren&amp;#39;t quite as safe as one could<br /> assume of IOCTL handlers; disable them for now. Instead of removing the<br /> code, return in the beginning of the function if cmd is non-zero in order<br /> to keep static checkers happy.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> batman-adv: stop tp_meter sessions during mesh teardown<br /> <br /> TP meter sessions remain linked on bat_priv-&gt;tp_list after the netlink<br /> request has already finished. When the mesh interface is removed,<br /> batadv_mesh_free() currently tears down the mesh without first draining<br /> these sessions.<br /> <br /> A running sender thread or a late incoming tp_meter packet can then keep<br /> processing against a mesh instance which is already shutting down.<br /> Synchronize tp_meter with the mesh lifetime by stopping all active<br /> sessions from batadv_mesh_free() and waiting for sender threads to exit<br /> before teardown continues.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdkfd: validate SVM ioctl nattr against buffer size<br /> <br /> Validate nattr field against the buffer size, preventing<br /> out-of-bounds buffer access via user-controlled attribute count.<br /> <br /> (cherry picked from commit 5eca8bfdfa456c3304ca77523718fe24254c172f)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> batman-adv: fix integer overflow on buff_pos<br /> <br /> Fixing an integer overflow present in batadv_iv_ogm_send_to_if. The size<br /> check is done using the int type in batadv_iv_ogm_aggr_packet whereas the<br /> buff_pos variable uses the s16 type. This could lead to an out-of-bound<br /> read.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu/vcn4: Prevent OOB reads when parsing dec msg<br /> <br /> Check bounds against the end of the BO whenever we access the msg.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> spi: mpc52xx: fix controller deregistration<br /> <br /> Make sure to deregister the controller before disabling and releasing<br /> underlying resources like interrupts and gpios during driver unbind.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/xe: Fix dma-buf attachment leak in xe_gem_prime_import()<br /> <br /> When xe_dma_buf_init_obj() fails, the attachment from<br /> dma_buf_dynamic_attach() is not detached. Add dma_buf_detach() before<br /> returning the error. Note: we cannot use goto out_err here because<br /> xe_dma_buf_init_obj() already frees bo on failure, and out_err would<br /> double-free it.<br /> <br /> (cherry picked from commit a828eb185aac41800df8eae4b60501ccc0dbbe51)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> HID: appletb-kbd: run inactivity autodim from workqueues<br /> <br /> The autodim code in hid-appletb-kbd takes backlight_device-&gt;ops_lock<br /> via backlight_device_set_brightness() -&gt; mutex_lock() from two<br /> different atomic contexts:<br /> <br /> * appletb_inactivity_timer() is a struct timer_list callback, so it<br /> runs in softirq context. Every expiry triggers<br /> <br /> BUG: sleeping function called from invalid context at kernel/locking/mutex.c:591<br /> Call Trace:<br /> <br /> __might_resched<br /> __mutex_lock<br /> backlight_device_set_brightness<br /> appletb_inactivity_timer<br /> call_timer_fn<br /> run_timer_softirq<br /> <br /> * reset_inactivity_timer() is called from appletb_kbd_hid_event() and<br /> appletb_kbd_inp_event(). On real USB hardware these run in<br /> softirq/IRQ context (URB completion and input-event dispatch).<br /> When the Touch Bar has already been dimmed or turned off, the<br /> reset path calls backlight_device_set_brightness() directly to<br /> restore brightness, producing the same warning.<br /> <br /> Both call sites hit the same mutex_lock()-from-atomic bug. Fix them<br /> together by moving the blocking work onto the system workqueue:<br /> <br /> * Convert the inactivity timer from struct timer_list to<br /> struct delayed_work; the callback (appletb_inactivity_work) now<br /> runs in process context where mutex_lock() is legal.<br /> * Add a dedicated struct work_struct restore_brightness_work and have<br /> reset_inactivity_timer() schedule it instead of calling<br /> backlight_device_set_brightness() directly.<br /> <br /> Cancel both works synchronously during driver tear-down alongside the<br /> existing backlight reference drop.<br /> <br /> The semantics are unchanged (same delays, same state transitions on<br /> dim, turn-off and user activity); only the execution context of the<br /> sleeping call changes. The timer field and callback are renamed to<br /> match their new type; reset_inactivity_timer() keeps its name because<br /> it is invoked from input event paths that read naturally as "reset<br /> the inactivity timer".

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: fix node_cnt race between extent node destroy and writeback<br /> <br /> f2fs_destroy_extent_node() does not set FI_NO_EXTENT before clearing<br /> extent nodes. When called from f2fs_drop_inode() with I_SYNC set,<br /> concurrent kworker writeback can insert new extent nodes into the same<br /> extent tree, racing with the destroy and triggering f2fs_bug_on() in<br /> __destroy_extent_node(). The scenario is as follows:<br /> <br /> drop inode writeback<br /> - iput<br /> - f2fs_drop_inode // I_SYNC set<br /> - f2fs_destroy_extent_node<br /> - __destroy_extent_node<br /> - while (node_cnt) {<br /> write_lock(&amp;et-&gt;lock)<br /> __free_extent_tree<br /> write_unlock(&amp;et-&gt;lock)<br /> - __writeback_single_inode<br /> - f2fs_outplace_write_data<br /> - f2fs_update_read_extent_cache<br /> - __update_extent_tree_range<br /> // FI_NO_EXTENT not set,<br /> // insert new extent node<br /> } // node_cnt == 0, exit while<br /> - f2fs_bug_on(node_cnt) // node_cnt &gt; 0<br /> <br /> Additionally, __update_extent_tree_range() only checks FI_NO_EXTENT for<br /> EX_READ type, leaving EX_BLOCK_AGE updates completely unprotected.<br /> <br /> This patch set FI_NO_EXTENT under et-&gt;lock in __destroy_extent_node(),<br /> consistent with other callers (__update_extent_tree_range and<br /> __drop_extent_tree) and check FI_NO_EXTENT for both EX_READ and<br /> EX_BLOCK_AGE tree.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tracepoint: balance regfunc() on func_add() failure in tracepoint_add_func()<br /> <br /> When a tracepoint goes through the 0 -&gt; 1 transition, tracepoint_add_func()<br /> invokes the subsystem&amp;#39;s ext-&gt;regfunc() before attempting to install the<br /> new probe via func_add(). If func_add() then fails (for example, when<br /> allocate_probes() cannot allocate a new probe array under memory pressure<br /> and returns -ENOMEM), the function returns the error without calling the<br /> matching ext-&gt;unregfunc(), leaving the side effects of regfunc() behind<br /> with no installed probe to justify them.<br /> <br /> For syscall tracepoints this is particularly unpleasant: syscall_regfunc()<br /> bumps sys_tracepoint_refcount and sets SYSCALL_TRACEPOINT on every task.<br /> After a leaked failure, the refcount is stuck at a non-zero value with no<br /> consumer, and every task continues paying the syscall trace entry/exit<br /> overhead until reboot. Other subsystems providing regfunc()/unregfunc()<br /> pairs exhibit similarly scoped persistent state.<br /> <br /> Mirror the existing 1 -&gt; 0 cleanup and call ext-&gt;unregfunc() in the<br /> func_add() error path, gated on the same condition used there so the<br /> unwind is symmetric with the registration.