| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In the Linux kernel, the following vulnerability has been resolved:
btrfs: fix removed dentries still existing after log is synced
When we move one inode from one directory to another and both the inode
and its previous parent directory were logged before, we are not supposed
to have the dentry for the old parent if we have a power failure after the
log is synced. Only the new dentry is supposed to exist.
Generally this works correctly, however there is a scenario where this is
not currently working, because the old parent of the file/directory that
was moved is not authoritative for a range that includes the dir index and
dir item keys of the old dentry. This case is better explained with the
following example and reproducer:
# The test requires a very specific layout of keys and items in the
# fs/subvolume btree to trigger the bug. So we want to make sure that
# on whatever platform we are, we have the same leaf/node size.
#
# Currently in btrfs the node/leaf size can not be smaller than the page
# size (but it can be greater than the page size). So use the largest
# supported node/leaf size (64K).
$ mkfs.btrfs -f -n 65536 /dev/sdc
$ mount /dev/sdc /mnt
# "testdir" is inode 257.
$ mkdir /mnt/testdir
$ chmod 755 /mnt/testdir
# Create several empty files to have the directory "testdir" with its
# items spread over several leaves (7 in this case).
$ for ((i = 1; i <= 1200; i++)); do
echo -n > /mnt/testdir/file$i
done
# Create our test directory "dira", inode number 1458, which gets all
# its items in leaf 7.
#
# The BTRFS_DIR_ITEM_KEY item for inode 257 ("testdir") that points to
# the entry named "dira" is in leaf 2, while the BTRFS_DIR_INDEX_KEY
# item that points to that entry is in leaf 3.
#
# For this particular filesystem node size (64K), file count and file
# names, we endup with the directory entry items from inode 257 in
# leaves 2 and 3, as previously mentioned - what matters for triggering
# the bug exercised by this test case is that those items are not placed
# in leaf 1, they must be placed in a leaf different from the one
# containing the inode item for inode 257.
#
# The corresponding BTRFS_DIR_ITEM_KEY and BTRFS_DIR_INDEX_KEY items for
# the parent inode (257) are the following:
#
# item 460 key (257 DIR_ITEM 3724298081) itemoff 48344 itemsize 34
# location key (1458 INODE_ITEM 0) type DIR
# transid 6 data_len 0 name_len 4
# name: dira
#
# and:
#
# item 771 key (257 DIR_INDEX 1202) itemoff 36673 itemsize 34
# location key (1458 INODE_ITEM 0) type DIR
# transid 6 data_len 0 name_len 4
# name: dira
$ mkdir /mnt/testdir/dira
# Make sure everything done so far is durably persisted.
$ sync
# Now do a change to inode 257 ("testdir") that does not result in
# COWing leaves 2 and 3 - the leaves that contain the directory items
# pointing to inode 1458 (directory "dira").
#
# Changing permissions, the owner/group, updating or adding a xattr,
# etc, will not change (COW) leaves 2 and 3. So for the sake of
# simplicity change the permissions of inode 257, which results in
# updating its inode item and therefore change (COW) only leaf 1.
$ chmod 700 /mnt/testdir
# Now fsync directory inode 257.
#
# Since only the first leaf was changed/COWed, we log the inode item of
# inode 257 and only the dentries found in the first leaf, all have a
# key type of BTRFS_DIR_ITEM_KEY, and no keys of type
# BTRFS_DIR_INDEX_KEY, because they sort after the former type and none
# exist in the first leaf.
#
# We also log 3 items that represent ranges for dir items and dir
# indexes for which the log is authoritative:
#
# 1) a key of type BTRFS_DIR_LOG_ITEM_KEY, which indicates the log is
# authoritative for all BTRFS_DIR_ITEM_KEY keys that have an offset
# in the range [0, 2285968570] (the offset here is th
---truncated--- |
| In the Linux kernel, the following vulnerability has been resolved:
dmaengine: idxd: clear MSIX permission entry on shutdown
Add disabling/clearing of MSIX permission entries on device shutdown to
mirror the enabling of the MSIX entries on probe. Current code left the
MSIX enabled and the pasid entries still programmed at device shutdown. |
| In the Linux kernel, the following vulnerability has been resolved:
x86/xen: Drop USERGS_SYSRET64 paravirt call
commit afd30525a659ac0ae0904f0cb4a2ca75522c3123 upstream.
USERGS_SYSRET64 is used to return from a syscall via SYSRET, but
a Xen PV guest will nevertheless use the IRET hypercall, as there
is no sysret PV hypercall defined.
So instead of testing all the prerequisites for doing a sysret and
then mangling the stack for Xen PV again for doing an iret just use
the iret exit from the beginning.
This can easily be done via an ALTERNATIVE like it is done for the
sysenter compat case already.
It should be noted that this drops the optimization in Xen for not
restoring a few registers when returning to user mode, but it seems
as if the saved instructions in the kernel more than compensate for
this drop (a kernel build in a Xen PV guest was slightly faster with
this patch applied).
While at it remove the stale sysret32 remnants.
[ pawan: Brad Spengler and Salvatore Bonaccorso <carnil@debian.org>
reported a problem with the 5.10 backport commit edc702b4a820
("x86/entry_64: Add VERW just before userspace transition").
When CONFIG_PARAVIRT_XXL=y, CLEAR_CPU_BUFFERS is not executed in
syscall_return_via_sysret path as USERGS_SYSRET64 is runtime
patched to:
.cpu_usergs_sysret64 = { 0x0f, 0x01, 0xf8,
0x48, 0x0f, 0x07 }, // swapgs; sysretq
which is missing CLEAR_CPU_BUFFERS. It turns out dropping
USERGS_SYSRET64 simplifies the code, allowing CLEAR_CPU_BUFFERS
to be explicitly added to syscall_return_via_sysret path. Below
is with CONFIG_PARAVIRT_XXL=y and this patch applied:
syscall_return_via_sysret:
...
<+342>: swapgs
<+345>: xchg %ax,%ax
<+347>: verw -0x1a2(%rip) <------
<+354>: sysretq
] |
| phpCAS is an authentication library that allows PHP applications to easily authenticate users via a Central Authentication Service (CAS) server. The phpCAS library uses HTTP headers to determine the service URL used to validate tickets. This allows an attacker to control the host header and use a valid ticket granted for any authorized service in the same SSO realm (CAS server) to authenticate to the service protected by phpCAS. Depending on the settings of the CAS server service registry in worst case this may be any other service URL (if the allowed URLs are configured to "^(https)://.*") or may be strictly limited to known and authorized services in the same SSO federation if proper URL service validation is applied. This vulnerability may allow an attacker to gain access to a victim's account on a vulnerable CASified service without victim's knowledge, when the victim visits attacker's website while being logged in to the same CAS server. phpCAS 1.6.0 is a major version upgrade that starts enforcing service URL discovery validation, because there is unfortunately no 100% safe default config to use in PHP. Starting this version, it is required to pass in an additional service base URL argument when constructing the client class. For more information, please refer to the upgrading doc. This vulnerability only impacts the CAS client that the phpCAS library protects against. The problematic service URL discovery behavior in phpCAS < 1.6.0 will only be disabled, and thus you are not impacted from it, if the phpCAS configuration has the following setup: 1. `phpCAS::setUrl()` is called (a reminder that you have to pass in the full URL of the current page, rather than your service base URL), and 2. `phpCAS::setCallbackURL()` is called, only when the proxy mode is enabled. 3. If your PHP's HTTP header input `X-Forwarded-Host`, `X-Forwarded-Server`, `Host`, `X-Forwarded-Proto`, `X-Forwarded-Protocol` is sanitized before reaching PHP (by a reverse proxy, for example), you will not be impacted by this vulnerability either. If your CAS server service registry is configured to only allow known and trusted service URLs the severity of the vulnerability is reduced substantially in its severity since an attacker must be in control of another authorized service. Otherwise, you should upgrade the library to get the safe service discovery behavior. |
| An issue was discovered on Phoenix Contact mGuard devices that have been updated to Version 8.4.0. When updating an mGuard device to Version 8.4.0 via the update-upload facility, the update will succeed, but it will reset the password of the admin user to its default value. |
| A vulnerability classified as critical was found in School Club Application System 1.0. This vulnerability affects a request to the file /scas/classes/Users.php?f=save_user. The manipulation with a POST request leads to privilege escalation. The attack can be initiated remotely and does not require authentication. The exploit has been disclosed to the public and may be used. |
| A vulnerability was found in SourceCodester Train Scheduler App 1.0 and classified as critical. Affected by this issue is some unknown functionality of the file /train_scheduler_app/?action=delete. The manipulation of the argument id leads to improper control of resource identifiers. The attack may be launched remotely. The identifier of this vulnerability is VDB-212504. |
| A vulnerability, which was classified as problematic, was found in CampCodes School Management Software 1.0. This affects an unknown part of the component Attachment Handler. The manipulation leads to improper control of resource identifiers. It is possible to initiate the attack remotely. The complexity of an attack is rather high. The exploitability is told to be difficult. The exploit has been disclosed to the public and may be used. |
| A vulnerability has been found in Control iD RH iD 25.2.25.0 and classified as problematic. This vulnerability affects unknown code of the file /v2/report.svc/comprovante_marcacao/?companyId=1 of the component PDF Document Handler. The manipulation of the argument nsr leads to improper control of resource identifiers. The attack can be initiated remotely. The vendor was contacted early about this disclosure but did not respond in any way. |
| A vulnerability was found in Benner ModernaNet up to 1.1.0. It has been declared as critical. This vulnerability affects unknown code of the file /AGE0000700/GetImageMedico?fooId=1. The manipulation of the argument fooId leads to improper control of resource identifiers. The attack can be initiated remotely. Upgrading to version 1.1.1 is able to address this issue. It is recommended to upgrade the affected component. |
| A vulnerability has been found in Campcodes Online Laundry Management System 1.0 and classified as critical. This vulnerability affects unknown code of the file manage_user.php of the component HTTP Request Parameter Handler. The manipulation of the argument id leads to improper control of resource identifiers. The attack can be initiated remotely. The exploit has been disclosed to the public and may be used. VDB-263938 is the identifier assigned to this vulnerability. |
| On sites that also had the Elementor plugin for WordPress installed, it was possible for users with the edit_posts capability, which includes Contributor-level users, to import blocks onto any page using the astra-page-elementor-batch-process AJAX action. An attacker could craft and host a block containing malicious JavaScript on a server they controlled, and then use it to overwrite any post or page by sending an AJAX request with the action set to astra-page-elementor-batch-process and the url parameter pointed to their remotely-hosted malicious block, as well as an id parameter containing the post or page to overwrite. Any post or page that had been built with Elementor, including published pages, could be overwritten by the imported block, and the malicious JavaScript in the imported block would then be executed in the browser of any visitors to that page. |
| A vulnerability, which was classified as problematic, has been found in projectsend up to r1605. This issue affects the function get_preview of the file process.php. The manipulation leads to improper control of resource identifiers. The attack may be initiated remotely. Upgrading to version r1720 is able to address this issue. The patch is named eb5a04774927e5855b9d0e5870a2aae5a3dc5a08. It is recommended to upgrade the affected component. |
| A vulnerability classified as critical was found in Abstrium Pydio Cells 4.2.0. This vulnerability affects unknown code of the component User Creation Handler. The manipulation leads to improper control of resource identifiers. The attack can be initiated remotely. The exploit has been disclosed to the public and may be used. Upgrading to version 4.2.1 is able to address this issue. It is recommended to upgrade the affected component. The identifier of this vulnerability is VDB-230212. |
| This CVE ID has been rejected or withdrawn by its CVE Numbering Authority. |
| This CVE ID has been rejected or withdrawn by its CVE Numbering Authority. |
| A vulnerability in the dashboard gadget rendering of Cisco Unified Intelligence Center could allow an unauthenticated, remote attacker to obtain or manipulate sensitive information between a user’s browser and Cisco Unified Intelligence Center. The vulnerability is due to the lack of gadget validation. An attacker could exploit this vulnerability by forcing a user to load a malicious gadget. A successful exploit could allow the attacker to obtain sensitive information, such as current user credentials, or manipulate data between the user’s browser and Cisco Unified Intelligence Center in the context of the malicious gadget. |
| A resource misdirection vulnerability in GitLab CE/EE versions 12.0 prior to 17.0.5, 17.1 prior to 17.1.3, and 17.2 prior to 17.2.1 allows an attacker to craft a repository import in such a way as to misdirect commits. |
|
Hitachi Vantara Pentaho Data Integration & Analytics versions before 9.5.0.1 and 9.3.0.5, including
8.3.x does not restrict JNDI identifiers during the creation of XActions, allowing control of system level data sources.
|
| SAP SQL Anywhere - version 17.0, allows an authenticated attacker to prevent legitimate users from accessing a SQL Anywhere database server by crashing the server with some queries that use indirect identifiers. |
