| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In the Linux kernel, the following vulnerability has been resolved:
f2fs: fix return value of f2fs_recover_fsync_data()
With below scripts, it will trigger panic in f2fs:
mkfs.f2fs -f /dev/vdd
mount /dev/vdd /mnt/f2fs
touch /mnt/f2fs/foo
sync
echo 111 >> /mnt/f2fs/foo
f2fs_io fsync /mnt/f2fs/foo
f2fs_io shutdown 2 /mnt/f2fs
umount /mnt/f2fs
mount -o ro,norecovery /dev/vdd /mnt/f2fs
or
mount -o ro,disable_roll_forward /dev/vdd /mnt/f2fs
F2FS-fs (vdd): f2fs_recover_fsync_data: recovery fsync data, check_only: 0
F2FS-fs (vdd): Mounted with checkpoint version = 7f5c361f
F2FS-fs (vdd): Stopped filesystem due to reason: 0
F2FS-fs (vdd): f2fs_recover_fsync_data: recovery fsync data, check_only: 1
Filesystem f2fs get_tree() didn't set fc->root, returned 1
------------[ cut here ]------------
kernel BUG at fs/super.c:1761!
Oops: invalid opcode: 0000 [#1] SMP PTI
CPU: 3 UID: 0 PID: 722 Comm: mount Not tainted 6.18.0-rc2+ #721 PREEMPT(voluntary)
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
RIP: 0010:vfs_get_tree.cold+0x18/0x1a
Call Trace:
<TASK>
fc_mount+0x13/0xa0
path_mount+0x34e/0xc50
__x64_sys_mount+0x121/0x150
do_syscall_64+0x84/0x800
entry_SYSCALL_64_after_hwframe+0x76/0x7e
RIP: 0033:0x7fa6cc126cfe
The root cause is we missed to handle error number returned from
f2fs_recover_fsync_data() when mounting image w/ ro,norecovery or
ro,disable_roll_forward mount option, result in returning a positive
error number to vfs_get_tree(), fix it. |
| In the Linux kernel, the following vulnerability has been resolved:
f2fs: fix to avoid updating compression context during writeback
Bai, Shuangpeng <[email protected]> reported a bug as below:
Oops: divide error: 0000 [#1] SMP KASAN PTI
CPU: 0 UID: 0 PID: 11441 Comm: syz.0.46 Not tainted 6.17.0 #1 PREEMPT(full)
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
RIP: 0010:f2fs_all_cluster_page_ready+0x106/0x550 fs/f2fs/compress.c:857
Call Trace:
<TASK>
f2fs_write_cache_pages fs/f2fs/data.c:3078 [inline]
__f2fs_write_data_pages fs/f2fs/data.c:3290 [inline]
f2fs_write_data_pages+0x1c19/0x3600 fs/f2fs/data.c:3317
do_writepages+0x38e/0x640 mm/page-writeback.c:2634
filemap_fdatawrite_wbc mm/filemap.c:386 [inline]
__filemap_fdatawrite_range mm/filemap.c:419 [inline]
file_write_and_wait_range+0x2ba/0x3e0 mm/filemap.c:794
f2fs_do_sync_file+0x6e6/0x1b00 fs/f2fs/file.c:294
generic_write_sync include/linux/fs.h:3043 [inline]
f2fs_file_write_iter+0x76e/0x2700 fs/f2fs/file.c:5259
new_sync_write fs/read_write.c:593 [inline]
vfs_write+0x7e9/0xe00 fs/read_write.c:686
ksys_write+0x19d/0x2d0 fs/read_write.c:738
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0xf7/0x470 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
The bug was triggered w/ below race condition:
fsync setattr ioctl
- f2fs_do_sync_file
- file_write_and_wait_range
- f2fs_write_cache_pages
: inode is non-compressed
: cc.cluster_size =
F2FS_I(inode)->i_cluster_size = 0
- tag_pages_for_writeback
- f2fs_setattr
- truncate_setsize
- f2fs_truncate
- f2fs_fileattr_set
- f2fs_setflags_common
- set_compress_context
: F2FS_I(inode)->i_cluster_size = 4
: set_inode_flag(inode, FI_COMPRESSED_FILE)
- f2fs_compressed_file
: return true
- f2fs_all_cluster_page_ready
: "pgidx % cc->cluster_size" trigger dividing 0 issue
Let's change as below to fix this issue:
- introduce a new atomic type variable .writeback in structure f2fs_inode_info
to track the number of threads which calling f2fs_write_cache_pages().
- use .i_sem lock to protect .writeback update.
- check .writeback before update compression context in f2fs_setflags_common()
to avoid race w/ ->writepages. |
| In the Linux kernel, the following vulnerability has been resolved:
sched/deadline: only set free_cpus for online runqueues
Commit 16b269436b72 ("sched/deadline: Modify cpudl::free_cpus
to reflect rd->online") introduced the cpudl_set/clear_freecpu
functions to allow the cpu_dl::free_cpus mask to be manipulated
by the deadline scheduler class rq_on/offline callbacks so the
mask would also reflect this state.
Commit 9659e1eeee28 ("sched/deadline: Remove cpu_active_mask
from cpudl_find()") removed the check of the cpu_active_mask to
save some processing on the premise that the cpudl::free_cpus
mask already reflected the runqueue online state.
Unfortunately, there are cases where it is possible for the
cpudl_clear function to set the free_cpus bit for a CPU when the
deadline runqueue is offline. When this occurs while a CPU is
connected to the default root domain the flag may retain the bad
state after the CPU has been unplugged. Later, a different CPU
that is transitioning through the default root domain may push a
deadline task to the powered down CPU when cpudl_find sees its
free_cpus bit is set. If this happens the task will not have the
opportunity to run.
One example is outlined here:
https://lore.kernel.org/lkml/[email protected]
Another occurs when the last deadline task is migrated from a
CPU that has an offlined runqueue. The dequeue_task member of
the deadline scheduler class will eventually call cpudl_clear
and set the free_cpus bit for the CPU.
This commit modifies the cpudl_clear function to be aware of the
online state of the deadline runqueue so that the free_cpus mask
can be updated appropriately.
It is no longer necessary to manage the mask outside of the
cpudl_set/clear functions so the cpudl_set/clear_freecpu
functions are removed. In addition, since the free_cpus mask is
now only updated under the cpudl lock the code was changed to
use the non-atomic __cpumask functions. |
| In the Linux kernel, the following vulnerability has been resolved:
ntfs: set dummy blocksize to read boot_block when mounting
When mounting, sb->s_blocksize is used to read the boot_block without
being defined or validated. Set a dummy blocksize before attempting to
read the boot_block.
The issue can be triggered with the following syz reproducer:
mkdirat(0xffffffffffffff9c, &(0x7f0000000080)='./file1\x00', 0x0)
r4 = openat$nullb(0xffffffffffffff9c, &(0x7f0000000040), 0x121403, 0x0)
ioctl$FS_IOC_SETFLAGS(r4, 0x40081271, &(0x7f0000000980)=0x4000)
mount(&(0x7f0000000140)=@nullb, &(0x7f0000000040)='./cgroup\x00',
&(0x7f0000000000)='ntfs3\x00', 0x2208004, 0x0)
syz_clone(0x88200200, 0x0, 0x0, 0x0, 0x0, 0x0)
Here, the ioctl sets the bdev block size to 16384. During mount,
get_tree_bdev_flags() calls sb_set_blocksize(sb, block_size(bdev)),
but since block_size(bdev) > PAGE_SIZE, sb_set_blocksize() leaves
sb->s_blocksize at zero.
Later, ntfs_init_from_boot() attempts to read the boot_block while
sb->s_blocksize is still zero, which triggers the bug.
[[email protected]: changed comment style, added
return value handling] |
| In the Linux kernel, the following vulnerability has been resolved:
f2fs: invalidate dentry cache on failed whiteout creation
F2FS can mount filesystems with corrupted directory depth values that
get runtime-clamped to MAX_DIR_HASH_DEPTH. When RENAME_WHITEOUT
operations are performed on such directories, f2fs_rename performs
directory modifications (updating target entry and deleting source
entry) before attempting to add the whiteout entry via f2fs_add_link.
If f2fs_add_link fails due to the corrupted directory structure, the
function returns an error to VFS, but the partial directory
modifications have already been committed to disk. VFS assumes the
entire rename operation failed and does not update the dentry cache,
leaving stale mappings.
In the error path, VFS does not call d_move() to update the dentry
cache. This results in new_dentry still pointing to the old inode
(new_inode) which has already had its i_nlink decremented to zero.
The stale cache causes subsequent operations to incorrectly reference
the freed inode.
This causes subsequent operations to use cached dentry information that
no longer matches the on-disk state. When a second rename targets the
same entry, VFS attempts to decrement i_nlink on the stale inode, which
may already have i_nlink=0, triggering a WARNING in drop_nlink().
Example sequence:
1. First rename (RENAME_WHITEOUT): file2 → file1
- f2fs updates file1 entry on disk (points to inode 8)
- f2fs deletes file2 entry on disk
- f2fs_add_link(whiteout) fails (corrupted directory)
- Returns error to VFS
- VFS does not call d_move() due to error
- VFS cache still has: file1 → inode 7 (stale!)
- inode 7 has i_nlink=0 (already decremented)
2. Second rename: file3 → file1
- VFS uses stale cache: file1 → inode 7
- Tries to drop_nlink on inode 7 (i_nlink already 0)
- WARNING in drop_nlink()
Fix this by explicitly invalidating old_dentry and new_dentry when
f2fs_add_link fails during whiteout creation. This forces VFS to
refresh from disk on subsequent operations, ensuring cache consistency
even when the rename partially succeeds.
Reproducer:
1. Mount F2FS image with corrupted i_current_depth
2. renameat2(file2, file1, RENAME_WHITEOUT)
3. renameat2(file3, file1, 0)
4. System triggers WARNING in drop_nlink() |
| A security vulnerability has been detected in Public Knowledge Project omp and ojs 3.3.0/3.4.0/3.5.0. Impacted is an unknown function of the file plugins/paymethod/manual/templates/paymentForm.tpl of the component Payment Instructions Setting Handler. The manipulation of the argument manualInstructions leads to cross site scripting. The attack can be initiated remotely. You should upgrade the affected component. |
| A Reflected Cross-Site Scripting (XSS) vulnerability was discovered in the /publix/run endpoint of JATOS 3.7.1 through 3.9.6 (inclusive). This allows remote attackers to execute arbitrary JavaScript in a user's web browser by including a malicious payload in the "code" URL parameter. When an authenticated admin user accesses the study's URL, the malicious script gets interpreted and executes within their browser, which can lead to unauthorized actions, account compromise, and privilege escalation. |
| VTun-ng is a Virtual Tunnel over TCP/IP network. In versions 3.0.17 and below, failure to initialize encryption modules might cause reversion to plaintext due to insufficient error handling. The bug was first introduced in VTun-ng version 3.0.12. This is fixed in version 3.0.18. To workaround this issue, avoid blowfish-256. |
| onion-site-template is a complete, scalable tor hidden service self-hosting sample. Versions which include commit 3196bd89 contain a baked-in tor image if the secrets were copied from an existing onion domain. A website could be compromised if a user shared the baked-in image, or if someone were able to acquire access to the user's device outside of a containerized environment. This is fixed by commit bc9ba0fd. |
| RISC Zero is a zero-knowledge verifiable general computing platform based on zk-STARKs and the RISC-V microarchitecture. RISC packages risc0-zkvm versions 2.0.0 through 2.1.0 and risc0-circuit-rv32im and risc0-circuit-rv32im-sys versions 2.0.0 through 2.0.4 contain vulnerabilities where signed integer division allows multiple outputs for certain inputs with only one being valid, and division by zero results are underconstrained. This issue is fixed in risc0-zkvm version 2.2.0 and version 3.0.0 for the risc0-circuit-rv32im and risc0-circuit-rv32im-sys packages. |
| The Janssen Project is an open-source identity and access management (IAM) platform. In versions 1.9.0 and below, Janssen stores passwords in plaintext in the local cli_cmd.log file. This is fixed in the nightly prerelease. |
| Vision UI is a collection of enterprise-grade, dependency-free modules for modern web projects. In versions 1.4.0 and below, the generateSecureId and getSecureRandomInt functions in security-kit versions prior to 3.5.0 (packaged in Vision UI 1.4.0 and below) are vulnerable to Denial of Service (DoS) attacks. The generateSecureId(length) function directly used the length parameter to size a Uint8Array buffer, allowing attackers to exhaust server memory through repeated requests for large IDs since the previous 1024 limit was insufficient. The getSecureRandomInt(min, max) function calculated buffer size based on the range between min and max, where large ranges caused excessive memory allocation and CPU-intensive rejection-sampling loops that could hang the thread. This issue is fixed in version 1.5.0. |
| traQ is a messenger application built for Digital Creators Club traP. Prior to version 3.25.0, a vulnerability exists where sensitive information, such as OAuth tokens, are recorded in log files when an error occurs during the execution of an SQL query. An attacker could intentionally trigger an SQL error by methods such as placing a high load on the database. This could allow an attacker who has the authority to view the log files to illicitly acquire the recorded sensitive information. This vulnerability has been patched in version 3.25.0. If upgrading is not possible, a temporary workaround involves reviewing access permissions for SQL error logs and strictly limiting access to prevent unauthorized users from viewing them. |
| color-string is a parser and generator for CSS color strings. On 8 September 2025, the npm publishing account for color-string was taken over after a phishing attack. Version 2.1.1 was published, functionally identical to the previous patch version, but with a malware payload added attempting to redirect cryptocurrency transactions to the attacker's own addresses from within browser environments. Local environments, server environments, command line applications, etc. are not affected. If the package was used in a browser context (e.g. a direct <script> inclusion, or via a bundling tool such as Babel, Rollup, Vite, Next.js, etc.) there is a chance the malware still exists and such bundles will need to be rebuilt. The malware seemingly only targets cryptocurrency transactions and wallets such as MetaMask. npm removed the offending package from the registry over the course of the day on 8 September. On 13 September, the package owner published new patch versions to help cache-bust those using private registries who might still have the compromised version cached. This issue has been resolved in 2.1.2. |
| OS command injection vulnerability exists in network storage servers STEALTHONE D220/D340/D440 provided by Y'S corporation. A user with an administrative privilege who logged in to the web management page of the affected product may execute an arbitrary OS command. |
| A vulnerability in the management interface access control list (ACL) processing feature in Cisco IOS XR Software could allow an unauthenticated, remote attacker to bypass configured ACLs for the SSH, NetConf, and gRPC features.
This vulnerability exists because management interface ACLs have not been supported on Cisco IOS XR Software Packet I/O infrastructure platforms for Linux-handled features such as SSH, NetConf, or gRPC. An attacker could exploit this vulnerability by attempting to send traffic to an affected device. A successful exploit could allow the attacker to bypass an ingress ACL that is applied on the management interface of the affected device. |
| A double free vulnerability has been identified in the ASUS System Analysis service. This vulnerability can be triggered by sending specially crafted local RPC requests, leading to the service crash and potentially memory manipulation in some rare circumstances.
Refer to the 'Security Update for MyASUS' section on the ASUS Security Advisory for more information. |
| A vulnerability was found in Roxy-WI up to 8.1.3. It has been declared as critical. Affected by this vulnerability is the function action_service of the file app/modules/roxywi/roxy.py. The manipulation of the argument action/service leads to os command injection. The attack can be launched remotely. The exploit has been disclosed to the public and may be used. Upgrading to version 8.1.4 is able to address this issue. The identifier of the patch is 32313928eb9ce906887b8a30bf7b9a3d5c0de1be. It is recommended to upgrade the affected component. |
| Karmada is a Kubernetes management system that allows users to run cloud-native applications across multiple Kubernetes clusters and clouds. Prior to version 1.12.0, the PULL mode clusters registered with the `karmadactl register` command have excessive privileges to access control plane resources. By abusing these permissions, an attacker able to authenticate as the karmada-agent to a karmada cluster would be able to obtain administrative privileges over the entire federation system including all registered member clusters. Since Karmada v1.12.0, command `karmadactl register` restricts the access permissions of pull mode member clusters to control plane resources. This way, an attacker able to authenticate as the karmada-agent cannot control other member clusters in Karmada. As a workaround, one may restrict the access permissions of pull mode member clusters to control plane resources according to Karmada Component Permissions Docs. |
| Karmada is a Kubernetes management system that allows users to run cloud-native applications across multiple Kubernetes clusters and clouds. Prior to version 1.12.0, both in karmadactl and karmada-operator, it is possible to supply a filesystem path, or an HTTP(s) URL to retrieve the custom resource definitions(CRDs) needed by Karmada. The CRDs are downloaded as a gzipped tarfile and are vulnerable to a TarSlip vulnerability. An attacker able to supply a malicious CRD file into a Karmada initialization could write arbitrary files in arbitrary paths of the filesystem. From Karmada version 1.12.0, when processing custom CRDs files, CRDs archive verification is utilized to enhance file system robustness. A workaround is available. Someone who needs to set flag `--crd` to customize the CRD files required for Karmada initialization when using `karmadactl init` to set up Karmada can manually inspect the CRD files to check whether they contain sequences such as `../` that would alter file paths, to determine if they potentially include malicious files. When using karmada-operator to set up Karmada, one must upgrade one's karmada-operator to one of the fixed versions. |
