| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In libarchive before 3.6.2, the software does not check for an error after calling calloc function that can return with a NULL pointer if the function fails, which leads to a resultant NULL pointer dereference. NOTE: the discoverer cites this CWE-476 remark but third parties dispute the code-execution impact: "In rare circumstances, when NULL is equivalent to the 0x0 memory address and privileged code can access it, then writing or reading memory is possible, which may lead to code execution." |
| An issue was discovered in the Linux kernel through 5.2.13. nbd_genl_status in drivers/block/nbd.c does not check the nla_nest_start_noflag return value. |
| mJobTime through build 15.7.3.32 contains an unauthenticated SQL execution vulnerability in the Login.aspx admin panel handlers, where the runQueryButton postback and exportSqlQuery_Server PageMethod execute caller-supplied SQL against the backing Sybase SQL Anywhere database using DBA/sysadmin privileges with no server-side authentication enforced beyond a client-side sessionStorage flag. Attackers can submit arbitrary SQL through these exposed endpoints to invoke xp_cmdshell and xp_read_file, achieving pre-authentication remote code execution as LocalSystem via a single HTTP request. |
| In the Linux kernel, the following vulnerability has been resolved:
ntfs: leave HasEA flag untouched on setxattr failure
In ntfs_set_ea(), the exit path unconditionally updates the HasEA
flag based on ea_info_qsize. When an error occurs before
ea_info_qsize is updated, NInoClearHasEA() hides existing on-disk
EAs until the inode is evicted.
Only update the flag on success. |
| In the Linux kernel, the following vulnerability has been resolved:
ntfs: only count successfully cleared runs when freeing clusters
ntfs_cluster_free_from_rl_nolock() adds a run's length to nr_freed
whenever the error bookkeeping condition is false, which includes
cases where ntfs_bitmap_clear_run() actually failed - e.g. a second
run failing with the same errno as an earlier one, or any failure
after a non-ENOMEM error was already recorded. Since a failed
ntfs_bitmap_clear_run() rolls back its partial modifications, no
bits were cleared for that run, yet its length still inflates
vol->free_clusters, corrupting statfs output and the allocator's
free space gate.
Only count runs whose bitmap clear succeeded. |
| RabbitMQ is a messaging and streaming broker. From 3.13.0 until 4.3.3, 4.2.9, 4.1.14, 4.0.23, and 3.13.18, JWKS Fetch Ignores HTTP Response Status Code - Signing Key Destruction Causes Authentication DoS (CWE-252). the JWKS key fetching mechanism in uaajwt.erl does not validate the HTTP response status code when downloading signing keys from the OAuth2 provider's JWKS endpoint. Non-200 responses (including 4xx and 5xx errors) are processed identically to successful responses. When the JWKS endpoint returns an error response with a valid-JSON body that lacks a keys field, all previously cached signing keys are destroyed, causing a persistent authentication denial of Files: deps/rabbitmqauthbackendoauth2/src/uaajwt.erl, lines 50-63 deps/rabbitmqauthbackendoauth2/src/uaajwks.erl, lines 5-7 deps/rabbitmqauthbackendoauth2/src/rabbitoauth2provider.erl, lines 98-107 Bug 1: HTTP status code ignored (uaajwt.erl:50-63): The Erlang httpc module returns {ok, {{HttpVersion, StatusCode, ReasonPhrase}, Headers, Body}}. The pattern {ok, {, , JwksBody}} matches ANY successful HTTP transaction Persistent authentication DoS: Once keys are destroyed, ALL OAuth2/JWT authentication fails for all users until a new successful JWKS refresh occurs Amplification: A single attacker can deny access to all legitimate OAuth2 users across the entire RabbitMQ. This issue is fixed in versions 4.3.3, 4.2.9, 4.1.14, 4.0.23, and 3.13.18. |
| A vulnerability has been identified within Rancher Manager where the Fleet agent wrote resources to downstream clusters using its own cluster-admin credentials instead of the ServiceAccount pinned to the deployment. It affects multi-tenancy environments where different tenants share the same downstream clusters, for example different privileged or untrusted teams inside the same organization. This could lead to overwritten configuration files.
This issue affected SUSE Rancher Fleet 0.16 before 0.16.2, 0.15 before 0.15.7, and 0.14 before 0.14.11. |
| A local privilege escalation vulnerability in Kiteworks could have allowed an attacker with an existing shell under a low-privileged service account to escalate to root privileges on the appliance. |
| Privilege elevation in Sandbox in Google Chrome on on Mac prior to 155.0.8059.39 allowed a remote attacker who had compromised the renderer process to execute arbitrary code outside the sandbox via a crafted HTML page. (Chromium security severity: Medium) |
| IBM Financial Transaction Manager (FTM) for RedHat OpenShift could allow a local attacker to achieve privilege escalation within the container due to improper privilege management. |
| Plane is an open-source project management tool. Prior to 1.4.0, aPITokenLogMiddleware logs API keys in plaintext. This allows someone with low privileges to steal user API keys and further escalate their privileges. This issue is fixed in 1.4.0. |
| A vulnerability was determined in SciPhi-AI R2R up to 3.6.6. This affects an unknown part of the component JWT Secret Handler. This manipulation of the argument DEFAULT_BCRYPT_SECRET_KEY/DEFAULT_NACL_SECRET_KEY causes hard-coded credentials. The attack can be initiated remotely. The exploit has been publicly disclosed and may be utilized. The vendor was contacted early about this disclosure but did not respond in any way. |
| A security flaw has been discovered in topoteretes cognee up to 1.5.4. The affected element is the function get_user_id_by_email of the file cognee/modules/users/authentication/get_api_auth_backend.py of the component JWT Signing Key Handler. The manipulation of the argument FASTAPI_USERS_JWT_SECRET results in hard-coded credentials. The attack may be launched remotely. Upgrading to version 1.6.0 is sufficient to fix this issue. The patch is identified as fa65fc0cd86cdba48d19aa76e36be862be982f5d. Upgrading the affected component is advised. |
| A flaw was found in olm-operator-konflux-sample. The `bundle-hack/update_bundle.sh` script lacks mechanisms to stop execution immediately upon encountering an error. This oversight allows critical data processing steps, such as those involving `skopeo` or `jq` commands, to fail silently and proceed with outdated or incomplete information. Consequently, this could lead to data integrity issues within the system. |
| In the Linux kernel, the following vulnerability has been resolved:
bnxt_en: Propagate RX ring init failures in bnxt_init_nic()
bnxt_init_rx_rings() returns an error when bnxt_alloc_one_rx_ring()
fails, but bnxt_init_nic() discards that return value and calls
bnxt_init_chip(), which enables TPA.
If an allocation fails, this could leave rxr->rx_tpa[] partially zeroed
and TPA would be enabled over an array with zeroed entries. This would
lead to a zeroed DMA address being handed out if the agg_idx is
translated to a SW index at a zeroed entry.
Fix this by propagating the error out of bnxt_init_nic(). Both callers
already check its return value and unwind with bnxt_free_skbs() and
bnxt_free_mem(), which tolerate a partially initialized RX ring. |
| In the Linux kernel, the following vulnerability has been resolved:
xfs: bail out on bitmap errors in xrep_agfl_fill
LOLLM also points out that the xagb_bitmap_set call in xrep_agfl_fill
can fail, but we don't check the result of xagb_bitmap_walk, so we
silently drop the error and proceed with inconsistent incore data.
That shouldn't be allowed. |
| In the Linux kernel, the following vulnerability has been resolved:
mptcp: fix bad accounting in __mptcp_subflow_push_pending()
If __subflow_push_pending() errors out we should avoid updating the
copied byte counters, to avoid mismatch push call later on. |
| In the Linux kernel, the following vulnerability has been resolved:
spi: spi-qcom-qspi: Fix incomplete error handling in runtime PM
The runtime PM functions had incomplete error handling that could leave the
system in an inconsistent state. If any operation failed midway through
suspend or resume, some resources would be left in the wrong state while
others were already changed, leading to potential clock/power imbalances.
Reorder the suspend/resume sequences to avoid brownout risk by ensuring the
performance state is set appropriately before clocks are enabled and clocks
are disabled before dropping the performance state.
Fix by adding proper error checking for all operations and using goto-based
cleanup to ensure all successfully acquired resources are properly released
on any error. |
| In the Linux kernel, the following vulnerability has been resolved:
ASoC: rockchip: rockchip_pdm: Handle runtime PM resume failures in set_fmt
rockchip_pdm_set_fmt() calls pm_runtime_get_sync() before accessing
hardware registers, but ignores its return value.
If the runtime resume fails, the function continues to perform register
accesses while the device state is undefined.
Replace pm_runtime_get_sync() with pm_runtime_resume_and_get() and
return early on failure to avoid unpowered register accesses. |
| 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. |
