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 /> 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]

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 /> 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 /> 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.