Vulnerabilities

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]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: verisilicon: Avoid G2 bus error while decoding H.264 and HEVC<br /> <br /> For the i.MX8MQ platform, there is a hardware limitation: the g1 VPU and<br /> g2 VPU cannot decode simultaneously; otherwise, it will cause below bus<br /> error and produce corrupted pictures, even potentially lead to system hang.<br /> <br /> [ 110.527986] hantro-vpu 38310000.video-codec: frame decode timed out.<br /> [ 110.583517] hantro-vpu 38310000.video-codec: bus error detected.<br /> <br /> Therefore, it is necessary to ensure that g1 and g2 operate alternately.<br /> This allows for successful multi-instance decoding of H.264 and HEVC.<br /> <br /> To achieve this, g1 and g2 share the same v4l2_m2m_dev, and then the<br /> v4l2_m2m_dev can handle the scheduling.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> md raid: fix hang when stopping arrays with metadata through dm-raid<br /> <br /> When using device-mapper&amp;#39;s dm-raid target, stopping a RAID array can cause<br /> the system to hang under specific conditions.<br /> <br /> This occurs when:<br /> <br /> - A dm-raid managed device tree is suspended from top to bottom<br /> (the top-level RAID device is suspended first, followed by its<br /> underlying metadata and data devices)<br /> <br /> - The top-level RAID device is then removed<br /> <br /> Removing the top-level device triggers a hang in the following sequence:<br /> the dm-raid destructor calls md_stop(), which tries to flush the<br /> write-intent bitmap by writing to the metadata sub-devices. However, these<br /> devices are already suspended, making them unable to complete the write-intent<br /> operations and causing an indefinite block.<br /> <br /> Fix:<br /> <br /> - Prevent bitmap flushing when md_stop() is called from dm-raid<br /> destructor context<br /> and avoid a quiescing/unquescing cycle which could also cause I/O<br /> <br /> - Still allow write-intent bitmap flushing when called from dm-raid<br /> suspend context<br /> <br /> This ensures that RAID array teardown can complete successfully even when the<br /> underlying devices are in a suspended state.<br /> <br /> This second patch uses md_is_rdwr() to distinguish between suspend and<br /> destructor paths as elaborated on above.