| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In the Linux kernel, the following vulnerability has been resolved:
bpf: Fix REG INVARIANTS VIOLATION on speculative pointer arithmetic
Take the following unprivileged program as an example:
r0 = bpf_map_lookup_elem(...) /* PTR_TO_MAP_VALUE, offset 0 */
...
14: r0 += r1 /* r1 is a bounded scalar */
15: r9 = r0
Loading it triggers a verifier warning from reg_bounds_sanity_check():
verifier bug: REG INVARIANTS VIOLATION (alu): const subreg tnum out
of sync with range bounds r64={.base=0x0, .size=0x0}
r32={.base=0x0, .size=0xffffffff} var_off=(0x0, 0x0)
What happens:
1. Processing insn 14 (r0 += r1) in adjust_ptr_min_max_vals(), the new
offset is computed into dst_reg's var_off and 32/64-bit ranges.
2. Because pointer registers do not track 32-bit subregister bounds,
__mark_reg32_unbounded() first sets r32 to the full range; r32 is
re-derived from the offset at the end of the function by
reg_bounds_sync().
3. On the unprivileged path, sanitize_ptr_alu() is called and, via
sanitize_speculative_path() -> push_stack(), snapshots the current
register state and schedules the next instruction (insn 15) to be
verified directly as a speculative path.
4. That snapshot is taken between step 2 and the final reg_bounds_sync():
at this point dst_reg's var_off still holds the (const) original
offset while r32 has just been blanked to the full range, i.e. the two
are out of sync. When the speculative path later verifies insn 15
(r9 = r0), the inconsistent state reaches reg_bounds_sanity_check() and
trips the warning.
var_off and the 32-bit range must always be consistent. There are two
ways to keep the snapshot consistent:
1. sync var_off and r32 before the snapshot so they match, or
2. leave r32 at its original (already consistent) value and blank it
only after the snapshot.
The whole point of sanitize_ptr_alu() is to insert a harmless masking
sequence that keeps the access in bounds under speculation, so the state
it snapshots should faithfully represent that. Take approach 2: move
__mark_reg32_unbounded() to after sanitize_ptr_alu(), so the speculative
snapshot keeps the pointer's original, consistent r32. The non-speculative
path is unchanged: r32 is still blanked before the offset is applied and
re-derived by reg_bounds_sync(). |
| An issue in nvbn thefuck v.3.32 allows a local attacker to execute arbitrary code via the get_rules_import_paths in thefuck/corrector.py and Rule.from_path in thefuck/types.py |
| LocalAI v4.6.0 through v4.11.0 contains a server-side request forgery vulnerability in core/gallery/gallery.go that validates only the initial gallery config URL. Attackers can submit a config URL through POST /models/apply that redirects to internal or cloud metadata addresses, receiving those internal responses as gallery content. |
| Trudesk through 1.2.11 contains a regular expression injection vulnerability that allows unauthenticated attackers to enumerate usernames by submitting regex patterns to POST /api/v1/login. Attackers can send alternations or prefixes like (admin|root) or a.* and distinguish 'Invalid User' from 'Invalid Password' responses to discover valid accounts. |
| Improper input validation in WebShare in Google Chrome prior to 156.0.8078.47 allowed a remote attacker to potentially execute arbitrary code inside the sandbox via a crafted HTML page. (Chromium security severity: Medium) |
| Memory corruption in PerformanceAPIs in Google Chrome prior to 156.0.8078.47 allowed a remote attacker to potentially execute arbitrary code inside the sandbox via a crafted HTML page. (Chromium security severity: Medium) |
| Memory corruption in Extensions in Google Chrome prior to 156.0.8078.47 allowed a remote attacker to potentially read memory inside the sandbox via a crafted HTML page. (Chromium security severity: Medium) |
| Use after free in Transactions Platform in Google Chrome prior to 156.0.8078.47 allowed a remote attacker to execute arbitrary code inside the sandbox via a crafted HTML page. (Chromium security severity: High) |
| Memory corruption in Autofill in Google Chrome prior to 156.0.8078.47 allowed a remote attacker to potentially read memory inside the sandbox via a crafted HTML page. (Chromium security severity: Medium) |
| Memory corruption in Extensions in Google Chrome prior to 156.0.8078.47 allowed a remote attacker to execute arbitrary code inside the sandbox via a crafted HTML page. (Chromium security severity: Medium) |
| Out of bounds read in Extensions in Google Chrome prior to 156.0.8078.47 allowed a remote attacker to read memory inside the sandbox via a crafted HTML page. (Chromium security severity: Medium) |
| Use after free in WindowControlsOverlay in Google Chrome prior to 156.0.8078.47 allowed a remote attacker to execute arbitrary code inside the sandbox via a crafted HTML page. (Chromium security severity: Medium) |
| A security vulnerability has been detected in leomoon-studios wiki-go up to 1.9.1. Affected by this issue is the function DeleteComment of the file internal/comments/comments.go of the component Comment Deletion Handler. The manipulation of the argument documentPath leads to path traversal. The attack may be initiated remotely. The exploit has been disclosed publicly and may be used. Upgrading to version 1.9.2 can resolve this issue. The identifier of the patch is 224ef2a11facddef6b3a3c1f0a69156d1e574a33. It is advisable to upgrade the affected component. |
| Grafana's data source proxy did not apply role-based access control to write requests forwarded to Loki data sources. A user holding only the Viewer role on an affected Grafana instance could send POST, PUT and DELETE requests through the proxy to the Loki rules API (/loki/api/v1/rules), allowing them to create, modify and delete Loki alerting rules. Because those rules are stored by Loki rather than by Grafana, the change took effect for every user of that Loki data source, not only for the Viewer who made the request.
Exploitation requires an authenticated Viewer account on the Grafana instance and a configured Loki data source; no other privileges are needed. Both Grafana OSS and Grafana Enterprise are affected. The defect is in Grafana's data source proxy; Loki itself is not vulnerable and does not need to be patched. |
| A server-side template injection exists in SolusVM 2 up to version 2.0.0-44576 that allows remote authenticated users to execute arbitrary code as root. |
| A missing authorization check in Nexus Repository 3's NuGet Components API upload path allows an account holding only repository read and browse privileges to upload and persist NuGet symbol packages (.snupkg) to a hosted repository, bypassing the write-permission check enforced for ordinary package uploads. Exploitation requires a hosted NuGet repository with Symbol Server enabled. If anonymous access is enabled, the built-in anonymous user holds read and browse privileges across all repositories by default, so this precondition can also be met without an authenticated account. |
| Sonatype Nexus Repository 3 allows a user account that holds the edit permission on a hosted R repository to store script content in the metadata of an uploaded R package. The script runs in the browser of a user who opens the details of that package in the Browse user interface, with the permissions of the viewing user. In this description, a user account means an account that has supplied valid credentials. The anonymous user, if enabled, is also a user account and can hold this permission if an administrator grants it. |
| Sonatype Nexus Repository 3 allows a user that holds the role create or role update permission to grant roles and privileges that the account does not hold. This can give the user more access than intended, up to full administrative access. |
| Improper limitation of a pathname to a restricted directory ('path traversal') in Microsoft Office SharePoint allows an authorized attacker to execute code over a network. |
| The Apache Airflow Keycloak auth manager did not end the session on logout: the logout route revoked the presented token, but `KeycloakJWTMiddleware` then issued a new, unrevoked token on the same response, so the user stayed logged in. Deployments using the Keycloak auth manager are affected: after a user logs out, anyone with later access to the same browser (for example on a shared workstation) can continue to act as that user.
Users of apache-airflow-providers-keycloak are recommended to upgrade to apache-airflow-providers-keycloak 0.11.1 or later. |
