Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu: Skip vcn poison irq release on VF<br /> <br /> VF doesn&amp;#39;t enable VCN poison irq in VCNv2.5. Skip releasing it and avoid<br /> call trace during deinitialization.<br /> <br /> [ 71.913601] [drm] clean up the vf2pf work item<br /> [ 71.915088] ------------[ cut here ]------------<br /> [ 71.915092] WARNING: CPU: 3 PID: 1079 at /tmp/amd.aFkFvSQl/amd/amdgpu/amdgpu_irq.c:641 amdgpu_irq_put+0xc6/0xe0 [amdgpu]<br /> [ 71.915355] Modules linked in: amdgpu(OE-) amddrm_ttm_helper(OE) amdttm(OE) amddrm_buddy(OE) amdxcp(OE) amddrm_exec(OE) amd_sched(OE) amdkcl(OE) drm_suballoc_helper drm_display_helper cec rc_core i2c_algo_bit video wmi binfmt_misc nls_iso8859_1 intel_rapl_msr intel_rapl_common input_leds joydev serio_raw mac_hid qemu_fw_cfg sch_fq_codel dm_multipath scsi_dh_rdac scsi_dh_emc scsi_dh_alua efi_pstore ip_tables x_tables autofs4 btrfs blake2b_generic raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c raid1 raid0 hid_generic crct10dif_pclmul crc32_pclmul polyval_clmulni polyval_generic ghash_clmulni_intel usbhid 8139too sha256_ssse3 sha1_ssse3 hid psmouse bochs i2c_i801 ahci drm_vram_helper libahci i2c_smbus lpc_ich drm_ttm_helper 8139cp mii ttm aesni_intel crypto_simd cryptd<br /> [ 71.915484] CPU: 3 PID: 1079 Comm: rmmod Tainted: G OE 6.8.0-87-generic #88~22.04.1-Ubuntu<br /> [ 71.915489] Hardware name: Red Hat KVM/RHEL, BIOS 1.16.3-2.el9_5.1 04/01/2014<br /> [ 71.915492] RIP: 0010:amdgpu_irq_put+0xc6/0xe0 [amdgpu]<br /> [ 71.915768] Code: 75 84 b8 ea ff ff ff eb d4 44 89 ea 48 89 de 4c 89 e7 e8 fd fc ff ff 5b 41 5c 41 5d 41 5e 5d 31 d2 31 f6 31 ff e9 55 30 3b c7 0b eb d4 b8 fe ff ff ff eb a8 e9 b7 3b 8a 00 66 2e 0f 1f 84 00<br /> [ 71.915771] RSP: 0018:ffffcf0800eafa30 EFLAGS: 00010246<br /> [ 71.915775] RAX: 0000000000000000 RBX: ffff891bda4b0668 RCX: 0000000000000000<br /> [ 71.915777] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000<br /> [ 71.915779] RBP: ffffcf0800eafa50 R08: 0000000000000000 R09: 0000000000000000<br /> [ 71.915781] R10: 0000000000000000 R11: 0000000000000000 R12: ffff891bda480000<br /> [ 71.915782] R13: 0000000000000000 R14: 0000000000000001 R15: 0000000000000000<br /> [ 71.915792] FS: 000070cff87c4c40(0000) GS:ffff893abfb80000(0000) knlGS:0000000000000000<br /> [ 71.915795] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 71.915797] CR2: 00005fa13073e478 CR3: 000000010d634006 CR4: 0000000000770ef0<br /> [ 71.915800] PKRU: 55555554<br /> [ 71.915802] Call Trace:<br /> [ 71.915805] <br /> [ 71.915809] vcn_v2_5_hw_fini+0x19e/0x1e0 [amdgpu]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: rockchip: rga: Fix possible ERR_PTR dereference in rga_buf_init()<br /> <br /> rga_get_frame() can return ERR_PTR(-EINVAL) when buffer type is<br /> unsupported or invalid. rga_buf_init() does not check the return value<br /> and unconditionally dereferences the pointer when accessing f-&gt;size.<br /> <br /> Add proper ERR_PTR checking and return the error to prevent<br /> dereferencing an invalid pointer.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> octeontx2-af: Workaround SQM/PSE stalls by disabling sticky<br /> <br /> NIX SQ manager sticky mode is known to cause stalls when multiple SQs<br /> share an SMQ and transmit concurrently. Additionally, PSE may deadlock<br /> on transitions between sticky and non-sticky transmissions. There is<br /> also a credit drop issue observed when certain condition clocks are<br /> gated.<br /> <br /> work around these hardware errata by:<br /> - Disabling SQM sticky operation:<br /> - Clear TM6 (bit 15)<br /> - Clear TM11 (bit 14)<br /> - Disabling sticky → non-sticky transition path that can deadlock PSE:<br /> - Clear TM5 (bit 23)<br /> - Preventing credit drops by keeping the control-flow clock enabled:<br /> - Set TM9 (bit 21)<br /> <br /> These changes are applied via NIX_AF_SQM_DBG_CTL_STATUS. With this<br /> configuration the SQM/PSE maintain forward progress under load without<br /> credit loss, at the cost of disabling sticky optimizations.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rapidio: replace rio_free_net() with kfree() in rio_scan_alloc_net()<br /> <br /> When idtab allocation fails, net is not registered with rio_add_net() yet,<br /> so kfree(net) is sufficient to release the memory. Set mport-&gt;net to NULL<br /> to avoid dangling pointer.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm: renesas: rz-du: mipi_dsi: fix kernel panic when rebooting for some panels<br /> <br /> Since commit 56de5e305d4b ("clk: renesas: r9a07g044: Add MSTOP for RZ/G2L")<br /> we may get the following kernel panic, for some panels, when rebooting:<br /> <br /> systemd-shutdown[1]: Rebooting.<br /> Call trace:<br /> ...<br /> do_serror+0x28/0x68<br /> el1h_64_error_handler+0x34/0x50<br /> el1h_64_error+0x6c/0x70<br /> rzg2l_mipi_dsi_host_transfer+0x114/0x458 (P)<br /> mipi_dsi_device_transfer+0x44/0x58<br /> mipi_dsi_dcs_set_display_off_multi+0x9c/0xc4<br /> ili9881c_unprepare+0x38/0x88<br /> drm_panel_unprepare+0xbc/0x108<br /> <br /> This happens for panels that need to send MIPI-DSI commands in their<br /> unprepare() callback. Since the MIPI-DSI interface is stopped at that<br /> point, rzg2l_mipi_dsi_host_transfer() triggers the kernel panic.<br /> <br /> Fix by moving rzg2l_mipi_dsi_stop() to new callback function<br /> rzg2l_mipi_dsi_atomic_post_disable().<br /> <br /> With this change we now have the correct power-down/stop sequence:<br /> <br /> systemd-shutdown[1]: Rebooting.<br /> rzg2l-mipi-dsi 10850000.dsi: rzg2l_mipi_dsi_atomic_disable(): entry<br /> ili9881c-dsi 10850000.dsi.0: ili9881c_unprepare(): entry<br /> rzg2l-mipi-dsi 10850000.dsi: rzg2l_mipi_dsi_atomic_post_disable(): entry<br /> reboot: Restarting system

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: chips-media: wave5: Fix kthread worker destruction in polling mode<br /> <br /> Fix the cleanup order in polling mode (irq work_list)) and<br /> WARN_ON(!list_empty(&amp;worker-&gt;delayed_work_list)).<br /> <br /> The original code called kthread_destroy_worker() before hrtimer_cancel(),<br /> creating a race condition where the timer could fire during worker<br /> destruction and queue new work, triggering the WARN_ON.<br /> <br /> This causes the following warning on every module unload in polling mode:<br /> <br /> ------------[ cut here ]------------<br /> WARNING: CPU: 2 PID: 1034 at kernel/kthread.c:1430<br /> kthread_destroy_worker+0x84/0x98<br /> Modules linked in: wave5(-) rpmsg_ctrl rpmsg_char ...<br /> Call trace:<br /> kthread_destroy_worker+0x84/0x98<br /> wave5_vpu_remove+0xc8/0xe0 [wave5]<br /> platform_remove+0x30/0x58<br /> ...<br /> ---[ end trace 0000000000000000 ]---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/vmalloc: prevent RCU stalls in kasan_release_vmalloc_node<br /> <br /> When CONFIG_PAGE_OWNER is enabled, freeing KASAN shadow pages during<br /> vmalloc cleanup triggers expensive stack unwinding that acquires RCU read<br /> locks. Processing a large purge_list without rescheduling can cause the<br /> task to hold CPU for extended periods (10+ seconds), leading to RCU stalls<br /> and potential OOM conditions.<br /> <br /> The issue manifests in purge_vmap_node() -&gt; kasan_release_vmalloc_node()<br /> where iterating through hundreds or thousands of vmap_area entries and<br /> freeing their associated shadow pages causes:<br /> <br /> rcu: INFO: rcu_preempt detected stalls on CPUs/tasks:<br /> rcu: Tasks blocked on level-0 rcu_node (CPUs 0-1): P6229/1:b..l<br /> ...<br /> task:kworker/0:17 state:R running task stack:28840 pid:6229<br /> ...<br /> kasan_release_vmalloc_node+0x1ba/0xad0 mm/vmalloc.c:2299<br /> purge_vmap_node+0x1ba/0xad0 mm/vmalloc.c:2299<br /> <br /> Each call to kasan_release_vmalloc() can free many pages, and with<br /> page_owner tracking, each free triggers save_stack() which performs stack<br /> unwinding under RCU read lock. Without yielding, this creates an<br /> unbounded RCU critical section.<br /> <br /> Add periodic cond_resched() calls within the loop to allow:<br /> - RCU grace periods to complete<br /> - Other tasks to run<br /> - Scheduler to preempt when needed<br /> <br /> The fix uses need_resched() for immediate response under load, with a<br /> batch count of 32 as a guaranteed upper bound to prevent worst-case stalls<br /> even under light load.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> kexec: derive purgatory entry from symbol<br /> <br /> kexec_load_purgatory() derives image-&gt;start by locating e_entry inside an<br /> SHF_EXECINSTR section. If the purgatory object contains multiple<br /> executable sections with overlapping sh_addr, the entrypoint check can<br /> match more than once and trigger a WARN.<br /> <br /> Derive the entry section from the purgatory_start symbol when present and<br /> compute image-&gt;start from its final placement. Keep the existing e_entry<br /> fallback for purgatories that do not expose the symbol.<br /> <br /> WARNING: kernel/kexec_file.c:1009 at kexec_load_purgatory+0x395/0x3c0, CPU#10: kexec/1784<br /> Call Trace:<br /> <br /> bzImage64_load+0x133/0xa00<br /> __do_sys_kexec_file_load+0x2b3/0x5c0<br /> do_syscall_64+0x81/0x610<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> <br /> [me@linux.beauty: move helper to avoid forward declaration, per Baoquan]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: move ext4_percpu_param_init() before ext4_mb_init()<br /> <br /> When running `kvm-xfstests -c ext4/1k -C 1 generic/383` with the<br /> `DOUBLE_CHECK` macro defined, the following panic is triggered:<br /> <br /> ==================================================================<br /> EXT4-fs error (device vdc): ext4_validate_block_bitmap:423:<br /> comm mount: bg 0: bad block bitmap checksum<br /> BUG: unable to handle page fault for address: ff110000fa2cc000<br /> PGD 3e01067 P4D 3e02067 PUD 0<br /> Oops: Oops: 0000 [#1] SMP NOPTI<br /> CPU: 0 UID: 0 PID: 2386 Comm: mount Tainted: G W<br /> 6.18.0-gba65a4e7120a-dirty #1152 PREEMPT(none)<br /> RIP: 0010:percpu_counter_add_batch+0x13/0xa0<br /> Call Trace:<br /> <br /> ext4_mark_group_bitmap_corrupted+0xcb/0xe0<br /> ext4_validate_block_bitmap+0x2a1/0x2f0<br /> ext4_read_block_bitmap+0x33/0x50<br /> mb_group_bb_bitmap_alloc+0x33/0x80<br /> ext4_mb_add_groupinfo+0x190/0x250<br /> ext4_mb_init_backend+0x87/0x290<br /> ext4_mb_init+0x456/0x640<br /> __ext4_fill_super+0x1072/0x1680<br /> ext4_fill_super+0xd3/0x280<br /> get_tree_bdev_flags+0x132/0x1d0<br /> vfs_get_tree+0x29/0xd0<br /> vfs_cmd_create+0x59/0xe0<br /> __do_sys_fsconfig+0x4f6/0x6b0<br /> do_syscall_64+0x50/0x1f0<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> ==================================================================<br /> <br /> This issue can be reproduced using the following commands:<br /> mkfs.ext4 -F -q -b 1024 /dev/sda 5G<br /> tune2fs -O quota,project /dev/sda<br /> mount /dev/sda /tmp/test<br /> <br /> With DOUBLE_CHECK defined, mb_group_bb_bitmap_alloc() reads<br /> and validates the block bitmap. When the validation fails,<br /> ext4_mark_group_bitmap_corrupted() attempts to update<br /> sbi-&gt;s_freeclusters_counter. However, this percpu_counter has not been<br /> initialized yet at this point, which leads to the panic described above.<br /> <br /> Fix this by moving the execution of ext4_percpu_param_init() to occur<br /> before ext4_mb_init(), ensuring the per-CPU counters are initialized<br /> before they are used.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm: Account property blob allocations to memcg<br /> <br /> DRM_IOCTL_MODE_CREATEPROPBLOB allows userspace to allocate arbitrary-sized<br /> property blobs backed by kernel memory.<br /> <br /> Currently, the blob data allocation is not accounted to the allocating<br /> process&amp;#39;s memory cgroup, allowing unprivileged users to trigger unbounded<br /> kernel memory consumption and potentially cause system-wide OOM.<br /> <br /> Mark the property blob data allocation with GFP_KERNEL_ACCOUNT so that the memory<br /> is properly charged to the caller&amp;#39;s memcg. This ensures existing cgroup<br /> memory limits apply and prevents uncontrolled kernel memory growth without<br /> introducing additional policy or per-file limits.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/hugetlb: restore failed global reservations to subpool<br /> <br /> Commit a833a693a490 ("mm: hugetlb: fix incorrect fallback for subpool")<br /> fixed an underflow error for hstate-&gt;resv_huge_pages caused by incorrectly<br /> attributing globally requested pages to the subpool&amp;#39;s reservation.<br /> <br /> Unfortunately, this fix also introduced the opposite problem, which would<br /> leave spool-&gt;used_hpages elevated if the globally requested pages could<br /> not be acquired. This is because while a subpool&amp;#39;s reserve pages only<br /> accounts for what is requested and allocated from the subpool, its "used"<br /> counter keeps track of what is consumed in total, both from the subpool<br /> and globally. Thus, we need to adjust spool-&gt;used_hpages in the other<br /> direction, and make sure that globally requested pages are uncharged from<br /> the subpool&amp;#39;s used counter.<br /> <br /> Each failed allocation attempt increments the used_hpages counter by how<br /> many pages were requested from the global pool. Ultimately, this renders<br /> the subpool unusable, as used_hpages approaches the max limit.<br /> <br /> The issue can be reproduced as follows:<br /> 1. Allocate 4 hugetlb pages<br /> 2. Create a hugetlb mount with max=4, min=2<br /> 3. Consume 2 pages globally<br /> 4. Request 3 pages from the subpool (2 from subpool + 1 from global)<br /> 4.1 hugepage_subpool_get_pages(spool, 3) succeeds.<br /> used_hpages += 3<br /> 4.2 hugetlb_acct_memory(h, 1) fails: no global pages left<br /> used_hpages -= 2<br /> 5. Subpool now has used_hpages = 1, despite not being able to<br /> successfully allocate any hugepages. It believes it can now only<br /> allocate 3 more hugepages, not 4.<br /> <br /> With each failed allocation attempt incrementing the used counter, the<br /> subpool eventually reaches a point where its used counter equals its<br /> max counter. At that point, any future allocations that try to<br /> allocate hugeTLB pages from the subpool will fail, despite the subpool<br /> not having any of its hugeTLB pages consumed by any user.<br /> <br /> Once this happens, there is no way to make the subpool usable again,<br /> since there is no way to decrement the used counter as no process is<br /> really consuming the hugeTLB pages.<br /> <br /> The underflow issue that the original commit fixes still remains fixed<br /> as well.<br /> <br /> Without this fix, used_hpages would keep on leaking if<br /> hugetlb_acct_memory() fails.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/slab: do not access current-&gt;mems_allowed_seq if !allow_spin<br /> <br /> Lockdep complains when get_from_any_partial() is called in an NMI<br /> context, because current-&gt;mems_allowed_seq is seqcount_spinlock_t and<br /> not NMI-safe:<br /> <br /> ================================<br /> WARNING: inconsistent lock state<br /> 6.19.0-rc5-kfree-rcu+ #315 Tainted: G N<br /> --------------------------------<br /> inconsistent {INITIAL USE} -&gt; {IN-NMI} usage.<br /> kunit_try_catch/9989 [HC1[1]:SC0[0]:HE0:SE1] takes:<br /> ffff889085799820 (&amp;____s-&gt;seqcount#3){.-.-}-{0:0}, at: ___slab_alloc+0x58f/0xc00<br /> {INITIAL USE} state was registered at:<br /> lock_acquire+0x185/0x320<br /> kernel_init_freeable+0x391/0x1150<br /> kernel_init+0x1f/0x220<br /> ret_from_fork+0x736/0x8f0<br /> ret_from_fork_asm+0x1a/0x30<br /> irq event stamp: 56<br /> hardirqs last enabled at (55): [] _raw_spin_unlock_irq+0x27/0x70<br /> hardirqs last disabled at (56): [] __schedule+0x2a8a/0x6630<br /> softirqs last enabled at (0): [] copy_process+0x1dc1/0x6a10<br /> softirqs last disabled at (0): [] 0x0<br /> <br /> other info that might help us debug this:<br /> Possible unsafe locking scenario:<br /> <br /> CPU0<br /> ----<br /> lock(&amp;____s-&gt;seqcount#3);<br /> <br /> lock(&amp;____s-&gt;seqcount#3);<br /> <br /> *** DEADLOCK ***<br /> <br /> According to Documentation/locking/seqlock.rst, seqcount_t is not<br /> NMI-safe and seqcount_latch_t should be used when read path can interrupt<br /> the write-side critical section. In this case, do not access<br /> current-&gt;mems_allowed_seq and avoid retry.