Vulnerabilities

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 /> 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 /> 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 /> 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/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 /> 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 /> 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 /> KVM: nSVM: Remove a user-triggerable WARN on nested_svm_load_cr3() succeeding<br /> <br /> Drop the WARN in svm_set_nested_state() on nested_svm_load_cr3() failing<br /> as it is trivially easy to trigger from userspace by modifying CPUID after<br /> loading CR3. E.g. modifying the state restoration selftest like so:<br /> <br /> --- tools/testing/selftests/kvm/x86/state_test.c<br /> +++ tools/testing/selftests/kvm/x86/state_test.c<br /> @@ -280,7 +280,16 @@ int main(int argc, char *argv[])<br /> <br /> /* Restore state in a new VM. */<br /> vcpu = vm_recreate_with_one_vcpu(vm);<br /> - vcpu_load_state(vcpu, state);<br /> +<br /> + if (stage == 4) {<br /> + state-&gt;sregs.cr3 = BIT(44);<br /> + vcpu_load_state(vcpu, state);<br /> +<br /> + vcpu_set_cpuid_property(vcpu, X86_PROPERTY_MAX_PHY_ADDR, 36);<br /> + __vcpu_nested_state_set(vcpu, &amp;state-&gt;nested);<br /> + } else {<br /> + vcpu_load_state(vcpu, state);<br /> + }<br /> <br /> /*<br /> * Restore XSAVE state in a dummy vCPU, first without doing<br /> <br /> generates:<br /> <br /> WARNING: CPU: 30 PID: 938 at arch/x86/kvm/svm/nested.c:1877 svm_set_nested_state+0x34a/0x360 [kvm_amd]<br /> Modules linked in: kvm_amd kvm irqbypass [last unloaded: kvm]<br /> CPU: 30 UID: 1000 PID: 938 Comm: state_test Tainted: G W 6.18.0-rc7-58e10b63777d-next-vm<br /> Tainted: [W]=WARN<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015<br /> RIP: 0010:svm_set_nested_state+0x34a/0x360 [kvm_amd]<br /> Call Trace:<br /> <br /> kvm_arch_vcpu_ioctl+0xf33/0x1700 [kvm]<br /> kvm_vcpu_ioctl+0x4e6/0x8f0 [kvm]<br /> __x64_sys_ioctl+0x8f/0xd0<br /> do_syscall_64+0x61/0xad0<br /> entry_SYSCALL_64_after_hwframe+0x4b/0x53<br /> <br /> Simply delete the WARN instead of trying to prevent userspace from shoving<br /> "illegal" state into CR3. For better or worse, KVM&amp;#39;s ABI allows userspace<br /> to set CPUID after SREGS, and vice versa, and KVM is very permissive when<br /> it comes to guest CPUID. I.e. attempting to enforce the virtual CPU model<br /> when setting CPUID could break userspace. Given that the WARN doesn&amp;#39;t<br /> provide any meaningful protection for KVM or benefit for userspace, simply<br /> drop it even though the odds of breaking userspace are minuscule.<br /> <br /> Opportunistically delete a spurious newline.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dm: remove fake timeout to avoid leak request<br /> <br /> Since commit 15f73f5b3e59 ("blk-mq: move failure injection out of<br /> blk_mq_complete_request"), drivers are responsible for calling<br /> blk_should_fake_timeout() at appropriate code paths and opportunities.<br /> <br /> However, the dm driver does not implement its own timeout handler and<br /> relies on the timeout handling of its slave devices.<br /> <br /> If an io-timeout-fail error is injected to a dm device, the request<br /> will be leaked and never completed, causing tasks to hang indefinitely.<br /> <br /> Reproduce:<br /> 1. prepare dm which has iscsi slave device<br /> 2. inject io-timeout-fail to dm<br /> echo 1 &gt;/sys/class/block/dm-0/io-timeout-fail<br /> echo 100 &gt;/sys/kernel/debug/fail_io_timeout/probability<br /> echo 10 &gt;/sys/kernel/debug/fail_io_timeout/times<br /> 3. read/write dm<br /> 4. iscsiadm -m node -u<br /> <br /> Result: hang task like below<br /> [ 862.243768] INFO: task kworker/u514:2:151 blocked for more than 122 seconds.<br /> [ 862.244133] Tainted: G E 6.19.0-rc1+ #51<br /> [ 862.244337] "echo 0 &gt; /proc/sys/kernel/hung_task_timeout_secs" disables this message.<br /> [ 862.244718] task:kworker/u514:2 state:D stack:0 pid:151 tgid:151 ppid:2 task_flags:0x4288060 flags:0x00080000<br /> [ 862.245024] Workqueue: iscsi_ctrl_3:1 __iscsi_unbind_session [scsi_transport_iscsi]<br /> [ 862.245264] Call Trace:<br /> [ 862.245587] <br /> [ 862.245814] __schedule+0x810/0x15c0<br /> [ 862.246557] schedule+0x69/0x180<br /> [ 862.246760] blk_mq_freeze_queue_wait+0xde/0x120<br /> [ 862.247688] elevator_change+0x16d/0x460<br /> [ 862.247893] elevator_set_none+0x87/0xf0<br /> [ 862.248798] blk_unregister_queue+0x12e/0x2a0<br /> [ 862.248995] __del_gendisk+0x231/0x7e0<br /> [ 862.250143] del_gendisk+0x12f/0x1d0<br /> [ 862.250339] sd_remove+0x85/0x130 [sd_mod]<br /> [ 862.250650] device_release_driver_internal+0x36d/0x530<br /> [ 862.250849] bus_remove_device+0x1dd/0x3f0<br /> [ 862.251042] device_del+0x38a/0x930<br /> [ 862.252095] __scsi_remove_device+0x293/0x360<br /> [ 862.252291] scsi_remove_target+0x486/0x760<br /> [ 862.252654] __iscsi_unbind_session+0x18a/0x3e0 [scsi_transport_iscsi]<br /> [ 862.252886] process_one_work+0x633/0xe50<br /> [ 862.253101] worker_thread+0x6df/0xf10<br /> [ 862.253647] kthread+0x36d/0x720<br /> [ 862.254533] ret_from_fork+0x2a6/0x470<br /> [ 862.255852] ret_from_fork_asm+0x1a/0x30<br /> [ 862.256037] <br /> <br /> Remove the blk_should_fake_timeout() check from dm, as dm has no<br /> native timeout handling and should not attempt to fake timeouts.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ACPI: processor: Fix NULL-pointer dereference in acpi_processor_errata_piix4()<br /> <br /> In acpi_processor_errata_piix4(), the pointer dev is first assigned an IDE<br /> device and then reassigned an ISA device:<br /> <br /> dev = pci_get_subsys(..., PCI_DEVICE_ID_INTEL_82371AB, ...);<br /> dev = pci_get_subsys(..., PCI_DEVICE_ID_INTEL_82371AB_0, ...);<br /> <br /> If the first lookup succeeds but the second fails, dev becomes NULL. This<br /> leads to a potential null-pointer dereference when dev_dbg() is called:<br /> <br /> if (errata.piix4.bmisx)<br /> dev_dbg(&amp;dev-&gt;dev, ...);<br /> <br /> To prevent this, use two temporary pointers and retrieve each device<br /> independently, avoiding overwriting dev with a possible NULL value.<br /> <br /> [ rjw: Subject adjustment, added an empty code line ]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: i2c: ov5647: Initialize subdev before controls<br /> <br /> In ov5647_init_controls() we call v4l2_get_subdevdata, but it is<br /> initialized by v4l2_i2c_subdev_init() in the probe, which currently<br /> happens after init_controls(). This can result in a segfault if the<br /> error condition is hit, and we try to access i2c_client, so fix the<br /> order.

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]