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

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.

ai-scanner is an AI model safety scanner built on NVIDIA garak. From version 1.0.0 to before version 1.4.1, there is a remote code execution vulnerability via JavaScript injection in `BrowserAutomation::PlaywrightService`. This issue has been patched in version 1.4.1.

math-codegen generates code from mathematical expressions. Prior to version 0.4.3, string literal content passed to cg.parse() is injected verbatim into a new Function() body without sanitization. This allows an attacker to execute arbitrary system commands when user-controlled input reaches the parser. Any application exposing a math evaluation endpoint where user input flows into cg.parse() is vulnerable to full RCE. This issue has been patched in version 0.4.3.

CROSS implementation contains reference and optimized implementations of the CROSS post-quantum signature algorithm. Prior to commit fc6b7e7, there is a buffer overflow in crypto_sign_open() caused by an underflow of the integer mlen. This issue has been patched via commit fc6b7e7.

PraisonAI is a multi-agent teams system. Prior to version 4.6.9, the fix for PraisonAI&amp;#39;s MCP command handling does not add a command allowlist or argument validation to parse_mcp_command(), allowing arbitrary executables like bash, python, or /bin/sh with inline code execution flags to pass through to subprocess execution. This issue has been patched in version 4.6.9.