Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> HID: appletb-kbd: fix UAF in inactivity-timer cleanup path<br /> <br /> Commit 38224c472a03 ("HID: appletb-kbd: fix slab use-after-free bug in<br /> appletb_kbd_probe") added timer_delete_sync(&amp;kbd-&gt;inactivity_timer) to<br /> both the probe close_hw error path and appletb_kbd_remove(), but the<br /> way it was wired in left the inactivity timer reachable during driver<br /> tear-down via two distinct windows.<br /> <br /> Window A -- put_device() before timer_delete_sync():<br /> <br /> put_device(&amp;kbd-&gt;backlight_dev-&gt;dev);<br /> timer_delete_sync(&amp;kbd-&gt;inactivity_timer);<br /> <br /> The inactivity_timer softirq reads kbd-&gt;backlight_dev and calls<br /> backlight_device_set_brightness() -&gt; mutex_lock(&amp;ops_lock). If a<br /> concurrent hid_appletb_bl unbind drops the last devm reference<br /> between these two calls, the backlight_device is freed and the<br /> mutex_lock() touches freed memory.<br /> <br /> Window B -- backlight cleanup before hid_hw_stop():<br /> <br /> if (kbd-&gt;backlight_dev) {<br /> timer_delete_sync(...);<br /> put_device(...);<br /> }<br /> hid_hw_close(hdev);<br /> hid_hw_stop(hdev);<br /> <br /> Even after Window A is closed, hid_hw_close()/hid_hw_stop() still run<br /> afterwards, so a late ".event" callback from the HID core (USB URB<br /> completion on real Apple hardware) can arrive after<br /> timer_delete_sync() drained the softirq but before put_device() drops<br /> the reference. That callback reaches reset_inactivity_timer(), which<br /> calls mod_timer() and re-arms the timer. The freshly re-armed timer<br /> can then fire on the about-to-be-freed backlight_device.<br /> <br /> Both windows produce the same KASAN slab-use-after-free:<br /> <br /> BUG: KASAN: slab-use-after-free in __mutex_lock+0x1aab/0x21c0<br /> Read of size 8 at addr ffff88803ee9a108 by task swapper/0/0<br /> Call Trace:<br /> <br /> __mutex_lock<br /> backlight_device_set_brightness<br /> appletb_inactivity_timer<br /> call_timer_fn<br /> run_timer_softirq<br /> handle_softirqs<br /> Allocated by task N:<br /> devm_backlight_device_register<br /> appletb_bl_probe<br /> Freed by task M:<br /> (concurrent hid_appletb_bl unbind path)<br /> <br /> Close both windows at once by reworking the tear-down in<br /> appletb_kbd_remove() and in the probe close_hw error path so that<br /> <br /> 1) hid_hw_close()/hid_hw_stop() run before the backlight cleanup,<br /> guaranteeing no further .event callback can fire and re-arm the<br /> timer, and<br /> 2) inside the "if (kbd-&gt;backlight_dev)" block, timer_delete_sync()<br /> runs before put_device(), so the softirq is drained before the<br /> final reference is dropped.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu/vcn4: Prevent OOB reads when parsing IB<br /> <br /> Rewrite the IB parsing to use amdgpu_ib_get_value() which handles the<br /> bounds checks.

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: 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 /> 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/gem: Fix inconsistent plane dimension calculation in drm_gem_fb_init_with_funcs()<br /> <br /> drm_gem_fb_init_with_funcs() computes sub-sampled plane dimensions<br /> using plain integer division:<br /> <br /> unsigned int width = mode_cmd-&gt;width / (i ? info-&gt;hsub : 1);<br /> unsigned int height = mode_cmd-&gt;height / (i ? info-&gt;vsub : 1);<br /> <br /> However, the ioctl-level framebuffer_check() in drm_framebuffer.c uses<br /> drm_format_info_plane_width/height() which round up dimensions via<br /> DIV_ROUND_UP(). This inconsistency corrupts the subsequent GEM object<br /> size check for certain pixel format and dimension combinations.<br /> <br /> For example, with NV12 (vsub=2) and a 1-pixel-tall framebuffer the<br /> GEM size validation path sees height=0 instead of height=1. The<br /> expression (height - 1) then wraps to UINT_MAX as an unsigned int,<br /> causing min_size to overflow and wrap back to a small value. A tiny<br /> GEM object therefore passes the size guard, yet when the GPU accesses<br /> the chroma plane it will read or write memory beyond the object&amp;#39;s<br /> bounds.<br /> <br /> Fix by replacing the open-coded divisions with drm_format_info_plane_width()<br /> and drm_format_info_plane_height(), which use DIV_ROUND_UP() and match<br /> the calculation already used in framebuffer_check().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: iris: fix use-after-free of fmt_src during MBPF check<br /> <br /> During concurrency testing, multiple instances can run in parallel, and<br /> each instance uses its own inst-&gt;lock while the core-&gt;lock protects the<br /> list of active instances. The race happens because these locks cover<br /> different scopes, inst-&gt;lock protects only the internals of a single<br /> instance, while the Macro Blocks Per Frame (MBPF) checker walks the<br /> core list under core-&gt;lock and reads fields like fmt_src-&gt;width and<br /> fmt_src-&gt;height. At the same time, iris_close() may free fmt_src and<br /> fmt_dst under inst-&gt;lock while the instance is still present in the core<br /> list. This allows a situation where the MBPF checker, still iterating<br /> through the core list, reaches an instance whose fmt_src was already<br /> freed by another thread and ends up dereferencing a dangling pointer,<br /> resulting in a use-after-free. This happens because the MBPF checker<br /> assumes that any instance in the core list is fully valid, but the<br /> freeing of fmt_src and fmt_dst without removing the instance from the<br /> core list is not correct.<br /> <br /> The correct ordering is to defer freeing fmt_src and fmt_dst until after<br /> the instance has been removed from the core list and all teardown under<br /> the core lock has completed, ensuring that no dangling pointers are ever<br /> exposed during MBPF checks.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> batman-adv: bla: prevent use-after-free when deleting claims<br /> <br /> When batadv_bla_del_backbone_claims() removes all claims for a backbone, it<br /> does this by dropping the link entry in the hash list. This list entry<br /> itself was one of the references which need to be dropped at the same time<br /> via batadv_claim_put().<br /> <br /> But the batadv_claim_put() must not be done before the last access to the<br /> claim object in this function. Otherwise the claim might be freed already<br /> by the batadv_claim_release() function before the list entry was dropped.

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.

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 /> 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".