| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Unchecked Return Value vulnerability in ash-project ash_postgres allows a user who can drive a tenant rename to a name that collides with an existing tenant's schema to have their tenant record repointed at that other tenant's live schema, gaining access to its data.
AshPostgres.MultiTenancy.rename_tenant/3 issues the ALTER SCHEMA ... RENAME TO ... with the non-raising Ecto.Adapters.SQL.query/2, discards its {:ok, _} | {:error, _} result, and unconditionally returns :ok. PostgreSQL rejects the rename when the target schema already exists (and on insufficient privilege or lock timeout), but that failure never reaches the caller. The calling manage_tenant update action therefore sees success and commits the tenant row with the new name, which is the schema of a different existing tenant, so subsequent reads and writes for that tenant run against the other tenant's data.
This issue affects ash_postgres: from 0.25.0 before 2.13.0. |
| In the Linux kernel, the following vulnerability has been resolved:
perf sched: Fix register_pid() overflow, strcpy, and BUG_ON
register_pid() has several issues when processing untrusted perf.data:
1. Integer overflow: (pid + 1) * sizeof(struct task_desc *) can wrap
to a small value on 32-bit systems when pid is large (e.g.
0x40000000), causing realloc to return a tiny buffer followed by
out-of-bounds writes in the initialization loop.
2. Heap buffer overflow: strcpy(task->comm, comm) copies the
untrusted comm string into a fixed 20-byte COMM_LEN buffer with
no length check.
3. BUG_ON on allocation failure: perf.data is untrusted input, so
allocation failures should be handled gracefully rather than
killing the process.
4. Realloc of sched->tasks assigned directly back, leaking the old
pointer on failure; nr_tasks incremented before the realloc,
leaving corrupted state on failure.
Cap pid at PID_MAX_LIMIT (4194304, matching the kernel's maximum
on 64-bit), replace strcpy with strlcpy, guard against NULL comm,
replace BUG_ON with NULL returns using safe realloc patterns, and
add NULL checks in callers that dereference the result. |
| Nokogiri versions before 1.19.1 fail to check the return value from xmlC14NExecute in the canonicalize method, returning an empty string on failure instead of raising an exception. Attackers can exploit this to bypass signature validation in downstream SAML libraries by providing invalid canonicalized XML that is incorrectly accepted as valid. |
| tor before 0.4.9.9 was prone to a NULL write after free when sending a CONFLUX_SWITCH cell fails. The return value of relay_send_command_from_edge() was ignored, so a send failure (which calls circuit_mark_for_close() and removes the leg via cfx_del_leg()) would go undetected, causing the caller to write to the now-freed current leg and resulting in a crash. This is TROVE-2026-017. |
| In the Linux kernel, the following vulnerability has been resolved:
xfs: don't swallow dquot recovery verification errors
xlog_recover_dquot_commit_pass2() validates the recovered dquot with
xfs_dqblk_verify() and, on failure, sets error = -EFSCORRUPTED and jumps
to out_release. But out_release unconditionally returns 0, so the
corruption error is discarded: the caller xlog_recover_items_pass2()
sees success, log recovery proceeds as if the dquot were valid, and the
corrupt quota buffer can be written back to disk. |
| HAProxy Community Edition 3.2.x through 3.3.x before 3.3.3 can enter a loop or crash because varint is mishandled. HAProxy Enterprise and ALOHA are also affected. |
| In the Linux kernel, the following vulnerability has been resolved:
media: mtk-vcodec: potential null pointer deference in SCP
The return value of devm_kzalloc() needs to be checked to avoid
NULL pointer deference. This is similar to CVE-2022-3113. |
| In the Linux kernel, the following vulnerability has been resolved:
apparmor: fail policy unpack on accept2 allocation failure
unpack_pdb() may need to allocate a missing ACCEPT2 table for older policy
data. If that allocation failed, it set an error message but jumped to the
success path, returning a policydb with the required table missing.
Return -ENOMEM through the normal failure path when the ACCEPT2 allocation
fails. Remove the now-unused out label. |
| In the Linux kernel, the following vulnerability has been resolved:
RDMA/bnxt_re: Proper rollback if the ioremap fails
bnxt_qplib_alloc_dpi returns success even if ioremap fails.
Add the proper rollback when the ioremap fails and return
-ENOMEM status. |
| In the Linux kernel, the following vulnerability has been resolved:
ext2: fix ignored return value of generic_write_sync()
Fix ext2_dio_write_iter() to propagate the error returned by
generic_write_sync() instead of silently discarding it, which could
cause write(2) to return success to userspace on O_SYNC/O_DSYNC files
even when the sync failed.
The correct pattern, already used in ext2_dax_write_iter() in the same
file and in ext4, xfs, f2fs among others, is:
if (ret > 0)
ret = generic_write_sync(iocb, ret);
Found by Linux Verification Center (linuxtesting.org) with SVACE.
[JK: Reflect also filemap_write_and_wait() return value] |
| In the Linux kernel, the following vulnerability has been resolved:
tipc: fix infinite loop in __tipc_nl_compat_dumpit
cmd->dumpit callback can return a negative errno, causing an infinite
loop due to the while(len) condition. As the loop never terminates,
genl_mutex is never released, and other tasks waiting on it starve in D
state.
Check dumpit's return value, propagate it and jump to err_out on error. |
| MyBB is free and open source forum software. Prior to 1.8.40, the User CP Buddy/Ignore List component does not validate reciprocal buddy-list updates correctly. The usercp.php?action=do_editlists delete handler removes the selected entry from the acting user's list and then updates mybb_users.buddylist for the target account. The reciprocal update searches for the deleted target UID instead of the acting user's UID and uses the unchecked array_search() return value as an array key. A false result can be converted to index 0, removing the target account's first stored buddy while leaving the actual reciprocal entry unchanged. The uniquely identifying implementation details include false converted to index 0. This issue is fixed in version 1.8.40. |
| In the Linux kernel, the following vulnerability has been resolved:
ntfs: sanitize MFT references returned from ntfs_lookup_inode_by_name()
ntfs_lookup_inode_by_name() returns MFT references read from directory
index entries on disk. These values are untrusted, but the function can
currently return an error-marked MFT reference to its callers without
validating it.
Callers later decode lookup failures with MREF_ERR(). A crafted NTFS image
can set the MREF error bit while leaving the low bits as an arbitrary
value, causing callers to consume a bogus pseudo-errno instead of treating
the lookup result as corrupted on-disk metadata.
Fix this at the source by normalizing every error-marked MFT reference
returned from ntfs_lookup_inode_by_name() to ERR_MREF(-EIO). Apply this to
all four directory lookup return paths so every caller gets a validated
result without needing additional checks or an API change.
This keeps the sanitization in the common lookup helper, which is cleaner
than duplicating validation in each caller. |
| Uncaught exception in .NET allows an authorized attacker to elevate privileges locally. |
| In the Linux kernel, the following vulnerability has been resolved:
mm/compaction: handle free_pages_prepare() properly in compaction_free()
free_pages_prepare() can fail but compaction_free() does not handle the
failure case. Failed pages should not be added back to cc->freepages for
future use, since they can be either PageHWPoison or free_page_is_bad()
and might cause data corruption. |
| In the Linux kernel, the following vulnerability has been resolved:
ext4: fix kernel BUG in ext4_write_inline_data_end
When the data=journal mount option is used, the ext4_journalled_write_end()
function incorrectly calls ext4_write_inline_data_end() without checking
if the EXT4_STATE_MAY_INLINE_DATA flag is still set on the inode.
If a previous attempt to convert the inline data to an extent failed (e.g.
due to ENOSPC), the EXT4_STATE_MAY_INLINE_DATA flag is cleared, but
the EXT4_INODE_INLINE_DATA flag remains set. In this scenario, the next
call to ext4_write_begin() will not prepare the inline data xattr for
writing, but ext4_journalled_write_end() will incorrectly attempt to write
to it, triggering a BUG_ON(pos + len > EXT4_I(inode)->i_inline_size) in
ext4_write_inline_data() since i_inline_size was not expanded.
Fix this by ensuring that ext4_journalled_write_end() only calls
ext4_write_inline_data_end() if the EXT4_STATE_MAY_INLINE_DATA flag is
set, mirroring the behavior of ext4_write_end() and ext4_da_write_end(). |
| In the Linux kernel, the following vulnerability has been resolved:
drm/xe: Return error on non-migratable faults requiring devmem
Non-migratable faults that require devmem incorrectly jump to the 'out'
label, which squashes the error code intended to be returned to the
upper layers. Fix this by returning -EACCES instead.
(cherry picked from commit c4508edb2c723de93717272488ea65b165637eac) |
| In the Linux kernel, the following vulnerability has been resolved:
riscv: mm: Unconditionally sfence.vma for spurious fault
Svvptc does not guarantee that it's safe to just return here. Since we
have already cleared our bit, if, theoretically, the bounded timeframe
for the accessed page to become valid still hasn't happened after sret,
we could fault again and actually crash.
Hopefully, these spurious faults should be rare enough that this is an
acceptable slowdown. |
| When using the "tarfile" module with a file opened in "streaming mode" (mode="r|") the tarfile module did not properly handle EOF, making archive parsing take exponentially longer. |
| In the Linux kernel, the following vulnerability has been resolved:
crypto: tegra - do not transfer req when tegra init fails
The tegra_cmac_init or tegra_sha_init function may return an error when
memory is exhausted. It should not transfer the request when they return
an error. |
