Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> USB: dummy-hcd: Fix locking/synchronization error<br /> <br /> Syzbot testing was able to provoke an addressing exception and crash<br /> in the usb_gadget_udc_reset() routine in<br /> drivers/usb/gadgets/udc/core.c, resulting from the fact that the<br /> routine was called with a second ("driver") argument of NULL. The bad<br /> caller was set_link_state() in dummy_hcd.c, and the problem arose<br /> because of a race between a USB reset and driver unbind.<br /> <br /> These sorts of races were not supposed to be possible; commit<br /> 7dbd8f4cabd9 ("USB: dummy-hcd: Fix erroneous synchronization change"),<br /> along with a few followup commits, was written specifically to prevent<br /> them. As it turns out, there are (at least) two errors remaining in<br /> the code. Another patch will address the second error; this one is<br /> concerned with the first.<br /> <br /> The error responsible for the syzbot crash occurred because the<br /> stop_activity() routine will sometimes drop and then re-acquire the<br /> dum-&gt;lock spinlock. A call to stop_activity() occurs in<br /> set_link_state() when handling an emulated USB reset, after the test<br /> of dum-&gt;ints_enabled and before the increment of dum-&gt;callback_usage.<br /> This allowed another thread (doing a driver unbind) to sneak in and<br /> grab the spinlock, and then clear dum-&gt;ints_enabled and dum-&gt;driver.<br /> Normally this other thread would have to wait for dum-&gt;callback_usage<br /> to go down to 0 before it would clear dum-&gt;driver, but in this case it<br /> didn&amp;#39;t have to wait since dum-&gt;callback_usage had not yet been<br /> incremented.<br /> <br /> The fix is to increment dum-&gt;callback_usage _before_ calling<br /> stop_activity() instead of after. Then the thread doing the unbind<br /> will not clear dum-&gt;driver until after the call to<br /> usb_gadget_udc_reset() safely returns and dum-&gt;callback_usage has been<br /> decremented again.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> USB: dummy-hcd: Fix interrupt synchronization error<br /> <br /> This fixes an error in synchronization in the dummy-hcd driver. The<br /> error has a somewhat involved history. The synchronization mechanism<br /> was introduced by commit 7dbd8f4cabd9 ("USB: dummy-hcd: Fix erroneous<br /> synchronization change"), which added an emulated "interrupts enabled"<br /> flag together with code emulating synchronize_irq() (it waits until<br /> all current handler callbacks have returned).<br /> <br /> But the emulated interrupt-disable occurred too late, after the driver<br /> containing the handler callback routines had been told that it was<br /> unbound and no more callbacks would occur. Commit 4a5d797a9f9c ("usb:<br /> gadget: dummy_hcd: fix gpf in gadget_setup") tried to fix this by<br /> moving the synchronize_irq() emulation code from dummy_stop() to<br /> dummy_pullup(), which runs before the unbind callback.<br /> <br /> There still were races, though, because the emulated interrupt-disable<br /> still occurred too late. It couldn&amp;#39;t be moved to dummy_pullup(),<br /> because that routine can be called for reasons other than an impending<br /> unbind. Therefore commits 7dc0c55e9f30 ("USB: UDC core: Add<br /> udc_async_callbacks gadget op") and 04145a03db9d ("USB: UDC: Implement<br /> udc_async_callbacks in dummy-hcd") added an API allowing the UDC core<br /> to tell dummy-hcd exactly when emulated interrupts and their callbacks<br /> should be disabled.<br /> <br /> That brings us to the current state of things, which is still wrong<br /> because the emulated synchronize_irq() occurs before the emulated<br /> interrupt-disable! That&amp;#39;s no good, beause it means that more emulated<br /> interrupts can occur after the synchronize_irq() emulation has run,<br /> leading to the possibility that a callback handler may be running when<br /> the gadget driver is unbound.<br /> <br /> To fix this, we have to move the synchronize_irq() emulation code yet<br /> again, to the dummy_udc_async_callbacks() routine, which takes care of<br /> enabling and disabling emulated interrupt requests. The<br /> synchronization will now run immediately after emulated interrupts are<br /> disabled, which is where it belongs.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: iwlwifi: mvm: don&amp;#39;t send a 6E related command when not supported<br /> <br /> MCC_ALLOWED_AP_TYPE_CMD is related to 6E support. Do not send it if the<br /> device doesn&amp;#39;t support 6E.<br /> Apparently, the firmware is mistakenly advertising support for this<br /> command even on AX201 which does not support 6E and then the firmware<br /> crashes.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Properly mark live registers for indirect jumps<br /> <br /> For a `gotox rX` instruction the rX register should be marked as used<br /> in the compute_insn_live_regs() function. Fix this.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: solo6x10: Check for out of bounds chip_id<br /> <br /> Clang with CONFIG_UBSAN_SHIFT=y noticed a condition where a signed type<br /> (literal "1" is an "int") could end up being shifted beyond 32 bits,<br /> so instrumentation was added (and due to the double is_tw286x() call<br /> seen via inlining), Clang decides the second one must now be undefined<br /> behavior and elides the rest of the function[1]. This is a known problem<br /> with Clang (that is still being worked on), but we can avoid the entire<br /> problem by actually checking the existing max chip ID, and now there is<br /> no runtime instrumentation added at all since everything is known to be<br /> within bounds.<br /> <br /> Additionally use an unsigned value for the shift to remove the<br /> instrumentation even without the explicit bounds checking.<br /> <br /> [hverkuil: fix checkpatch warning for is_tw286x]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> most: core: fix leak on early registration failure<br /> <br /> A recent commit fixed a resource leak on early registration failures but<br /> for some reason left out the first error path which still leaks the<br /> resources associated with the interface.<br /> <br /> Fix up also the first error path so that the interface is always<br /> released on errors.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu: fix sync handling in amdgpu_dma_buf_move_notify<br /> <br /> Invalidating a dmabuf will impact other users of the shared BO.<br /> In the scenario where process A moves the BO, it needs to inform<br /> process B about the move and process B will need to update its<br /> page table.<br /> <br /> The commit fixes a synchronisation bug caused by the use of the<br /> ticket: it made amdgpu_vm_handle_moved behave as if updating<br /> the page table immediately was correct but in this case it&amp;#39;s not.<br /> <br /> An example is the following scenario, with 2 GPUs and glxgears<br /> running on GPU0 and Xorg running on GPU1, on a system where P2P<br /> PCI isn&amp;#39;t supported:<br /> <br /> glxgears:<br /> export linear buffer from GPU0 and import using GPU1<br /> submit frame rendering to GPU0<br /> submit tiled-&gt;linear blit<br /> Xorg:<br /> copy of linear buffer<br /> <br /> The sequence of jobs would be:<br /> drm_sched_job_run # GPU0, frame rendering<br /> drm_sched_job_queue # GPU0, blit<br /> drm_sched_job_done # GPU0, frame rendering<br /> drm_sched_job_run # GPU0, blit<br /> move linear buffer for GPU1 access #<br /> amdgpu_dma_buf_move_notify -&gt; update pt # GPU0<br /> <br /> It this point the blit job on GPU0 is still running and would<br /> likely produce a page fault.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> spi: spidev: fix lock inversion between spi_lock and buf_lock<br /> <br /> The spidev driver previously used two mutexes, spi_lock and buf_lock,<br /> but acquired them in different orders depending on the code path:<br /> <br /> write()/read(): buf_lock -&gt; spi_lock<br /> ioctl(): spi_lock -&gt; buf_lock<br /> <br /> This AB-BA locking pattern triggers lockdep warnings and can<br /> cause real deadlocks:<br /> <br /> WARNING: possible circular locking dependency detected<br /> spidev_ioctl() -&gt; mutex_lock(&amp;spidev-&gt;buf_lock)<br /> spidev_sync_write() -&gt; mutex_lock(&amp;spidev-&gt;spi_lock)<br /> *** DEADLOCK ***<br /> <br /> The issue is reproducible with a simple userspace program that<br /> performs write() and SPI_IOC_WR_MAX_SPEED_HZ ioctl() calls from<br /> separate threads on the same spidev file descriptor.<br /> <br /> Fix this by simplifying the locking model and removing the lock<br /> inversion entirely. spidev_sync() no longer performs any locking,<br /> and all callers serialize access using spi_lock.<br /> <br /> buf_lock is removed since its functionality is fully covered by<br /> spi_lock, eliminating the possibility of lock ordering issues.<br /> <br /> This removes the lock inversion and prevents deadlocks without<br /> changing userspace ABI or behaviour.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Fix dsc eDP issue<br /> <br /> [why]<br /> Need to add function hook check before use

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: hci_sync: Fix UAF in le_read_features_complete<br /> <br /> This fixes the following backtrace caused by hci_conn being freed<br /> before le_read_features_complete but after<br /> hci_le_read_remote_features_sync so hci_conn_del -&gt; hci_cmd_sync_dequeue<br /> is not able to prevent it:<br /> <br /> ==================================================================<br /> BUG: KASAN: slab-use-after-free in instrument_atomic_read_write include/linux/instrumented.h:96 [inline]<br /> BUG: KASAN: slab-use-after-free in atomic_dec_and_test include/linux/atomic/atomic-instrumented.h:1383 [inline]<br /> BUG: KASAN: slab-use-after-free in hci_conn_drop include/net/bluetooth/hci_core.h:1688 [inline]<br /> BUG: KASAN: slab-use-after-free in le_read_features_complete+0x5b/0x340 net/bluetooth/hci_sync.c:7344<br /> Write of size 4 at addr ffff8880796b0010 by task kworker/u9:0/52<br /> <br /> CPU: 0 UID: 0 PID: 52 Comm: kworker/u9:0 Not tainted syzkaller #0 PREEMPT(full)<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025<br /> Workqueue: hci0 hci_cmd_sync_work<br /> Call Trace:<br /> <br /> __dump_stack lib/dump_stack.c:94 [inline]<br /> dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120<br /> print_address_description mm/kasan/report.c:378 [inline]<br /> print_report+0xcd/0x630 mm/kasan/report.c:482<br /> kasan_report+0xe0/0x110 mm/kasan/report.c:595<br /> check_region_inline mm/kasan/generic.c:194 [inline]<br /> kasan_check_range+0x100/0x1b0 mm/kasan/generic.c:200<br /> instrument_atomic_read_write include/linux/instrumented.h:96 [inline]<br /> atomic_dec_and_test include/linux/atomic/atomic-instrumented.h:1383 [inline]<br /> hci_conn_drop include/net/bluetooth/hci_core.h:1688 [inline]<br /> le_read_features_complete+0x5b/0x340 net/bluetooth/hci_sync.c:7344<br /> hci_cmd_sync_work+0x1ff/0x430 net/bluetooth/hci_sync.c:334<br /> process_one_work+0x9ba/0x1b20 kernel/workqueue.c:3257<br /> process_scheduled_works kernel/workqueue.c:3340 [inline]<br /> worker_thread+0x6c8/0xf10 kernel/workqueue.c:3421<br /> kthread+0x3c5/0x780 kernel/kthread.c:463<br /> ret_from_fork+0x983/0xb10 arch/x86/kernel/process.c:158<br /> ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:246<br /> <br /> <br /> Allocated by task 5932:<br /> kasan_save_stack+0x33/0x60 mm/kasan/common.c:56<br /> kasan_save_track+0x14/0x30 mm/kasan/common.c:77<br /> poison_kmalloc_redzone mm/kasan/common.c:400 [inline]<br /> __kasan_kmalloc+0xaa/0xb0 mm/kasan/common.c:417<br /> kmalloc_noprof include/linux/slab.h:957 [inline]<br /> kzalloc_noprof include/linux/slab.h:1094 [inline]<br /> __hci_conn_add+0xf8/0x1c70 net/bluetooth/hci_conn.c:963<br /> hci_conn_add_unset+0x76/0x100 net/bluetooth/hci_conn.c:1084<br /> le_conn_complete_evt+0x639/0x1f20 net/bluetooth/hci_event.c:5714<br /> hci_le_enh_conn_complete_evt+0x23d/0x380 net/bluetooth/hci_event.c:5861<br /> hci_le_meta_evt+0x357/0x5e0 net/bluetooth/hci_event.c:7408<br /> hci_event_func net/bluetooth/hci_event.c:7716 [inline]<br /> hci_event_packet+0x685/0x11c0 net/bluetooth/hci_event.c:7773<br /> hci_rx_work+0x2c9/0xeb0 net/bluetooth/hci_core.c:4076<br /> process_one_work+0x9ba/0x1b20 kernel/workqueue.c:3257<br /> process_scheduled_works kernel/workqueue.c:3340 [inline]<br /> worker_thread+0x6c8/0xf10 kernel/workqueue.c:3421<br /> kthread+0x3c5/0x780 kernel/kthread.c:463<br /> ret_from_fork+0x983/0xb10 arch/x86/kernel/process.c:158<br /> ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:246<br /> <br /> Freed by task 5932:<br /> kasan_save_stack+0x33/0x60 mm/kasan/common.c:56<br /> kasan_save_track+0x14/0x30 mm/kasan/common.c:77<br /> __kasan_save_free_info+0x3b/0x60 mm/kasan/generic.c:587<br /> kasan_save_free_info mm/kasan/kasan.h:406 [inline]<br /> poison_slab_object mm/kasan/common.c:252 [inline]<br /> __kasan_slab_free+0x5f/0x80 mm/kasan/common.c:284<br /> kasan_slab_free include/linux/kasan.h:234 [inline]<br /> slab_free_hook mm/slub.c:2540 [inline]<br /> slab_free mm/slub.c:6663 [inline]<br /> kfree+0x2f8/0x6e0 mm/slub.c:6871<br /> device_release+0xa4/0x240 drivers/base/core.c:2565<br /> kobject_cleanup lib/kobject.c:689 [inline]<br /> kobject_release lib/kobject.c:720 [inline]<br /> kref_put include/linux/kref.h:65 [inline]<br /> kobject_put+0x1e7/0x590 lib/kobject.<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sched/fair: Fix zero_vruntime tracking fix<br /> <br /> John reported that stress-ng-yield could make his machine unhappy and<br /> managed to bisect it to commit b3d99f43c72b ("sched/fair: Fix<br /> zero_vruntime tracking").<br /> <br /> The combination of yield and that commit was specific enough to<br /> hypothesize the following scenario:<br /> <br /> Suppose we have 2 runnable tasks, both doing yield. Then one will be<br /> eligible and one will not be, because the average position must be in<br /> between these two entities.<br /> <br /> Therefore, the runnable task will be eligible, and be promoted a full<br /> slice (all the tasks do is yield after all). This causes it to jump over<br /> the other task and now the other task is eligible and current is no<br /> longer. So we schedule.<br /> <br /> Since we are runnable, there is no {de,en}queue. All we have is the<br /> __{en,de}queue_entity() from {put_prev,set_next}_task(). But per the<br /> fingered commit, those two no longer move zero_vruntime.<br /> <br /> All that moves zero_vruntime are tick and full {de,en}queue.<br /> <br /> This means, that if the two tasks playing leapfrog can reach the<br /> critical speed to reach the overflow point inside one tick&amp;#39;s worth of<br /> time, we&amp;#39;re up a creek.<br /> <br /> Additionally, when multiple cgroups are involved, there is no guarantee<br /> the tick will in fact hit every cgroup in a timely manner. Statistically<br /> speaking it will, but that same statistics does not rule out the<br /> possibility of one cgroup not getting a tick for a significant amount of<br /> time -- however unlikely.<br /> <br /> Therefore, just like with the yield() case, force an update at the end<br /> of every slice. This ensures the update is never more than a single<br /> slice behind and the whole thing is within 2 lag bounds as per the<br /> comment on entity_key().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> soc/tegra: pmc: Fix unsafe generic_handle_irq() call<br /> <br /> Currently, when resuming from system suspend on Tegra platforms,<br /> the following warning is observed:<br /> <br /> WARNING: CPU: 0 PID: 14459 at kernel/irq/irqdesc.c:666<br /> Call trace:<br /> handle_irq_desc+0x20/0x58 (P)<br /> tegra186_pmc_wake_syscore_resume+0xe4/0x15c<br /> syscore_resume+0x3c/0xb8<br /> suspend_devices_and_enter+0x510/0x540<br /> pm_suspend+0x16c/0x1d8<br /> <br /> The warning occurs because generic_handle_irq() is being called from<br /> a non-interrupt context which is considered as unsafe.<br /> <br /> Fix this warning by deferring generic_handle_irq() call to an IRQ work<br /> which gets executed in hard IRQ context where generic_handle_irq()<br /> can be called safely.<br /> <br /> When PREEMPT_RT kernels are used, regular IRQ work (initialized with<br /> init_irq_work) is deferred to run in per-CPU kthreads in preemptible<br /> context rather than hard IRQ context. Hence, use the IRQ_WORK_INIT_HARD<br /> variant so that with PREEMPT_RT kernels, the IRQ work is processed in<br /> hardirq context instead of being deferred to a thread which is required<br /> for calling generic_handle_irq().<br /> <br /> On non-PREEMPT_RT kernels, both init_irq_work() and IRQ_WORK_INIT_HARD()<br /> execute in IRQ context, so this change has no functional impact for<br /> standard kernel configurations.<br /> <br /> [treding@nvidia.com: miscellaneous cleanups]