| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Fix null check of pipe_ctx->plane_state for update_dchubp_dpp
Similar to commit 6a057072ddd1 ("drm/amd/display: Fix null check for
pipe_ctx->plane_state in dcn20_program_pipe") that addresses a null
pointer dereference on dcn20_update_dchubp_dpp. This is the same
function hooked for update_dchubp_dpp in dcn401, with the same issue.
Fix possible null pointer deference on dcn401_program_pipe too.
(cherry picked from commit d8d47f739752227957d8efc0cb894761bfe1d879) |
| In the Linux kernel, the following vulnerability has been resolved:
powerpc/rtas: Fix RTAS MSR[HV] handling for Cell
The semi-recent changes to MSR handling when entering RTAS (firmware)
cause crashes on IBM Cell machines. An example trace:
kernel tried to execute user page (2fff01a8) - exploit attempt? (uid: 0)
BUG: Unable to handle kernel instruction fetch
Faulting instruction address: 0x2fff01a8
Oops: Kernel access of bad area, sig: 11 [#1]
BE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=4 NUMA Cell
Modules linked in:
CPU: 0 PID: 0 Comm: swapper/0 Tainted: G W 6.0.0-rc2-00433-gede0a8d3307a #207
NIP: 000000002fff01a8 LR: 0000000000032608 CTR: 0000000000000000
REGS: c0000000015236b0 TRAP: 0400 Tainted: G W (6.0.0-rc2-00433-gede0a8d3307a)
MSR: 0000000008001002 <ME,RI> CR: 00000000 XER: 20000000
...
NIP 0x2fff01a8
LR 0x32608
Call Trace:
0xc00000000143c5f8 (unreliable)
.rtas_call+0x224/0x320
.rtas_get_boot_time+0x70/0x150
.read_persistent_clock64+0x114/0x140
.read_persistent_wall_and_boot_offset+0x24/0x80
.timekeeping_init+0x40/0x29c
.start_kernel+0x674/0x8f0
start_here_common+0x1c/0x50
Unlike PAPR platforms where RTAS is only used in guests, on the IBM Cell
machines Linux runs with MSR[HV] set but also uses RTAS, provided by
SLOF.
Fix it by copying the MSR[HV] bit from the MSR value we've just read
using mfmsr into the value used for RTAS.
It seems like we could also fix it using an #ifdef CELL to set MSR[HV],
but that doesn't work because it's possible to build a single kernel
image that runs on both Cell native and pseries. |
| In the Linux kernel, the following vulnerability has been resolved:
Input: iforce - wake up after clearing IFORCE_XMIT_RUNNING flag
syzbot is reporting hung task at __input_unregister_device() [1], for
iforce_close() waiting at wait_event_interruptible() with dev->mutex held
is blocking input_disconnect_device() from __input_unregister_device().
It seems that the cause is simply that commit c2b27ef672992a20 ("Input:
iforce - wait for command completion when closing the device") forgot to
call wake_up() after clear_bit().
Fix this problem by introducing a helper that calls clear_bit() followed
by wake_up_all(). |
| In the Linux kernel, the following vulnerability has been resolved:
iio: light: cm3605: Fix an error handling path in cm3605_probe()
The commit in Fixes also introduced a new error handling path which should
goto the existing error handling path.
Otherwise some resources leak. |
| In the Linux kernel, the following vulnerability has been resolved:
misc: fastrpc: fix memory corruption on probe
Add the missing sanity check on the probed-session count to avoid
corrupting memory beyond the fixed-size slab-allocated session array
when there are more than FASTRPC_MAX_SESSIONS sessions defined in the
devicetree. |
| In the Linux kernel, the following vulnerability has been resolved:
firmware_loader: Fix use-after-free during unregister
In the following code within firmware_upload_unregister(), the call to
device_unregister() could result in the dev_release function freeing the
fw_upload_priv structure before it is dereferenced for the call to
module_put(). This bug was found by the kernel test robot using
CONFIG_KASAN while running the firmware selftests.
device_unregister(&fw_sysfs->dev);
module_put(fw_upload_priv->module);
The problem is fixed by copying fw_upload_priv->module to a local variable
for use when calling device_unregister(). |
| In the Linux kernel, the following vulnerability has been resolved:
misc: fastrpc: fix memory corruption on open
The probe session-duplication overflow check incremented the session
count also when there were no more available sessions so that memory
beyond the fixed-size slab-allocated session array could be corrupted in
fastrpc_session_alloc() on open(). |
| In the Linux kernel, the following vulnerability has been resolved:
firmware_loader: Fix memory leak in firmware upload
In the case of firmware-upload, an instance of struct fw_upload is
allocated in firmware_upload_register(). This data needs to be freed
in fw_dev_release(). Create a new fw_upload_free() function in
sysfs_upload.c to handle the firmware-upload specific memory frees
and incorporate the missing kfree call for the fw_upload structure. |
| CodeChecker is an analyzer tooling, defect database and viewer extension for the Clang Static Analyzer and Clang Tidy.
CodeChecker versions up to 6.26.1 contain a buffer overflow vulnerability in the internal ldlogger library, which is executed by the CodeChecker log command.
This issue affects CodeChecker: through 6.26.1. |
| AXIS Optimizer was vulnerable to an unquoted search path vulnerability, which could potentially lead to privilege escalation within Microsoft Windows operating system. This vulnerability can only be exploited if the attacker has access to the local Windows machine and sufficient access rights (administrator) to write data into the installation path of AXIS Optimizer. |
| FairSketch Rise Ultimate Project Manager & CRM 3.9.4 is vulnerable to Insecure Permissions. A remote authenticated user can append comments or upload attachments to tickets for which they lack view or edit authorization, due to missing authorization checks in the ticketing/commenting API. |
| HTML injection vulnerability found in Fairsketch's RISE CRM Framework v3.8.1, which consist of an HTML code injection due to lack of proper validation of user inputs by sending a POST request in parameter 'title' in'/projects/save'. |
| HTML injection vulnerability found in Fairsketch's RISE CRM Framework v3.8.1, which consist of an HTML code injection due to lack of proper validation of user inputs by sending a POST request in parameter 'title' in '/tickets/save'. |
| Improper Restriction of Excessive Authentication Attempts, Client-Side Enforcement of Server-Side Security, Reliance on Untrusted Inputs in a Security Decision vulnerability in Turkguven Software Technologies Inc. Perfektive allows Brute Force, Authentication Bypass, Functionality Bypass.This issue affects Perfektive: before Version: 12574 Build: 2701. |
| A cross-site request forgery (CSRF) vulnerability has been reported to affect QuLog Center. The remote attackers can then exploit the vulnerability to gain privileges or hijack user identities.
We have already fixed the vulnerability in the following version:
QuLog Center 1.8.2.927 ( 2025/09/17 ) and later |
| It was possible to upload files with a specific name to a temporary directory, which may result in process crashes and impact usability. This flaw can only be exploited after authenticating with an operator- or administrator-privileged service account. |
| A vulnerability was found in 70mai X200 up to 20251019. This issue affects some unknown processing of the component Init Script Handler. The manipulation results in file inclusion. The attack requires a local approach. A high complexity level is associated with this attack. The exploitability is assessed as difficult. The exploit has been made public and could be used. The vendor was contacted early about this disclosure but did not respond in any way. |
| In the Linux kernel, the following vulnerability has been resolved:
ftrace: Fix NULL pointer dereference in is_ftrace_trampoline when ftrace is dead
ftrace_startup does not remove ops from ftrace_ops_list when
ftrace_startup_enable fails:
register_ftrace_function
ftrace_startup
__register_ftrace_function
...
add_ftrace_ops(&ftrace_ops_list, ops)
...
...
ftrace_startup_enable // if ftrace failed to modify, ftrace_disabled is set to 1
...
return 0 // ops is in the ftrace_ops_list.
When ftrace_disabled = 1, unregister_ftrace_function simply returns without doing anything:
unregister_ftrace_function
ftrace_shutdown
if (unlikely(ftrace_disabled))
return -ENODEV; // return here, __unregister_ftrace_function is not executed,
// as a result, ops is still in the ftrace_ops_list
__unregister_ftrace_function
...
If ops is dynamically allocated, it will be free later, in this case,
is_ftrace_trampoline accesses NULL pointer:
is_ftrace_trampoline
ftrace_ops_trampoline
do_for_each_ftrace_op(op, ftrace_ops_list) // OOPS! op may be NULL!
Syzkaller reports as follows:
[ 1203.506103] BUG: kernel NULL pointer dereference, address: 000000000000010b
[ 1203.508039] #PF: supervisor read access in kernel mode
[ 1203.508798] #PF: error_code(0x0000) - not-present page
[ 1203.509558] PGD 800000011660b067 P4D 800000011660b067 PUD 130fb8067 PMD 0
[ 1203.510560] Oops: 0000 [#1] SMP KASAN PTI
[ 1203.511189] CPU: 6 PID: 29532 Comm: syz-executor.2 Tainted: G B W 5.10.0 #8
[ 1203.512324] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014
[ 1203.513895] RIP: 0010:is_ftrace_trampoline+0x26/0xb0
[ 1203.514644] Code: ff eb d3 90 41 55 41 54 49 89 fc 55 53 e8 f2 00 fd ff 48 8b 1d 3b 35 5d 03 e8 e6 00 fd ff 48 8d bb 90 00 00 00 e8 2a 81 26 00 <48> 8b ab 90 00 00 00 48 85 ed 74 1d e8 c9 00 fd ff 48 8d bb 98 00
[ 1203.518838] RSP: 0018:ffffc900012cf960 EFLAGS: 00010246
[ 1203.520092] RAX: 0000000000000000 RBX: 000000000000007b RCX: ffffffff8a331866
[ 1203.521469] RDX: 0000000000000000 RSI: 0000000000000008 RDI: 000000000000010b
[ 1203.522583] RBP: 0000000000000000 R08: 0000000000000000 R09: ffffffff8df18b07
[ 1203.523550] R10: fffffbfff1be3160 R11: 0000000000000001 R12: 0000000000478399
[ 1203.524596] R13: 0000000000000000 R14: ffff888145088000 R15: 0000000000000008
[ 1203.525634] FS: 00007f429f5f4700(0000) GS:ffff8881daf00000(0000) knlGS:0000000000000000
[ 1203.526801] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 1203.527626] CR2: 000000000000010b CR3: 0000000170e1e001 CR4: 00000000003706e0
[ 1203.528611] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 1203.529605] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Therefore, when ftrace_startup_enable fails, we need to rollback registration
process and remove ops from ftrace_ops_list. |
| In the Linux kernel, the following vulnerability has been resolved:
fbdev: fb_pm2fb: Avoid potential divide by zero error
In `do_fb_ioctl()` of fbmem.c, if cmd is FBIOPUT_VSCREENINFO, var will be
copied from user, then go through `fb_set_var()` and
`info->fbops->fb_check_var()` which could may be `pm2fb_check_var()`.
Along the path, `var->pixclock` won't be modified. This function checks
whether reciprocal of `var->pixclock` is too high. If `var->pixclock` is
zero, there will be a divide by zero error. So, it is necessary to check
whether denominator is zero to avoid crash. As this bug is found by
Syzkaller, logs are listed below.
divide error in pm2fb_check_var
Call Trace:
<TASK>
fb_set_var+0x367/0xeb0 drivers/video/fbdev/core/fbmem.c:1015
do_fb_ioctl+0x234/0x670 drivers/video/fbdev/core/fbmem.c:1110
fb_ioctl+0xdd/0x130 drivers/video/fbdev/core/fbmem.c:1189 |
| Evervault is a payment security solution. A vulnerability was identified in the `evervault-go` SDK’s attestation verification logic in versions of `evervault-go` prior to 1.3.2 that may allow incomplete documents to pass validation. This may cause the client to trust an enclave operator that does not meet expected integrity guarantees. The exploitability of this issue is limited in Evervault-hosted environments as an attacker would require the pre-requisite ability to serve requests from specific evervault domain names, following from our ACME challenge based TLS certificate acquisition pipeline. The vulnerability primarily affects applications which only check PCR8. Though the efficacy is also reduced for applications that check all PCR values, the impact is largely remediated by checking PCR 0, 1 and 2. The identified issue has been addressed in version 1.3.2 by validating attestation documents before storing in the cache, and replacing the naive equality checks with a new SatisfiedBy check. Those who useevervault-go to attest Enclaves that are hosted outside of Evervault environments and cannot upgrade have two possible workarounds available. Modify the application logic to fail verification if PCR8 is not explicitly present and non-empty and/or add custom pre-validation to reject documents that omit any required PCRs. |
