Vulnerabilities

Vulnerability in SK Hynix DDR5 on x86 allows a local attacker to trigger Rowhammer bit flips impacting the Hardware Integrity and the system's security. This issue affects DDR5: DIMMs produced from 2021-1 until 2024-12.

Insufficiently specific bounds checking on authorization header could lead to denial of service in the Temporal server on all platforms due to excessive memory allocation.This issue affects all platforms and versions of OSS Server prior to 1.26.3, 1.27.3, and 1.28.1 (i.e., fixed in 1.26.3, 1.27.3, and 1.28.1 and later). Temporal Cloud services are not impacted.

TOTOLINK X6000R V9.4.0cu.1360_B20241207 was found to contain a command injection vulnerability in the sub_417D74 function via the file_name parameter. This vulnerability allows unauthenticated attackers to execute arbitrary commands via a crafted request.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mac80211: check S1G action frame size<br /> <br /> Before checking the action code, check that it even<br /> exists in the frame.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Fix possible underflow for displays with large vblank<br /> <br /> [Why]<br /> Underflow observed when using a display with a large vblank region<br /> and low refresh rate<br /> <br /> [How]<br /> Simplify calculation of vblank_nom<br /> <br /> Increase value for VBlankNomDefaultUS to 800us

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ovl: fix null pointer dereference in ovl_permission()<br /> <br /> Following process:<br /> P1 P2<br /> path_lookupat<br /> link_path_walk<br /> inode_permission<br /> ovl_permission<br /> ovl_i_path_real(inode, &amp;realpath)<br /> path-&gt;dentry = ovl_i_dentry_upper(inode)<br /> drop_cache<br /> __dentry_kill(ovl_dentry)<br /> iput(ovl_inode)<br /> ovl_destroy_inode(ovl_inode)<br /> dput(oi-&gt;__upperdentry)<br /> dentry_kill(upperdentry)<br /> dentry_unlink_inode<br /> upperdentry-&gt;d_inode = NULL<br /> realinode = d_inode(realpath.dentry) // return NULL<br /> inode_permission(realinode)<br /> inode-&gt;i_sb // NULL pointer dereference<br /> , will trigger an null pointer dereference at realinode:<br /> [ 335.664979] BUG: kernel NULL pointer dereference,<br /> address: 0000000000000002<br /> [ 335.668032] CPU: 0 PID: 2592 Comm: ls Not tainted 6.3.0<br /> [ 335.669956] RIP: 0010:inode_permission+0x33/0x2c0<br /> [ 335.678939] Call Trace:<br /> [ 335.679165] <br /> [ 335.679371] ovl_permission+0xde/0x320<br /> [ 335.679723] inode_permission+0x15e/0x2c0<br /> [ 335.680090] link_path_walk+0x115/0x550<br /> [ 335.680771] path_lookupat.isra.0+0xb2/0x200<br /> [ 335.681170] filename_lookup+0xda/0x240<br /> [ 335.681922] vfs_statx+0xa6/0x1f0<br /> [ 335.682233] vfs_fstatat+0x7b/0xb0<br /> <br /> Fetch a reproducer in [Link].<br /> <br /> Use the helper ovl_i_path_realinode() to get realinode and then do<br /> non-nullptr checking.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> coresight: Fix memory leak in acpi_buffer-&gt;pointer<br /> <br /> There are memory leaks reported by kmemleak:<br /> ...<br /> unreferenced object 0xffff00213c141000 (size 1024):<br /> comm "systemd-udevd", pid 2123, jiffies 4294909467 (age 6062.160s)<br /> hex dump (first 32 bytes):<br /> 04 00 00 00 02 00 00 00 18 10 14 3c 21 00 ff ff ...........] __kmem_cache_alloc_node+0x2f8/0x348<br /> [] __kmalloc+0x58/0x108<br /> [] acpi_os_allocate+0x2c/0x68<br /> [] acpi_ut_initialize_buffer+0x54/0xe0<br /> [] acpi_evaluate_object+0x388/0x438<br /> [] acpi_evaluate_object_typed+0xe8/0x240<br /> [] coresight_get_platform_data+0x1b4/0x988 [coresight]<br /> ...<br /> <br /> The ACPI buffer memory (buf.pointer) should be freed. But the buffer<br /> is also used after returning from acpi_get_dsd_graph().<br /> Move the temporary variables buf to acpi_coresight_parse_graph(),<br /> and free it before the function return to prevent memory leak.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: fix scheduling while atomic in decompression path<br /> <br /> [ 16.945668][ C0] Call trace:<br /> [ 16.945678][ C0] dump_backtrace+0x110/0x204<br /> [ 16.945706][ C0] dump_stack_lvl+0x84/0xbc<br /> [ 16.945735][ C0] __schedule_bug+0xb8/0x1ac<br /> [ 16.945756][ C0] __schedule+0x724/0xbdc<br /> [ 16.945778][ C0] schedule+0x154/0x258<br /> [ 16.945793][ C0] bit_wait_io+0x48/0xa4<br /> [ 16.945808][ C0] out_of_line_wait_on_bit+0x114/0x198<br /> [ 16.945824][ C0] __sync_dirty_buffer+0x1f8/0x2e8<br /> [ 16.945853][ C0] __f2fs_commit_super+0x140/0x1f4<br /> [ 16.945881][ C0] f2fs_commit_super+0x110/0x28c<br /> [ 16.945898][ C0] f2fs_handle_error+0x1f4/0x2f4<br /> [ 16.945917][ C0] f2fs_decompress_cluster+0xc4/0x450<br /> [ 16.945942][ C0] f2fs_end_read_compressed_page+0xc0/0xfc<br /> [ 16.945959][ C0] f2fs_handle_step_decompress+0x118/0x1cc<br /> [ 16.945978][ C0] f2fs_read_end_io+0x168/0x2b0<br /> [ 16.945993][ C0] bio_endio+0x25c/0x2c8<br /> [ 16.946015][ C0] dm_io_dec_pending+0x3e8/0x57c<br /> [ 16.946052][ C0] clone_endio+0x134/0x254<br /> [ 16.946069][ C0] bio_endio+0x25c/0x2c8<br /> [ 16.946084][ C0] blk_update_request+0x1d4/0x478<br /> [ 16.946103][ C0] scsi_end_request+0x38/0x4cc<br /> [ 16.946129][ C0] scsi_io_completion+0x94/0x184<br /> [ 16.946147][ C0] scsi_finish_command+0xe8/0x154<br /> [ 16.946164][ C0] scsi_complete+0x90/0x1d8<br /> [ 16.946181][ C0] blk_done_softirq+0xa4/0x11c<br /> [ 16.946198][ C0] _stext+0x184/0x614<br /> [ 16.946214][ C0] __irq_exit_rcu+0x78/0x144<br /> [ 16.946234][ C0] handle_domain_irq+0xd4/0x154<br /> [ 16.946260][ C0] gic_handle_irq.33881+0x5c/0x27c<br /> [ 16.946281][ C0] call_on_irq_stack+0x40/0x70<br /> [ 16.946298][ C0] do_interrupt_handler+0x48/0xa4<br /> [ 16.946313][ C0] el1_interrupt+0x38/0x68<br /> [ 16.946346][ C0] el1h_64_irq_handler+0x20/0x30<br /> [ 16.946362][ C0] el1h_64_irq+0x78/0x7c<br /> [ 16.946377][ C0] finish_task_switch+0xc8/0x3d8<br /> [ 16.946394][ C0] __schedule+0x600/0xbdc<br /> [ 16.946408][ C0] preempt_schedule_common+0x34/0x5c<br /> [ 16.946423][ C0] preempt_schedule+0x44/0x48<br /> [ 16.946438][ C0] process_one_work+0x30c/0x550<br /> [ 16.946456][ C0] worker_thread+0x414/0x8bc<br /> [ 16.946472][ C0] kthread+0x16c/0x1e0<br /> [ 16.946486][ C0] ret_from_fork+0x10/0x20

A security flaw has been discovered in PHPGurukul Beauty Parlour Management System 1.1. This affects an unknown part of the file /admin/all-appointment.php. The manipulation of the argument delid results in sql injection. The attack can be executed remotely. The exploit has been released to the public and may be exploited.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> VMCI: check context-&gt;notify_page after call to get_user_pages_fast() to avoid GPF<br /> <br /> The call to get_user_pages_fast() in vmci_host_setup_notify() can return<br /> NULL context-&gt;notify_page causing a GPF. To avoid GPF check if<br /> context-&gt;notify_page == NULL and return error if so.<br /> <br /> general protection fault, probably for non-canonical address<br /> 0xe0009d1000000060: 0000 [#1] PREEMPT SMP KASAN NOPTI<br /> KASAN: maybe wild-memory-access in range [0x0005088000000300-<br /> 0x0005088000000307]<br /> CPU: 2 PID: 26180 Comm: repro_34802241 Not tainted 6.1.0-rc4 #1<br /> Hardware name: Red Hat KVM, BIOS 1.15.0-2.module+el8.6.0 04/01/2014<br /> RIP: 0010:vmci_ctx_check_signal_notify+0x91/0xe0<br /> Call Trace:<br /> <br /> vmci_host_unlocked_ioctl+0x362/0x1f40<br /> __x64_sys_ioctl+0x1a1/0x230<br /> do_syscall_64+0x3a/0x90<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu: install stub fence into potential unused fence pointers<br /> <br /> When using cpu to update page tables, vm update fences are unused.<br /> Install stub fence into these fence pointers instead of NULL<br /> to avoid NULL dereference when calling dma_fence_wait() on them.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> clk: imx: clk-imx8mn: fix memory leak in imx8mn_clocks_probe<br /> <br /> Use devm_of_iomap() instead of of_iomap() to automatically handle<br /> the unused ioremap region.<br /> <br /> If any error occurs, regions allocated by kzalloc() will leak,<br /> but using devm_kzalloc() instead will automatically free the memory<br /> using devm_kfree().