| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Baby Care System v1.0 was discovered to contain a SQL injection vulnerability via /admin/inbox.php&action=read&msgid=. |
| Baby Care System v1.0 was discovered to contain a SQL injection vulnerability via /admin/inbox.php&action=delete&msgid=. |
| Baby Care System v1.0 was discovered to contain a SQL injection vulnerability via /admin.php?id=siteoptions&social=edit&sid=2. |
| Baby Care System v1.0 was discovered to contain a SQL injection vulnerability via /admin/uesrs.php&action=type&userrole=Admin&userid=3. |
| Baby Care System v1.0 was discovered to contain a SQL injection vulnerability via /admin/posts.php&action=delete. |
| Baby Care System v1.0 was discovered to contain a SQL injection vulnerability via BabyCare/admin.php?id=theme&setid=. |
| Baby Care System v1.0 was discovered to contain a SQL injection vulnerability via /admin/siteoptions.php&social=remove&sid=2. |
| Baby Care System v1.0 was discovered to contain a SQL injection vulnerability via /admin/uesrs.php&action=display&value=Hide&userid=. |
| Baby Care System v1.0 was discovered to contain a SQL injection vulnerability via /admin/uesrs.php&&action=delete&userid=4. |
| Baby Care System v1.0 was discovered to contain a SQL injection vulnerability via /admin/posts.php&action=edit. |
| Baby Care System v1.0 was discovered to contain a SQL injection vulnerability via /admin/pagerole.php&action=display&value=1&roleid=. |
| Baby Care System v1.0 was discovered to contain a SQL injection vulnerability via /admin/siteoptions.php&action=displaygoal&value=1&roleid=1. |
| Baby Care System v1.0 was discovered to contain a SQL injection vulnerability via /admin/uesrs.php&action=display&value=Show&userid=. |
| Baby Care System v1.0 was discovered to contain a SQL injection vulnerability via /admin.php?id=siteoptions&social=display&value=0&sid=2. |
| A security flaw has been discovered in itsourcecode Inventory Management System 1.0. Affected is an unknown function of the file /LogSignModal.PHP. The manipulation of the argument U_USERNAME results in sql injection. The attack can be launched remotely. The exploit has been released to the public and may be exploited. |
| A vulnerability was determined in SourceCodester Best House Rental Management System 1.0. This affects the function delete_house of the file /admin_class.php. Executing manipulation of the argument ID can lead to sql injection. The attack may be performed from remote. The exploit has been publicly disclosed and may be utilized. |
| A security flaw has been discovered in Campcodes School File Management 1.0. This affects an unknown part of the file /admin/update_user.php. Performing manipulation of the argument user_id results in sql injection. It is possible to initiate the attack remotely. The exploit has been released to the public and may be exploited. |
| In the Linux kernel, the following vulnerability has been resolved:
vfio: Split migration ops from main device ops
vfio core checks whether the driver sets some migration op (e.g.
set_state/get_state) and accordingly calls its op.
However, currently mlx5 driver sets the above ops without regards to its
migration caps.
This might lead to unexpected usage/Oops if user space may call to the
above ops even if the driver doesn't support migration. As for example,
the migration state_mutex is not initialized in that case.
The cleanest way to manage that seems to split the migration ops from
the main device ops, this will let the driver setting them separately
from the main ops when it's applicable.
As part of that, validate ops construction on registration and include a
check for VFIO_MIGRATION_STOP_COPY since the uAPI claims it must be set
in migration_flags.
HISI driver was changed as well to match this scheme.
This scheme may enable down the road to come with some extra group of
ops (e.g. DMA log) that can be set without regards to the other options
based on driver caps. |
| In the Linux kernel, the following vulnerability has been resolved:
net: phy: Don't register LEDs for genphy
If a PHY has no driver, the genphy driver is probed/removed directly in
phy_attach/detach. If the PHY's ofnode has an "leds" subnode, then the
LEDs will be (un)registered when probing/removing the genphy driver.
This could occur if the leds are for a non-generic driver that isn't
loaded for whatever reason. Synchronously removing the PHY device in
phy_detach leads to the following deadlock:
rtnl_lock()
ndo_close()
...
phy_detach()
phy_remove()
phy_leds_unregister()
led_classdev_unregister()
led_trigger_set()
netdev_trigger_deactivate()
unregister_netdevice_notifier()
rtnl_lock()
There is a corresponding deadlock on the open/register side of things
(and that one is reported by lockdep), but it requires a race while this
one is deterministic.
Generic PHYs do not support LEDs anyway, so don't bother registering
them. |
| U-Office Force developed by e-Excellence has a SQL Injection vulnerability, allowing authenticated remote attacker to inject arbitrary SQL commands to read, modify, and delete database contents. |
