Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> i3c: master: Fix miss free init_dyn_addr at i3c_master_put_i3c_addrs()<br /> <br /> if (dev-&gt;boardinfo &amp;&amp; dev-&gt;boardinfo-&gt;init_dyn_addr)<br /> ^^^ here check "init_dyn_addr"<br /> i3c_bus_set_addr_slot_status(&amp;master-&gt;bus, dev-&gt;info.dyn_addr, ...)<br /> ^^^^<br /> free "dyn_addr"<br /> Fix copy/paste error "dyn_addr" by replacing it with "init_dyn_addr".

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ad7780: fix division by zero in ad7780_write_raw()<br /> <br /> In the ad7780_write_raw() , val2 can be zero, which might lead to a<br /> division by zero error in DIV_ROUND_CLOSEST(). The ad7780_write_raw()<br /> is based on iio_info&amp;#39;s write_raw. While val is explicitly declared that<br /> can be zero (in read mode), val2 is not specified to be non-zero.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommu/arm-smmu: Defer probe of clients after smmu device bound<br /> <br /> Null pointer dereference occurs due to a race between smmu<br /> driver probe and client driver probe, when of_dma_configure()<br /> for client is called after the iommu_device_register() for smmu driver<br /> probe has executed but before the driver_bound() for smmu driver<br /> has been called.<br /> <br /> Following is how the race occurs:<br /> <br /> T1:Smmu device probe T2: Client device probe<br /> <br /> really_probe()<br /> arm_smmu_device_probe()<br /> iommu_device_register()<br /> really_probe()<br /> platform_dma_configure()<br /> of_dma_configure()<br /> of_dma_configure_id()<br /> of_iommu_configure()<br /> iommu_probe_device()<br /> iommu_init_device()<br /> arm_smmu_probe_device()<br /> arm_smmu_get_by_fwnode()<br /> driver_find_device_by_fwnode()<br /> driver_find_device()<br /> next_device()<br /> klist_next()<br /> /* null ptr<br /> assigned to smmu */<br /> /* null ptr dereference<br /> while smmu-&gt;streamid_mask */<br /> driver_bound()<br /> klist_add_tail()<br /> <br /> When this null smmu pointer is dereferenced later in<br /> arm_smmu_probe_device, the device crashes.<br /> <br /> Fix this by deferring the probe of the client device<br /> until the smmu device has bound to the arm smmu driver.<br /> <br /> [will: Add comment]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ftrace: Fix regression with module command in stack_trace_filter<br /> <br /> When executing the following command:<br /> <br /> # echo "write*:mod:ext3" &gt; /sys/kernel/tracing/stack_trace_filter<br /> <br /> The current mod command causes a null pointer dereference. While commit<br /> 0f17976568b3f ("ftrace: Fix regression with module command in stack_trace_filter")<br /> has addressed part of the issue, it left a corner case unhandled, which still<br /> results in a kernel crash.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ovl: Filter invalid inodes with missing lookup function<br /> <br /> Add a check to the ovl_dentry_weird() function to prevent the<br /> processing of directory inodes that lack the lookup function.<br /> This is important because such inodes can cause errors in overlayfs<br /> when passed to the lowerstack.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> binder: fix memleak of proc-&gt;delivered_freeze<br /> <br /> If a freeze notification is cleared with BC_CLEAR_FREEZE_NOTIFICATION<br /> before calling binder_freeze_notification_done(), then it is detached<br /> from its reference (e.g. ref-&gt;freeze) but the work remains queued in<br /> proc-&gt;delivered_freeze. This leads to a memory leak when the process<br /> exits as any pending entries in proc-&gt;delivered_freeze are not freed:<br /> <br /> unreferenced object 0xffff38e8cfa36180 (size 64):<br /> comm "binder-util", pid 655, jiffies 4294936641<br /> hex dump (first 32 bytes):<br /> b8 e9 9e c8 e8 38 ff ff b8 e9 9e c8 e8 38 ff ff .....8.......8..<br /> 0b 00 00 00 00 00 00 00 3c 1f 4b 00 00 00 00 00 ........delivered_freeze are freed during binder_deferred_release().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> binder: fix freeze UAF in binder_release_work()<br /> <br /> When a binder reference is cleaned up, any freeze work queued in the<br /> associated process should also be removed. Otherwise, the reference is<br /> freed while its ref-&gt;freeze.work is still queued in proc-&gt;work leading<br /> to a use-after-free issue as shown by the following KASAN report:<br /> <br /> ==================================================================<br /> BUG: KASAN: slab-use-after-free in binder_release_work+0x398/0x3d0<br /> Read of size 8 at addr ffff31600ee91488 by task kworker/5:1/211<br /> <br /> CPU: 5 UID: 0 PID: 211 Comm: kworker/5:1 Not tainted 6.11.0-rc7-00382-gfc6c92196396 #22<br /> Hardware name: linux,dummy-virt (DT)<br /> Workqueue: events binder_deferred_func<br /> Call trace:<br /> binder_release_work+0x398/0x3d0<br /> binder_deferred_func+0xb60/0x109c<br /> process_one_work+0x51c/0xbd4<br /> worker_thread+0x608/0xee8<br /> <br /> Allocated by task 703:<br /> __kmalloc_cache_noprof+0x130/0x280<br /> binder_thread_write+0xdb4/0x42a0<br /> binder_ioctl+0x18f0/0x25ac<br /> __arm64_sys_ioctl+0x124/0x190<br /> invoke_syscall+0x6c/0x254<br /> <br /> Freed by task 211:<br /> kfree+0xc4/0x230<br /> binder_deferred_func+0xae8/0x109c<br /> process_one_work+0x51c/0xbd4<br /> worker_thread+0x608/0xee8<br /> ==================================================================<br /> <br /> This commit fixes the issue by ensuring any queued freeze work is removed<br /> when cleaning up a binder reference.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> binder: fix OOB in binder_add_freeze_work()<br /> <br /> In binder_add_freeze_work() we iterate over the proc-&gt;nodes with the<br /> proc-&gt;inner_lock held. However, this lock is temporarily dropped to<br /> acquire the node-&gt;lock first (lock nesting order). This can race with<br /> binder_deferred_release() which removes the nodes from the proc-&gt;nodes<br /> rbtree and adds them into binder_dead_nodes list. This leads to a broken<br /> iteration in binder_add_freeze_work() as rb_next() will use data from<br /> binder_dead_nodes, triggering an out-of-bounds access:<br /> <br /> ==================================================================<br /> BUG: KASAN: global-out-of-bounds in rb_next+0xfc/0x124<br /> Read of size 8 at addr ffffcb84285f7170 by task freeze/660<br /> <br /> CPU: 8 UID: 0 PID: 660 Comm: freeze Not tainted 6.11.0-07343-ga727812a8d45 #18<br /> Hardware name: linux,dummy-virt (DT)<br /> Call trace:<br /> rb_next+0xfc/0x124<br /> binder_add_freeze_work+0x344/0x534<br /> binder_ioctl+0x1e70/0x25ac<br /> __arm64_sys_ioctl+0x124/0x190<br /> <br /> The buggy address belongs to the variable:<br /> binder_dead_nodes+0x10/0x40<br /> [...]<br /> ==================================================================<br /> <br /> This is possible because proc-&gt;nodes (rbtree) and binder_dead_nodes<br /> (list) share entries in binder_node through a union:<br /> <br /> struct binder_node {<br /> [...]<br /> union {<br /> struct rb_node rb_node;<br /> struct hlist_node dead_node;<br /> };<br /> <br /> Fix the race by checking that the proc is still alive. If not, simply<br /> break out of the iteration.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> binder: fix node UAF in binder_add_freeze_work()<br /> <br /> In binder_add_freeze_work() we iterate over the proc-&gt;nodes with the<br /> proc-&gt;inner_lock held. However, this lock is temporarily dropped in<br /> order to acquire the node-&gt;lock first (lock nesting order). This can<br /> race with binder_node_release() and trigger a use-after-free:<br /> <br /> ==================================================================<br /> BUG: KASAN: slab-use-after-free in _raw_spin_lock+0xe4/0x19c<br /> Write of size 4 at addr ffff53c04c29dd04 by task freeze/640<br /> <br /> CPU: 5 UID: 0 PID: 640 Comm: freeze Not tainted 6.11.0-07343-ga727812a8d45 #17<br /> Hardware name: linux,dummy-virt (DT)<br /> Call trace:<br /> _raw_spin_lock+0xe4/0x19c<br /> binder_add_freeze_work+0x148/0x478<br /> binder_ioctl+0x1e70/0x25ac<br /> __arm64_sys_ioctl+0x124/0x190<br /> <br /> Allocated by task 637:<br /> __kmalloc_cache_noprof+0x12c/0x27c<br /> binder_new_node+0x50/0x700<br /> binder_transaction+0x35ac/0x6f74<br /> binder_thread_write+0xfb8/0x42a0<br /> binder_ioctl+0x18f0/0x25ac<br /> __arm64_sys_ioctl+0x124/0x190<br /> <br /> Freed by task 637:<br /> kfree+0xf0/0x330<br /> binder_thread_read+0x1e88/0x3a68<br /> binder_ioctl+0x16d8/0x25ac<br /> __arm64_sys_ioctl+0x124/0x190<br /> ==================================================================<br /> <br /> Fix the race by taking a temporary reference on the node before<br /> releasing the proc-&gt;inner lock. This ensures the node remains alive<br /> while in use.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/vmalloc: combine all TLB flush operations of KASAN shadow virtual address into one operation<br /> <br /> When compiling kernel source &amp;#39;make -j $(nproc)&amp;#39; with the up-and-running<br /> KASAN-enabled kernel on a 256-core machine, the following soft lockup is<br /> shown:<br /> <br /> watchdog: BUG: soft lockup - CPU#28 stuck for 22s! [kworker/28:1:1760]<br /> CPU: 28 PID: 1760 Comm: kworker/28:1 Kdump: loaded Not tainted 6.10.0-rc5 #95<br /> Workqueue: events drain_vmap_area_work<br /> RIP: 0010:smp_call_function_many_cond+0x1d8/0xbb0<br /> Code: 38 c8 7c 08 84 c9 0f 85 49 08 00 00 8b 45 08 a8 01 74 2e 48 89 f1 49 89 f7 48 c1 e9 03 41 83 e7 07 4c 01 e9 41 83 c7 03 f3 90 b6 01 41 38 c7 7c 08 84 c0 0f 85 d4 06 00 00 8b 45 08 a8 01 75<br /> RSP: 0018:ffffc9000cb3fb60 EFLAGS: 00000202<br /> RAX: 0000000000000011 RBX: ffff8883bc4469c0 RCX: ffffed10776e9949<br /> RDX: 0000000000000002 RSI: ffff8883bb74ca48 RDI: ffffffff8434dc50<br /> RBP: ffff8883bb74ca40 R08: ffff888103585dc0 R09: ffff8884533a1800<br /> R10: 0000000000000004 R11: ffffffffffffffff R12: ffffed1077888d39<br /> R13: dffffc0000000000 R14: ffffed1077888d38 R15: 0000000000000003<br /> FS: 0000000000000000(0000) GS:ffff8883bc400000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00005577b5c8d158 CR3: 0000000004850000 CR4: 0000000000350ef0<br /> Call Trace:<br /> <br /> ? watchdog_timer_fn+0x2cd/0x390<br /> ? __pfx_watchdog_timer_fn+0x10/0x10<br /> ? __hrtimer_run_queues+0x300/0x6d0<br /> ? sched_clock_cpu+0x69/0x4e0<br /> ? __pfx___hrtimer_run_queues+0x10/0x10<br /> ? srso_return_thunk+0x5/0x5f<br /> ? ktime_get_update_offsets_now+0x7f/0x2a0<br /> ? srso_return_thunk+0x5/0x5f<br /> ? srso_return_thunk+0x5/0x5f<br /> ? hrtimer_interrupt+0x2ca/0x760<br /> ? __sysvec_apic_timer_interrupt+0x8c/0x2b0<br /> ? sysvec_apic_timer_interrupt+0x6a/0x90<br /> <br /> <br /> ? asm_sysvec_apic_timer_interrupt+0x16/0x20<br /> ? smp_call_function_many_cond+0x1d8/0xbb0<br /> ? __pfx_do_kernel_range_flush+0x10/0x10<br /> on_each_cpu_cond_mask+0x20/0x40<br /> flush_tlb_kernel_range+0x19b/0x250<br /> ? srso_return_thunk+0x5/0x5f<br /> ? kasan_release_vmalloc+0xa7/0xc0<br /> purge_vmap_node+0x357/0x820<br /> ? __pfx_purge_vmap_node+0x10/0x10<br /> __purge_vmap_area_lazy+0x5b8/0xa10<br /> drain_vmap_area_work+0x21/0x30<br /> process_one_work+0x661/0x10b0<br /> worker_thread+0x844/0x10e0<br /> ? srso_return_thunk+0x5/0x5f<br /> ? __kthread_parkme+0x82/0x140<br /> ? __pfx_worker_thread+0x10/0x10<br /> kthread+0x2a5/0x370<br /> ? __pfx_kthread+0x10/0x10<br /> ret_from_fork+0x30/0x70<br /> ? __pfx_kthread+0x10/0x10<br /> ret_from_fork_asm+0x1a/0x30<br /> <br /> <br /> Debugging Analysis:<br /> <br /> 1. The following ftrace log shows that the lockup CPU spends too much<br /> time iterating vmap_nodes and flushing TLB when purging vm_area<br /> structures. (Some info is trimmed).<br /> <br /> kworker: funcgraph_entry: | drain_vmap_area_work() {<br /> kworker: funcgraph_entry: | mutex_lock() {<br /> kworker: funcgraph_entry: 1.092 us | __cond_resched();<br /> kworker: funcgraph_exit: 3.306 us | }<br /> ... ...<br /> kworker: funcgraph_entry: | flush_tlb_kernel_range() {<br /> ... ...<br /> kworker: funcgraph_exit: # 7533.649 us | }<br /> ... ...<br /> kworker: funcgraph_entry: 2.344 us | mutex_unlock();<br /> kworker: funcgraph_exit: $ 23871554 us | }<br /> <br /> The drain_vmap_area_work() spends over 23 seconds.<br /> <br /> There are 2805 flush_tlb_kernel_range() calls in the ftrace log.<br /> * One is called in __purge_vmap_area_lazy().<br /> * Others are called by purge_vmap_node-&gt;kasan_release_vmalloc.<br /> purge_vmap_node() iteratively releases kasan vmalloc<br /> allocations and flushes TLB for each vmap_area.<br /> - [Rough calculation] Each flush_tlb_kernel_range() runs<br /> about 7.5ms.<br /> -- 2804 * 7.5ms = 21.03 seconds.<br /> -- That&amp;#39;s why a soft lock is triggered.<br /> <br /> 2. Extending the soft lockup time can work around the issue (For example,<br /> # echo<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> slab: Fix too strict alignment check in create_cache()<br /> <br /> On m68k, where the minimum alignment of unsigned long is 2 bytes:<br /> <br /> Kernel panic - not syncing: __kmem_cache_create_args: Failed to create slab &amp;#39;io_kiocb&amp;#39;. Error -22<br /> CPU: 0 UID: 0 PID: 1 Comm: swapper Not tainted 6.12.0-atari-03776-g7eaa1f99261a #1783<br /> Stack from 0102fe5c:<br /> 0102fe5c 00514a2b 00514a2b ffffff00 00000001 0051f5ed 00425e78 00514a2b<br /> 0041eb74 ffffffea 00000310 0051f5ed ffffffea ffffffea 00601f60 00000044<br /> 0102ff20 000e7a68 0051ab8e 004383b8 0051f5ed ffffffea 000000b8 00000007<br /> 01020c00 00000000 000e77f0 0041e5f0 005f67c0 0051f5ed 000000b6 0102fef4<br /> 00000310 0102fef4 00000000 00000016 005f676c 0060a34c 00000010 00000004<br /> 00000038 0000009a 01000000 000000b8 005f668e 0102e000 00001372 0102ff88<br /> Call Trace: [] dump_stack+0xc/0x10<br /> [] panic+0xd8/0x26c<br /> [] __kmem_cache_create_args+0x278/0x2e8<br /> [] __kmem_cache_create_args+0x0/0x2e8<br /> [] memset+0x0/0x8c<br /> [] io_uring_init+0x54/0xd2<br /> <br /> The minimal alignment of an integral type may differ from its size,<br /> hence is not safe to assume that an arbitrary freeptr_t (which is<br /> basically an unsigned long) is always aligned to 4 or 8 bytes.<br /> <br /> As nothing seems to require the additional alignment, it is safe to fix<br /> this by relaxing the check to the actual minimum alignment of freeptr_t.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> PCI: endpoint: Fix PCI domain ID release in pci_epc_destroy()<br /> <br /> pci_epc_destroy() invokes pci_bus_release_domain_nr() to release the PCI<br /> domain ID, but there are two issues:<br /> <br /> - &amp;#39;epc-&gt;dev&amp;#39; is passed to pci_bus_release_domain_nr() which was already<br /> freed by device_unregister(), leading to a use-after-free issue.<br /> <br /> - Domain ID corresponds to the EPC device parent, so passing &amp;#39;epc-&gt;dev&amp;#39;<br /> is also wrong.<br /> <br /> Fix these issues by passing &amp;#39;epc-&gt;dev.parent&amp;#39; to<br /> pci_bus_release_domain_nr() and also do it before device_unregister().<br /> <br /> [mani: reworded subject and description]