Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> interconnect: Don&amp;#39;t access req_list while it&amp;#39;s being manipulated<br /> <br /> The icc_lock mutex was split into separate icc_lock and icc_bw_lock<br /> mutexes in [1] to avoid lockdep splats. However, this didn&amp;#39;t adequately<br /> protect access to icc_node::req_list.<br /> <br /> The icc_set_bw() function will eventually iterate over req_list while<br /> only holding icc_bw_lock, but req_list can be modified while only<br /> holding icc_lock. This causes races between icc_set_bw(), of_icc_get(),<br /> and icc_put().<br /> <br /> Example A:<br /> <br /> CPU0 CPU1<br /> ---- ----<br /> icc_set_bw(path_a)<br /> mutex_lock(&amp;icc_bw_lock);<br /> icc_put(path_b)<br /> mutex_lock(&amp;icc_lock);<br /> aggregate_requests()<br /> hlist_for_each_entry(r, ...<br /> hlist_del(...<br /> <br /> <br /> Example B:<br /> <br /> CPU0 CPU1<br /> ---- ----<br /> icc_set_bw(path_a)<br /> mutex_lock(&amp;icc_bw_lock);<br /> path_b = of_icc_get()<br /> of_icc_get_by_index()<br /> mutex_lock(&amp;icc_lock);<br /> path_find()<br /> path_init()<br /> aggregate_requests()<br /> hlist_for_each_entry(r, ...<br /> hlist_add_head(...<br /> <br /> <br /> Fix this by ensuring icc_bw_lock is always held before manipulating<br /> icc_node::req_list. The additional places icc_bw_lock is held don&amp;#39;t<br /> perform any memory allocations, so we should still be safe from the<br /> original lockdep splats that motivated the separate locks.<br /> <br /> [1] commit af42269c3523 ("interconnect: Fix locking for runpm vs reclaim")

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs: sysfs: Fix reference leak in sysfs_break_active_protection()<br /> <br /> The sysfs_break_active_protection() routine has an obvious reference<br /> leak in its error path. If the call to kernfs_find_and_get() fails then<br /> kn will be NULL, so the companion sysfs_unbreak_active_protection()<br /> routine won&amp;#39;t get called (and would only cause an access violation by<br /> trying to dereference kn-&gt;parent if it was called). As a result, the<br /> reference to kobj acquired at the start of the function will never be<br /> released.<br /> <br /> Fix the leak by adding an explicit kobject_put() call when kn is NULL.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: typec: tcpm: Correct the PDO counting in pd_set<br /> <br /> Off-by-one errors happen because nr_snk_pdo and nr_src_pdo are<br /> incorrectly added one. The index of the loop is equal to the number of<br /> PDOs to be updated when leaving the loop and it doesn&amp;#39;t need to be added<br /> one.<br /> <br /> When doing the power negotiation, TCPM relies on the "nr_snk_pdo" as<br /> the size of the local sink PDO array to match the Source capabilities<br /> of the partner port. If the off-by-one overflow occurs, a wrong RDO<br /> might be sent and unexpected power transfer might happen such as over<br /> voltage or over current (than expected).<br /> <br /> "nr_src_pdo" is used to set the Rp level when the port is in Source<br /> role. It is also the array size of the local Source capabilities when<br /> filling up the buffer which will be sent as the Source PDOs (such as<br /> in Power Negotiation). If the off-by-one overflow occurs, a wrong Rp<br /> level might be set and wrong Source PDOs will be sent to the partner<br /> port. This could potentially cause over current or port resets.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: dwc2: host: Fix dereference issue in DDMA completion flow.<br /> <br /> Fixed variable dereference issue in DDMA completion flow.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> serial: core: Clearing the circular buffer before NULLifying it<br /> <br /> The circular buffer is NULLified in uart_tty_port_shutdown()<br /> under the spin lock. However, the PM or other timer based callbacks<br /> may still trigger after this event without knowning that buffer pointer<br /> is not valid. Since the serial code is a bit inconsistent in checking<br /> the buffer state (some rely on the head-tail positions, some on the<br /> buffer pointer), it&amp;#39;s better to have both aligned, i.e. buffer pointer<br /> to be NULL and head-tail possitions to be the same, meaning it&amp;#39;s empty.<br /> This will prevent asynchronous calls to dereference NULL pointer as<br /> reported recently in 8250 case:<br /> <br /> BUG: kernel NULL pointer dereference, address: 00000cf5<br /> Workqueue: pm pm_runtime_work<br /> EIP: serial8250_tx_chars (drivers/tty/serial/8250/8250_port.c:1809)<br /> ...<br /> ? serial8250_tx_chars (drivers/tty/serial/8250/8250_port.c:1809)<br /> __start_tx (drivers/tty/serial/8250/8250_port.c:1551)<br /> serial8250_start_tx (drivers/tty/serial/8250/8250_port.c:1654)<br /> serial_port_runtime_suspend (include/linux/serial_core.h:667 drivers/tty/serial/serial_port.c:63)<br /> __rpm_callback (drivers/base/power/runtime.c:393)<br /> ? serial_port_remove (drivers/tty/serial/serial_port.c:50)<br /> rpm_suspend (drivers/base/power/runtime.c:447)<br /> <br /> The proposed change will prevent -&gt;start_tx() to be called during<br /> suspend on shut down port.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> serial/pmac_zilog: Remove flawed mitigation for rx irq flood<br /> <br /> The mitigation was intended to stop the irq completely. That may be<br /> better than a hard lock-up but it turns out that you get a crash anyway<br /> if you&amp;#39;re using pmac_zilog as a serial console:<br /> <br /> ttyPZ0: pmz: rx irq flood !<br /> BUG: spinlock recursion on CPU#0, swapper/0<br /> <br /> That&amp;#39;s because the pr_err() call in pmz_receive_chars() results in<br /> pmz_console_write() attempting to lock a spinlock already locked in<br /> pmz_interrupt(). With CONFIG_DEBUG_SPINLOCK=y, this produces a fatal<br /> BUG splat. The spinlock in question is the one in struct uart_port.<br /> <br /> Even when it&amp;#39;s not fatal, the serial port rx function ceases to work.<br /> Also, the iteration limit doesn&amp;#39;t play nicely with QEMU, as can be<br /> seen in the bug report linked below.<br /> <br /> A web search for other reports of the error message "pmz: rx irq flood"<br /> didn&amp;#39;t produce anything. So I don&amp;#39;t think this code is needed any more.<br /> Remove it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> speakup: Avoid crash on very long word<br /> <br /> In case a console is set up really large and contains a really long word<br /> (&gt; 256 characters), we have to stop before the length of the word buffer.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: gadget: f_ncm: Fix UAF ncm object at re-bind after usb ep transport error<br /> <br /> When ncm function is working and then stop usb0 interface for link down,<br /> eth_stop() is called. At this piont, accidentally if usb transport error<br /> should happen in usb_ep_enable(), &amp;#39;in_ep&amp;#39; and/or &amp;#39;out_ep&amp;#39; may not be enabled.<br /> <br /> After that, ncm_disable() is called to disable for ncm unbind<br /> but gether_disconnect() is never called since &amp;#39;in_ep&amp;#39; is not enabled.<br /> <br /> As the result, ncm object is released in ncm unbind<br /> but &amp;#39;dev-&gt;port_usb&amp;#39; associated to &amp;#39;ncm-&gt;port&amp;#39; is not NULL.<br /> <br /> And when ncm bind again to recover netdev, ncm object is reallocated<br /> but usb0 interface is already associated to previous released ncm object.<br /> <br /> Therefore, once usb0 interface is up and eth_start_xmit() is called,<br /> released ncm object is dereferrenced and it might cause use-after-free memory.<br /> <br /> [function unlink via configfs]<br /> usb0: eth_stop dev-&gt;port_usb=ffffff9b179c3200<br /> --&gt; error happens in usb_ep_enable().<br /> NCM: ncm_disable: ncm=ffffff9b179c3200<br /> --&gt; no gether_disconnect() since ncm-&gt;port.in_ep-&gt;enabled is false.<br /> NCM: ncm_unbind: ncm unbind ncm=ffffff9b179c3200<br /> NCM: ncm_free: ncm free ncm=ffffff9b179c3200 port_usb=ffffff9b179c3200 port_usb=ffffff9b179c3200 dev-&gt;wrap()<br /> Unable to handle kernel paging request at virtual address dead00000000014f<br /> <br /> This patch addresses the issue by checking if &amp;#39;ncm-&gt;netdev&amp;#39; is not NULL at<br /> ncm_disable() to call gether_disconnect() to deassociate &amp;#39;dev-&gt;port_usb&amp;#39;.<br /> It&amp;#39;s more reasonable to check &amp;#39;ncm-&gt;netdev&amp;#39; to call gether_connect/disconnect<br /> rather than check &amp;#39;ncm-&gt;port.in_ep-&gt;enabled&amp;#39; since it might not be enabled<br /> but the gether connection might be established.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/xe: Fix bo leak in intel_fb_bo_framebuffer_init<br /> <br /> Add a unreference bo in the error path, to prevent leaking a bo ref.<br /> <br /> Return 0 on success to clarify the success path.<br /> <br /> (cherry picked from commit a2f3d731be3893e730417ae3190760fcaffdf549)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdkfd: Fix memory leak in create_process failure<br /> <br /> Fix memory leak due to a leaked mmget reference on an error handling<br /> code path that is triggered when attempting to create KFD processes<br /> while a GPU reset is in progress.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/memory-failure: fix deadlock when hugetlb_optimize_vmemmap is enabled<br /> <br /> When I did hard offline test with hugetlb pages, below deadlock occurs:<br /> <br /> ======================================================<br /> WARNING: possible circular locking dependency detected<br /> 6.8.0-11409-gf6cef5f8c37f #1 Not tainted<br /> ------------------------------------------------------<br /> bash/46904 is trying to acquire lock:<br /> ffffffffabe68910 (cpu_hotplug_lock){++++}-{0:0}, at: static_key_slow_dec+0x16/0x60<br /> <br /> but task is already holding lock:<br /> ffffffffabf92ea8 (pcp_batch_high_lock){+.+.}-{3:3}, at: zone_pcp_disable+0x16/0x40<br /> <br /> which lock already depends on the new lock.<br /> <br /> the existing dependency chain (in reverse order) is:<br /> <br /> -&gt; #1 (pcp_batch_high_lock){+.+.}-{3:3}:<br /> __mutex_lock+0x6c/0x770<br /> page_alloc_cpu_online+0x3c/0x70<br /> cpuhp_invoke_callback+0x397/0x5f0<br /> __cpuhp_invoke_callback_range+0x71/0xe0<br /> _cpu_up+0xeb/0x210<br /> cpu_up+0x91/0xe0<br /> cpuhp_bringup_mask+0x49/0xb0<br /> bringup_nonboot_cpus+0xb7/0xe0<br /> smp_init+0x25/0xa0<br /> kernel_init_freeable+0x15f/0x3e0<br /> kernel_init+0x15/0x1b0<br /> ret_from_fork+0x2f/0x50<br /> ret_from_fork_asm+0x1a/0x30<br /> <br /> -&gt; #0 (cpu_hotplug_lock){++++}-{0:0}:<br /> __lock_acquire+0x1298/0x1cd0<br /> lock_acquire+0xc0/0x2b0<br /> cpus_read_lock+0x2a/0xc0<br /> static_key_slow_dec+0x16/0x60<br /> __hugetlb_vmemmap_restore_folio+0x1b9/0x200<br /> dissolve_free_huge_page+0x211/0x260<br /> __page_handle_poison+0x45/0xc0<br /> memory_failure+0x65e/0xc70<br /> hard_offline_page_store+0x55/0xa0<br /> kernfs_fop_write_iter+0x12c/0x1d0<br /> vfs_write+0x387/0x550<br /> ksys_write+0x64/0xe0<br /> do_syscall_64+0xca/0x1e0<br /> entry_SYSCALL_64_after_hwframe+0x6d/0x75<br /> <br /> other info that might help us debug this:<br /> <br /> Possible unsafe locking scenario:<br /> <br /> CPU0 CPU1<br /> ---- ----<br /> lock(pcp_batch_high_lock);<br /> lock(cpu_hotplug_lock);<br /> lock(pcp_batch_high_lock);<br /> rlock(cpu_hotplug_lock);<br /> <br /> *** DEADLOCK ***<br /> <br /> 5 locks held by bash/46904:<br /> #0: ffff98f6c3bb23f0 (sb_writers#5){.+.+}-{0:0}, at: ksys_write+0x64/0xe0<br /> #1: ffff98f6c328e488 (&amp;of-&gt;mutex){+.+.}-{3:3}, at: kernfs_fop_write_iter+0xf8/0x1d0<br /> #2: ffff98ef83b31890 (kn-&gt;active#113){.+.+}-{0:0}, at: kernfs_fop_write_iter+0x100/0x1d0<br /> #3: ffffffffabf9db48 (mf_mutex){+.+.}-{3:3}, at: memory_failure+0x44/0xc70<br /> #4: ffffffffabf92ea8 (pcp_batch_high_lock){+.+.}-{3:3}, at: zone_pcp_disable+0x16/0x40<br /> <br /> stack backtrace:<br /> CPU: 10 PID: 46904 Comm: bash Kdump: loaded Not tainted 6.8.0-11409-gf6cef5f8c37f #1<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x68/0xa0<br /> check_noncircular+0x129/0x140<br /> __lock_acquire+0x1298/0x1cd0<br /> lock_acquire+0xc0/0x2b0<br /> cpus_read_lock+0x2a/0xc0<br /> static_key_slow_dec+0x16/0x60<br /> __hugetlb_vmemmap_restore_folio+0x1b9/0x200<br /> dissolve_free_huge_page+0x211/0x260<br /> __page_handle_poison+0x45/0xc0<br /> memory_failure+0x65e/0xc70<br /> hard_offline_page_store+0x55/0xa0<br /> kernfs_fop_write_iter+0x12c/0x1d0<br /> vfs_write+0x387/0x550<br /> ksys_write+0x64/0xe0<br /> do_syscall_64+0xca/0x1e0<br /> entry_SYSCALL_64_after_hwframe+0x6d/0x75<br /> RIP: 0033:0x7fc862314887<br /> Code: 10 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 01 00 00 00 0f 05 3d 00 f0 ff ff 77 51 c3 48 83 ec 28 48 89 54 24 18 48 89 74 24<br /> RSP: 002b:00007fff19311268 EFLAGS: 00000246 ORIG_RAX: 0000000000000001<br /> RAX: ffffffffffffffda RBX: 000000000000000c RCX: 00007fc862314887<br /> RDX: 000000000000000c RSI: 000056405645fe10 RDI: 0000000000000001<br /> RBP: 000056405645fe10 R08: 00007fc8623d1460 R09: 000000007fffffff<br /> R10: 0000000000000000 R11: 0000000000000246 R12: 000000000000000c<br /> R13: 00007fc86241b780 R14: 00007fc862417600 R15: 00007fc862416a00<br /> <br /> In short, below scene breaks the <br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> init/main.c: Fix potential static_command_line memory overflow<br /> <br /> We allocate memory of size &amp;#39;xlen + strlen(boot_command_line) + 1&amp;#39; for<br /> static_command_line, but the strings copied into static_command_line are<br /> extra_command_line and command_line, rather than extra_command_line and<br /> boot_command_line.<br /> <br /> When strlen(command_line) &gt; strlen(boot_command_line), static_command_line<br /> will overflow.<br /> <br /> This patch just recovers strlen(command_line) which was miss-consolidated<br /> with strlen(boot_command_line) in the commit f5c7310ac73e ("init/main: add<br /> checks for the return value of memblock_alloc*()")