| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Incorrect authorization in certain Zoom Workplace Clients for Windows may allow an authenticated user to conduct an impact to integrity via network access. |
| Cross-site scripting in certain Zoom Workplace Clients may allow an unauthenticated user to conduct a denial of service via network access. |
| In the Linux kernel, the following vulnerability has been resolved:
net: dsa: mv88e6xxx: don't use devres for mdiobus
As explained in commits:
74b6d7d13307 ("net: dsa: realtek: register the MDIO bus under devres")
5135e96a3dd2 ("net: dsa: don't allocate the slave_mii_bus using devres")
mdiobus_free() will panic when called from devm_mdiobus_free() <-
devres_release_all() <- __device_release_driver(), and that mdiobus was
not previously unregistered.
The mv88e6xxx is an MDIO device, so the initial set of constraints that
I thought would cause this (I2C or SPI buses which call ->remove on
->shutdown) do not apply. But there is one more which applies here.
If the DSA master itself is on a bus that calls ->remove from ->shutdown
(like dpaa2-eth, which is on the fsl-mc bus), there is a device link
between the switch and the DSA master, and device_links_unbind_consumers()
will unbind the Marvell switch driver on shutdown.
systemd-shutdown[1]: Powering off.
mv88e6085 0x0000000008b96000:00 sw_gl0: Link is Down
fsl-mc dpbp.9: Removing from iommu group 7
fsl-mc dpbp.8: Removing from iommu group 7
------------[ cut here ]------------
kernel BUG at drivers/net/phy/mdio_bus.c:677!
Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
Modules linked in:
CPU: 0 PID: 1 Comm: systemd-shutdow Not tainted 5.16.5-00040-gdc05f73788e5 #15
pc : mdiobus_free+0x44/0x50
lr : devm_mdiobus_free+0x10/0x20
Call trace:
mdiobus_free+0x44/0x50
devm_mdiobus_free+0x10/0x20
devres_release_all+0xa0/0x100
__device_release_driver+0x190/0x220
device_release_driver_internal+0xac/0xb0
device_links_unbind_consumers+0xd4/0x100
__device_release_driver+0x4c/0x220
device_release_driver_internal+0xac/0xb0
device_links_unbind_consumers+0xd4/0x100
__device_release_driver+0x94/0x220
device_release_driver+0x28/0x40
bus_remove_device+0x118/0x124
device_del+0x174/0x420
fsl_mc_device_remove+0x24/0x40
__fsl_mc_device_remove+0xc/0x20
device_for_each_child+0x58/0xa0
dprc_remove+0x90/0xb0
fsl_mc_driver_remove+0x20/0x5c
__device_release_driver+0x21c/0x220
device_release_driver+0x28/0x40
bus_remove_device+0x118/0x124
device_del+0x174/0x420
fsl_mc_bus_remove+0x80/0x100
fsl_mc_bus_shutdown+0xc/0x1c
platform_shutdown+0x20/0x30
device_shutdown+0x154/0x330
kernel_power_off+0x34/0x6c
__do_sys_reboot+0x15c/0x250
__arm64_sys_reboot+0x20/0x30
invoke_syscall.constprop.0+0x4c/0xe0
do_el0_svc+0x4c/0x150
el0_svc+0x24/0xb0
el0t_64_sync_handler+0xa8/0xb0
el0t_64_sync+0x178/0x17c
So the same treatment must be applied to all DSA switch drivers, which
is: either use devres for both the mdiobus allocation and registration,
or don't use devres at all.
The Marvell driver already has a good structure for mdiobus removal, so
just plug in mdiobus_free and get rid of devres. |
| In the Linux kernel, the following vulnerability has been resolved:
net: dsa: ar9331: register the mdiobus under devres
As explained in commits:
74b6d7d13307 ("net: dsa: realtek: register the MDIO bus under devres")
5135e96a3dd2 ("net: dsa: don't allocate the slave_mii_bus using devres")
mdiobus_free() will panic when called from devm_mdiobus_free() <-
devres_release_all() <- __device_release_driver(), and that mdiobus was
not previously unregistered.
The ar9331 is an MDIO device, so the initial set of constraints that I
thought would cause this (I2C or SPI buses which call ->remove on
->shutdown) do not apply. But there is one more which applies here.
If the DSA master itself is on a bus that calls ->remove from ->shutdown
(like dpaa2-eth, which is on the fsl-mc bus), there is a device link
between the switch and the DSA master, and device_links_unbind_consumers()
will unbind the ar9331 switch driver on shutdown.
So the same treatment must be applied to all DSA switch drivers, which
is: either use devres for both the mdiobus allocation and registration,
or don't use devres at all.
The ar9331 driver doesn't have a complex code structure for mdiobus
removal, so just replace of_mdiobus_register with the devres variant in
order to be all-devres and ensure that we don't free a still-registered
bus. |
| In the Linux kernel, the following vulnerability has been resolved:
net: dsa: bcm_sf2: don't use devres for mdiobus
As explained in commits:
74b6d7d13307 ("net: dsa: realtek: register the MDIO bus under devres")
5135e96a3dd2 ("net: dsa: don't allocate the slave_mii_bus using devres")
mdiobus_free() will panic when called from devm_mdiobus_free() <-
devres_release_all() <- __device_release_driver(), and that mdiobus was
not previously unregistered.
The Starfighter 2 is a platform device, so the initial set of
constraints that I thought would cause this (I2C or SPI buses which call
->remove on ->shutdown) do not apply. But there is one more which
applies here.
If the DSA master itself is on a bus that calls ->remove from ->shutdown
(like dpaa2-eth, which is on the fsl-mc bus), there is a device link
between the switch and the DSA master, and device_links_unbind_consumers()
will unbind the bcm_sf2 switch driver on shutdown.
So the same treatment must be applied to all DSA switch drivers, which
is: either use devres for both the mdiobus allocation and registration,
or don't use devres at all.
The bcm_sf2 driver has the code structure in place for orderly mdiobus
removal, so just replace devm_mdiobus_alloc() with the non-devres
variant, and add manual free where necessary, to ensure that we don't
let devres free a still-registered bus. |
| NSSCryptoSignBackend.cc in Poppler before 25.04.0 does not verify the adbe.pkcs7.sha1 signatures on documents, resulting in potential signature forgeries. |
| A vulnerability, which was classified as problematic, has been found in SeaCMS 13.2. This issue affects some unknown processing of the file /admin_pay.php. The manipulation of the argument cstatus leads to cross site scripting. The attack may be initiated remotely. The exploit has been disclosed to the public and may be used. |
| mailcow: dockerized is an open source groupware/email suite based on docker. A security vulnerability has been identified in mailcow affecting versions prior to 2024-04. This vulnerability resides in the exception handling mechanism, specifically when not operating in DEV_MODE. The system saves exception details into a session array without proper sanitization or encoding. These details are later rendered into HTML and executed in a JavaScript block within the user's browser, without adequate escaping of HTML entities. This flaw allows for Cross-Site Scripting (XSS) attacks, where attackers can inject malicious scripts into the admin panel by triggering exceptions with controlled input. The exploitation method involves using any function that might throw an exception with user-controllable argument. This issue can lead to session hijacking and unauthorized administrative actions, posing a significant security risk. Version 2024-04 contains a fix for the issue. |
| Mattermost versions 10.6.x <= 10.6.1, 10.5.x <= 10.5.2, 10.4.x <= 10.4.4, 9.11.x <= 9.11.11 fail to lockout LDAP users following repeated login failures, which allows attackers to lock external LDAP accounts through repeated login failures through Mattermost. |
| Mattermost versions 10.5.x <= 10.5.3, 9.11.x <= 9.11.11 fail to check `RestrictSystemAdmin` setting if user doesn't have access to `ExperimentalSettings` which allows a System Manager to access `ExperimentSettings` when `RestrictSystemAdmin` is true via System Console. |
| mailcow: dockerized is an open source groupware/email suite based on docker. A security vulnerability has been identified in mailcow affecting versions prior to 2024-04. This vulnerability is a combination of path traversal and arbitrary code execution, specifically targeting the `rspamd_maps()` function. It allows authenticated admin users to overwrite any file writable by the www-data user by exploiting improper path validation. The exploit chain can lead to the execution of arbitrary commands on the server. Version 2024-04 contains a patch for the issue. |
| LinkAce is a self-hosted archive to collect website links. A stored cross-site scripting (XSS) vulnerability was discovered in versions prior to 2.1.9 that allows an attacker to inject arbitrary JavaScript, which is then executed in the context of a user's browser when the malicious link is clicked. This is a one-click XSS, meaning the victim only needs to click a crafted link — no further interaction is required. The application contains a stored XSS vulnerability due to insufficient filtering and escaping of user-supplied data inserted into link attributes. Malicious JavaScript code can be saved in the database along with the link and executed in the user’s browser when clicking the link, leading to arbitrary script execution within the context of the site. Version 2.1.9 fixes the issue. |
| The Limit Bio WordPress plugin through 1.0 does not have CSRF check when updating its settings, and is missing sanitisation as well as escaping, which could allow attackers to make logged in admin add Stored XSS payloads via a CSRF attack. |
| Improper Privilege Management vulnerability in OpenText NetIQ Access Manager allows user account impersonation in specific scenario. This issue affects NetIQ Access Manager before 5.0.4.1 and before 5.1 |
| Improper Input Validation vulnerability in OpenText NetIQ Access Manager leads to Cross-Site Scripting (XSS) attack. This issue affects Access Manager before 5.0.4.1 and 5.1. |
| NVIDIA Container Toolkit contains an improper isolation vulnerability where a specially crafted container image could lead to untrusted code running in the host’s network namespace. This vulnerability is present only when the NVIDIA Container Toolkit is configured in a nondefault way. A successful exploit of this vulnerability may lead to denial of service and escalation of privileges. |
| NVIDIA Container Toolkit contains an improper isolation vulnerability where a specially crafted container image could lead to untrusted code obtaining read and write access to host devices. This vulnerability is present only when the NVIDIA Container Toolkit is configured in a nondefault way. A successful exploit of this vulnerability may lead to code execution, denial of service, escalation of privileges, information disclosure, and data tampering. |
| NVIDIA Container Toolkit contains an improper isolation vulnerability where a specially crafted container image could lead to modification of a host binary. A successful exploit of this vulnerability may lead to code execution, denial of service, escalation of privileges, information disclosure, and data tampering. |
| A Cross-Site Request Forgery (CSRF) vulnerability exists in the management console of WSO2 Enterprise Integrator 6.6.0 due to the absence of CSRF token validation. This flaw allows attackers to craft malicious requests that can trigger state-changing operations on behalf of an authenticated user, potentially compromising account settings and data integrity. The vulnerability only affects a limited set of state-changing operations, and successful exploitation requires social engineering to trick a user with access to the management console into performing the malicious action. |
| A vulnerability has been identified in OZW672 (All versions < V8.0), OZW772 (All versions < V8.0). The web service in affected devices does not sanitize the input parameters required for the `exportDiagramPage` endpoint. This could allow an unauthenticated remote attacker to execute arbitrary code with root privileges. |
