Vulnerabilities

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.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: don&amp;#39;t BUG() on unexpected delayed ref type in run_one_delayed_ref()<br /> <br /> There is no need to BUG(), we can just return an error and log an error<br /> message.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iio: accel: adxl380: Avoid reading more entries than present in FIFO<br /> <br /> The interrupt handler reads FIFO entries in batches of N samples, where N<br /> is the number of scan elements that have been enabled. However, the sensor<br /> fills the FIFO one sample at a time, even when more than one channel is<br /> enabled. Therefore,the number of entries reported by the FIFO status<br /> registers may not be a multiple of N; if this number is not a multiple, the<br /> number of entries read from the FIFO may exceed the number of entries<br /> actually present.<br /> <br /> To fix the above issue, round down the number of FIFO entries read from the<br /> status registers so that it is always a multiple of N.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: crypto: Use the correct destructor kfunc type<br /> <br /> With CONFIG_CFI enabled, the kernel strictly enforces that indirect<br /> function calls use a function pointer type that matches the target<br /> function. I ran into the following type mismatch when running BPF<br /> self-tests:<br /> <br /> CFI failure at bpf_obj_free_fields+0x190/0x238 (target:<br /> bpf_crypto_ctx_release+0x0/0x94; expected type: 0xa488ebfc)<br /> Internal error: Oops - CFI: 00000000f2008228 [#1] SMP<br /> ...<br /> <br /> As bpf_crypto_ctx_release() is also used in BPF programs and using<br /> a void pointer as the argument would make the verifier unhappy, add<br /> a simple stub function with the correct type and register it as the<br /> destructor kfunc instead.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Fix mismatched unlock for DMUB HW lock in HWSS fast path<br /> <br /> [Why]<br /> The evaluation for whether we need to use the DMUB HW lock isn&amp;#39;t the<br /> same as whether we need to unlock which results in a hang when the<br /> fast path is used for ASIC without FAMS support.<br /> <br /> [How]<br /> Store a flag that indicates whether we should use the lock and use<br /> that same flag to specify whether unlocking is needed.