Vulnerabilities

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 /> 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 /> 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 /> 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 /> 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 /> 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 /> 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 /> 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 /> btrfs: do not ASSERT() when the fs flips RO inside btrfs_repair_io_failure()<br /> <br /> [BUG]<br /> There is a bug report that when btrfs hits ENOSPC error in a critical<br /> path, btrfs flips RO (this part is expected, although the ENOSPC bug<br /> still needs to be addressed).<br /> <br /> The problem is after the RO flip, if there is a read repair pending, we<br /> can hit the ASSERT() inside btrfs_repair_io_failure() like the following:<br /> <br /> BTRFS info (device vdc): relocating block group 30408704 flags metadata|raid1<br /> ------------[ cut here ]------------<br /> BTRFS: Transaction aborted (error -28)<br /> WARNING: fs/btrfs/extent-tree.c:3235 at __btrfs_free_extent.isra.0+0x453/0xfd0, CPU#1: btrfs/383844<br /> Modules linked in: kvm_intel kvm irqbypass<br /> [...]<br /> ---[ end trace 0000000000000000 ]---<br /> BTRFS info (device vdc state EA): 2 enospc errors during balance<br /> BTRFS info (device vdc state EA): balance: ended with status: -30<br /> BTRFS error (device vdc state EA): parent transid verify failed on logical 30556160 mirror 2 wanted 8 found 6<br /> BTRFS error (device vdc state EA): bdev /dev/nvme0n1 errs: wr 0, rd 0, flush 0, corrupt 10, gen 0<br /> [...]<br /> assertion failed: !(fs_info-&gt;sb-&gt;s_flags &amp; SB_RDONLY) :: 0, in fs/btrfs/bio.c:938<br /> ------------[ cut here ]------------<br /> assertion failed: !(fs_info-&gt;sb-&gt;s_flags &amp; SB_RDONLY) :: 0, in fs/btrfs/bio.c:938<br /> kernel BUG at fs/btrfs/bio.c:938!<br /> Oops: invalid opcode: 0000 [#1] SMP NOPTI<br /> CPU: 0 UID: 0 PID: 868 Comm: kworker/u8:13 Tainted: G W N 6.19.0-rc6+ #4788 PREEMPT(full)<br /> Tainted: [W]=WARN, [N]=TEST<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.17.0-0-gb52ca86e094d-prebuilt.qemu.org 04/01/2014<br /> Workqueue: btrfs-endio simple_end_io_work<br /> RIP: 0010:btrfs_repair_io_failure.cold+0xb2/0x120<br /> RSP: 0000:ffffc90001d2bcf0 EFLAGS: 00010246<br /> RAX: 0000000000000051 RBX: 0000000000001000 RCX: 0000000000000000<br /> RDX: 0000000000000000 RSI: ffffffff8305cf42 RDI: 00000000ffffffff<br /> RBP: 0000000000000002 R08: 00000000fffeffff R09: ffffffff837fa988<br /> R10: ffffffff8327a9e0 R11: 6f69747265737361 R12: ffff88813018d310<br /> R13: ffff888168b8a000 R14: ffffc90001d2bd90 R15: ffff88810a169000<br /> FS: 0000000000000000(0000) GS:ffff8885e752c000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> ------------[ cut here ]------------<br /> <br /> [CAUSE]<br /> The cause of -ENOSPC error during the test case btrfs/124 is still<br /> unknown, although it&amp;#39;s known that we still have cases where metadata can<br /> be over-committed but can not be fulfilled correctly, thus if we hit<br /> such ENOSPC error inside a critical path, we have no choice but abort<br /> the current transaction.<br /> <br /> This will mark the fs read-only.<br /> <br /> The problem is inside the btrfs_repair_io_failure() path that we require<br /> the fs not to be mount read-only. This is normally fine, but if we are<br /> doing a read-repair meanwhile the fs flips RO due to a critical error,<br /> we can enter btrfs_repair_io_failure() with super block set to<br /> read-only, thus triggering the above crash.<br /> <br /> [FIX]<br /> Just replace the ASSERT() with a proper return if the fs is already<br /> read-only.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/panel: Fix a possible null-pointer dereference in jdi_panel_dsi_remove()<br /> <br /> In jdi_panel_dsi_remove(), jdi is explicitly checked, indicating that it<br /> may be NULL:<br /> <br /> if (!jdi)<br /> mipi_dsi_detach(dsi);<br /> <br /> However, when jdi is NULL, the function does not return and continues by<br /> calling jdi_panel_disable():<br /> <br /> err = jdi_panel_disable(&amp;jdi-&gt;base);<br /> <br /> Inside jdi_panel_disable(), jdi is dereferenced unconditionally, which can<br /> lead to a NULL-pointer dereference:<br /> <br /> struct jdi_panel *jdi = to_panel_jdi(panel);<br /> backlight_disable(jdi-&gt;backlight);<br /> <br /> To prevent such a potential NULL-pointer dereference, return early from<br /> jdi_panel_dsi_remove() when jdi is NULL.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: chips-media: wave5: Fix PM runtime usage count underflow<br /> <br /> Replace pm_runtime_put_sync() with pm_runtime_dont_use_autosuspend() in<br /> the remove path to properly pair with pm_runtime_use_autosuspend() from<br /> probe. This allows pm_runtime_disable() to handle reference count cleanup<br /> correctly regardless of current suspend state.<br /> <br /> The driver calls pm_runtime_put_sync() unconditionally in remove, but the<br /> device may already be suspended due to autosuspend configured in probe.<br /> When autosuspend has already suspended the device, the usage count is 0,<br /> and pm_runtime_put_sync() decrements it to -1.<br /> <br /> This causes the following warning on module unload:<br /> <br /> ------------[ cut here ]------------<br /> WARNING: CPU: 1 PID: 963 at kernel/kthread.c:1430<br /> kthread_destroy_worker+0x84/0x98<br /> ...<br /> vdec 30210000.video-codec: Runtime PM usage count underflow!

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/v3d: Set DMA segment size to avoid debug warnings<br /> <br /> When using V3D rendering with CONFIG_DMA_API_DEBUG enabled, the<br /> kernel occasionally reports a segment size mismatch. This is because<br /> &amp;#39;max_seg_size&amp;#39; is not set. The kernel defaults to 64K. setting<br /> &amp;#39;max_seg_size&amp;#39; to the maximum will prevent &amp;#39;debug_dma_map_sg()&amp;#39;<br /> from complaining about the over-mapping of the V3D segment length.<br /> <br /> DMA-API: v3d 1002000000.v3d: mapping sg segment longer than device<br /> claims to support [len=8290304] [max=65536]<br /> WARNING: CPU: 0 PID: 493 at kernel/dma/debug.c:1179 debug_dma_map_sg+0x330/0x388<br /> CPU: 0 UID: 0 PID: 493 Comm: Xorg Not tainted 6.12.53-yocto-standard #1<br /> Hardware name: Raspberry Pi 5 Model B Rev 1.0 (DT)<br /> pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> pc : debug_dma_map_sg+0x330/0x388<br /> lr : debug_dma_map_sg+0x330/0x388<br /> sp : ffff8000829a3ac0<br /> x29: ffff8000829a3ac0 x28: 0000000000000001 x27: ffff8000813fe000<br /> x26: ffffc1ffc0000000 x25: ffff00010fdeb760 x24: 0000000000000000<br /> x23: ffff8000816a9bf0 x22: 0000000000000001 x21: 0000000000000002<br /> x20: 0000000000000002 x19: ffff00010185e810 x18: ffffffffffffffff<br /> x17: 69766564206e6168 x16: 74207265676e6f6c x15: 20746e656d676573<br /> x14: 20677320676e6970 x13: 5d34303334393134 x12: 0000000000000000<br /> x11: 00000000000000c0 x10: 00000000000009c0 x9 : ffff8000800e0b7c<br /> x8 : ffff00010a315ca0 x7 : ffff8000816a5110 x6 : 0000000000000001<br /> x5 : 000000000000002b x4 : 0000000000000002 x3 : 0000000000000008<br /> x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff00010a315280<br /> Call trace:<br /> debug_dma_map_sg+0x330/0x388<br /> __dma_map_sg_attrs+0xc0/0x278<br /> dma_map_sgtable+0x30/0x58<br /> drm_gem_shmem_get_pages_sgt+0xb4/0x140<br /> v3d_bo_create_finish+0x28/0x130 [v3d]<br /> v3d_create_bo_ioctl+0x54/0x180 [v3d]<br /> drm_ioctl_kernel+0xc8/0x140<br /> drm_ioctl+0x2d4/0x4d8