| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Liferay Portal 7.4.0 through 7.4.3.101, and Liferay DXP 2023.Q3.0 through 2023.Q3.4, 7.4 GA through update 92 and 7.3 GA though update 35 does not limit the number of objects returned from a GraphQL queries, which allows remote attackers to perform denial-of-service (DoS) attacks on the application by executing queries that return a large number of objects. |
| Open redirect vulnerability in the System Settings in Liferay Portal 7.1.0 through 7.4.3.101, and Liferay DXP 2023.Q3.1 through 2023.Q3.4 , 7.4 GA through update 92, 7.3 GA through update 35, and older unsupported versions allows remote attackers to redirect users to arbitrary external URLs via the _com_liferay_configuration_admin_web_portlet_SystemSettingsPortlet_redirect parameter.
Open redirect vulnerability in the Instance Settings in Liferay Portal 7.1.0 through 7.4.3.101, and Liferay DXP 2023.Q3.1 through 2023.Q3.4 , 7.4 GA through update 92, 7.3 GA through update 35, and older unsupported versions allows remote attackers to redirect users to arbitrary external URLs via the _com_liferay_configuration_admin_web_portlet_InstanceSettingsPortlet_redirect parameter.
Open redirect vulnerability in the Site Settings in Liferay Portal 7.1.0 through 7.4.3.101, and Liferay DXP 2023.Q3.1 through 2023.Q3.4 , 7.4 GA through update 92, 7.3 GA through update 35, and older unsupported versions allows remote attackers to redirect users to arbitrary external URLs via the _com_liferay_site_admin_web_portlet_SiteSettingsPortlet_redirect parameter. |
| Stored cross-site scripting (XSS) vulnerability in Liferay Portal 7.4.0 through 7.4.3.111, and older unsupported versions, and Liferay DXP 2023.Q4.0, 2023.Q3.1 through 2023.Q3.4, 7.4 GA through update 92, 7.3 GA through update 35, and older unsupported versions allows remote authenticated attackers with the instance administrator role to inject arbitrary web script or HTML into all pages via a crafted payload injected into the Instance Configuration's (1) CDN Host HTTP text field or (2) CDN Host HTTPS text field. |
| A Stored cross-site scripting vulnerability in the Liferay Portal 7.4.0 through 7.4.3.132, and Liferay DXP 2025.Q3.0, 2025.Q2.0 through 2025.Q2.12, 2025.Q1.0 through 2025.Q1.17, 2024.Q4.0 through 2024.Q4.7, 2024.Q3.0 through 2024.Q3.13, 2024.Q2.0 through 2024.Q2.13 and 2024.Q1.1 through 2024.Q1.20 allows an remote authenticated attacker to inject JavaScript through the organization site names. The malicious payload is stored and executed without proper sanitization or escaping. |
| An information exposure vulnerability in the Palo Alto Networks User-ID Credential Agent (Windows-based) can expose the service account password under specific non-default configurations. This allows an unprivileged Domain User to escalate privileges by exploiting the account’s permissions. The impact varies by configuration:
* Minimally Privileged Accounts: Enable disruption of User-ID Credential Agent operations (e.g., uninstalling or disabling the agent service), weakening network security policies that leverage Credential Phishing Prevention https://docs.paloaltonetworks.com/advanced-url-filtering/administration/url-filtering-features/credential-phishing-prevention under a Domain Credential Filter https://docs.paloaltonetworks.com/advanced-url-filtering/administration/url-filtering-features/credential-phishing-prevention/methods-to-check-for-corporate-credential-submissions configuration.
* Elevated Accounts (Server Operator, Domain Join, Legacy Features): Permit increased impacts, including server control (e.g., shutdown/restart), domain manipulation (e.g., rogue computer objects), and network compromise via reconnaissance or client probing. |
| A problem with the Palo Alto Networks Cortex XDR Microsoft 365 Defender Pack can result in exposure of user credentials in application logs. Normally, these application logs are only viewable by local users and are included when generating logs for troubleshooting purposes. This means that these credentials are exposed to recipients of the application logs. |
| In the Linux kernel, the following vulnerability has been resolved:
lib/crypto: arm64/poly1305: Fix register corruption in no-SIMD contexts
Restore the SIMD usability check that was removed by commit a59e5468a921
("crypto: arm64/poly1305 - Add block-only interface").
This safety check is cheap and is well worth eliminating a footgun.
While the Poly1305 functions should not be called when SIMD registers
are unusable, if they are anyway, they should just do the right thing
instead of corrupting random tasks' registers and/or computing incorrect
MACs. Fixing this is also needed for poly1305_kunit to pass.
Just use may_use_simd() instead of the original crypto_simd_usable(),
since poly1305_kunit won't rely on crypto_simd_disabled_for_test. |
| In the Linux kernel, the following vulnerability has been resolved:
lib/crypto: arm/poly1305: Fix register corruption in no-SIMD contexts
Restore the SIMD usability check that was removed by commit 773426f4771b
("crypto: arm/poly1305 - Add block-only interface").
This safety check is cheap and is well worth eliminating a footgun.
While the Poly1305 functions should not be called when SIMD registers
are unusable, if they are anyway, they should just do the right thing
instead of corrupting random tasks' registers and/or computing incorrect
MACs. Fixing this is also needed for poly1305_kunit to pass.
Just use may_use_simd() instead of the original crypto_simd_usable(),
since poly1305_kunit won't rely on crypto_simd_disabled_for_test. |
| In the Linux kernel, the following vulnerability has been resolved:
usb: dwc3: Remove WARN_ON for device endpoint command timeouts
This commit addresses a rarely observed endpoint command timeout
which causes kernel panic due to warn when 'panic_on_warn' is enabled
and unnecessary call trace prints when 'panic_on_warn' is disabled.
It is seen during fast software-controlled connect/disconnect testcases.
The following is one such endpoint command timeout that we observed:
1. Connect
=======
->dwc3_thread_interrupt
->dwc3_ep0_interrupt
->configfs_composite_setup
->composite_setup
->usb_ep_queue
->dwc3_gadget_ep0_queue
->__dwc3_gadget_ep0_queue
->__dwc3_ep0_do_control_data
->dwc3_send_gadget_ep_cmd
2. Disconnect
==========
->dwc3_thread_interrupt
->dwc3_gadget_disconnect_interrupt
->dwc3_ep0_reset_state
->dwc3_ep0_end_control_data
->dwc3_send_gadget_ep_cmd
In the issue scenario, in Exynos platforms, we observed that control
transfers for the previous connect have not yet been completed and end
transfer command sent as a part of the disconnect sequence and
processing of USB_ENDPOINT_HALT feature request from the host timeout.
This maybe an expected scenario since the controller is processing EP
commands sent as a part of the previous connect. It maybe better to
remove WARN_ON in all places where device endpoint commands are sent to
avoid unnecessary kernel panic due to warn. |
| In the Linux kernel, the following vulnerability has been resolved:
btrfs: abort transaction on unexpected eb generation at btrfs_copy_root()
If we find an unexpected generation for the extent buffer we are cloning
at btrfs_copy_root(), we just WARN_ON() and don't error out and abort the
transaction, meaning we allow to persist metadata with an unexpected
generation. Instead of warning only, abort the transaction and return
-EUCLEAN. |
| In the Linux kernel, the following vulnerability has been resolved:
ACPI: processor: perflib: Move problematic pr->performance check
Commit d33bd88ac0eb ("ACPI: processor: perflib: Fix initial _PPC limit
application") added a pr->performance check that prevents the frequency
QoS request from being added when the given processor has no performance
object. Unfortunately, this causes a WARN() in freq_qos_remove_request()
to trigger on an attempt to take the given CPU offline later because the
frequency QoS object has not been added for it due to the missing
performance object.
Address this by moving the pr->performance check before calling
acpi_processor_get_platform_limit() so it only prevents a limit from
being set for the CPU if the performance object is not present. This
way, the frequency QoS request is added as it was before the above
commit and it is present all the time along with the CPU's cpufreq
policy regardless of whether or not the CPU is online. |
| In the Linux kernel, the following vulnerability has been resolved:
NFS: Fix the setting of capabilities when automounting a new filesystem
Capabilities cannot be inherited when we cross into a new filesystem.
They need to be reset to the minimal defaults, and then probed for
again. |
| In the Linux kernel, the following vulnerability has been resolved:
net: lapbether: ignore ops-locked netdevs
Syzkaller managed to trigger lock dependency in xsk_notify via
register_netdevice. As discussed in [0], using register_netdevice
in the notifiers is problematic so skip adding lapbeth for ops-locked
devices.
xsk_notifier+0xa4/0x280 net/xdp/xsk.c:1645
notifier_call_chain+0xbc/0x410 kernel/notifier.c:85
call_netdevice_notifiers_info+0xbe/0x140 net/core/dev.c:2230
call_netdevice_notifiers_extack net/core/dev.c:2268 [inline]
call_netdevice_notifiers net/core/dev.c:2282 [inline]
unregister_netdevice_many_notify+0xf9d/0x2700 net/core/dev.c:12077
unregister_netdevice_many net/core/dev.c:12140 [inline]
unregister_netdevice_queue+0x305/0x3f0 net/core/dev.c:11984
register_netdevice+0x18f1/0x2270 net/core/dev.c:11149
lapbeth_new_device drivers/net/wan/lapbether.c:420 [inline]
lapbeth_device_event+0x5b1/0xbe0 drivers/net/wan/lapbether.c:462
notifier_call_chain+0xbc/0x410 kernel/notifier.c:85
call_netdevice_notifiers_info+0xbe/0x140 net/core/dev.c:2230
call_netdevice_notifiers_extack net/core/dev.c:2268 [inline]
call_netdevice_notifiers net/core/dev.c:2282 [inline]
__dev_notify_flags+0x12c/0x2e0 net/core/dev.c:9497
netif_change_flags+0x108/0x160 net/core/dev.c:9526
dev_change_flags+0xba/0x250 net/core/dev_api.c:68
devinet_ioctl+0x11d5/0x1f50 net/ipv4/devinet.c:1200
inet_ioctl+0x3a7/0x3f0 net/ipv4/af_inet.c:1001
0: https://lore.kernel.org/netdev/20250625140357.6203d0af@kernel.org/ |
| In the Linux kernel, the following vulnerability has been resolved:
block: avoid possible overflow for chunk_sectors check in blk_stack_limits()
In blk_stack_limits(), we check that the t->chunk_sectors value is a
multiple of the t->physical_block_size value.
However, by finding the chunk_sectors value in bytes, we may overflow
the unsigned int which holds chunk_sectors, so change the check to be
based on sectors. |
| In the Linux kernel, the following vulnerability has been resolved:
io_uring/memmap: cast nr_pages to size_t before shifting
If the allocated size exceeds UINT_MAX, then it's necessary to cast
the mr->nr_pages value to size_t to prevent it from overflowing. In
practice this isn't much of a concern as the required memory size will
have been validated upfront, and accounted to the user. And > 4GB sizes
will be necessary to make the lack of a cast a problem, which greatly
exceeds normal user locked_vm settings that are generally in the kb to
mb range. However, if root is used, then accounting isn't done, and
then it's possible to hit this issue. |
| In the Linux kernel, the following vulnerability has been resolved:
dm: Always split write BIOs to zoned device limits
Any zoned DM target that requires zone append emulation will use the
block layer zone write plugging. In such case, DM target drivers must
not split BIOs using dm_accept_partial_bio() as doing so can potentially
lead to deadlocks with queue freeze operations. Regular write operations
used to emulate zone append operations also cannot be split by the
target driver as that would result in an invalid writen sector value
return using the BIO sector.
In order for zoned DM target drivers to avoid such incorrect BIO
splitting, we must ensure that large BIOs are split before being passed
to the map() function of the target, thus guaranteeing that the
limits for the mapped device are not exceeded.
dm-crypt and dm-flakey are the only target drivers supporting zoned
devices and using dm_accept_partial_bio().
In the case of dm-crypt, this function is used to split BIOs to the
internal max_write_size limit (which will be suppressed in a different
patch). However, since crypt_alloc_buffer() uses a bioset allowing only
up to BIO_MAX_VECS (256) vectors in a BIO. The dm-crypt device
max_segments limit, which is not set and so default to BLK_MAX_SEGMENTS
(128), must thus be respected and write BIOs split accordingly.
In the case of dm-flakey, since zone append emulation is not required,
the block layer zone write plugging is not used and no splitting of BIOs
required.
Modify the function dm_zone_bio_needs_split() to use the block layer
helper function bio_needs_zone_write_plugging() to force a call to
bio_split_to_limits() in dm_split_and_process_bio(). This allows DM
target drivers to avoid using dm_accept_partial_bio() for write
operations on zoned DM devices. |
| The jQuery Colorbox WordPress plugin through 4.6.3 uses the colorbox library, which does not sanitize title attributes on links before using them, allowing users with at least the contributor role to conduct XSS attacks against administrators. |
| IBM PowerVM Hypervisor FW950.00 through FW950.E0, FW1050.00 through FW1050.50, and FW1060.00 through FW1060.40 could allow a local privileged user to cause a denial of service by issuing a specially crafted IBM i hypervisor call that would disclose memory contents or consume excessive memory resources. |
| Zabbix Agent 2 smartctl plugin does not properly sanitize smart.disk.get parameters, allowing an attacker to inject unexpected arguments into the smartctl command. In Zabbix 5.0 this allows for remote code execution. |
| Zabbix Agent 2 smartctl plugin does not properly sanitize smart.disk.get parameters, allowing an attacker to inject unexpected arguments into the smartctl command. This can be used to leak the NTLMv2 hash from a Windows system. |
