A SQL Injection vulnerability was found in /admin/aboutus.php in PHPGurukul Land Record System v1.0, which allows remote attackers to execute arbitrary code via the pagetitle POST request parameter.
A SQL Injection was found in /admin/admin-profile.php in PHPGurukul Land Record System v1.0, which allows remote attackers to execute arbitrary code via the contactnumber POST request parameter.
A SQL Injection vulnerability was found in /admin/bwdates-reports-details.php in PHPGurukul Land Record System v1.0, which allows remote attackers to execute arbitrary code via the fromdate POST request parameter.
A SQL Injection vulnerability was found in /admin/bwdates-reports-details.php in PHPGurukul Land Record System v1.0, which allows remote attackers to execute arbitrary code via the " todate" POST request parameter.
A SQL Injection vulnerability was found in /admin/contactus.php in PHPGurukul Land Record System v1.0, which allows remote attackers to execute arbitrary code via the email POST request parameter.
In the Linux kernel, the following vulnerability has been resolved:
gfs2: Truncate address space when flipping GFS2_DIF_JDATA flag
Truncate an inode's address space when flipping the GFS2_DIF_JDATA flag:
depending on that flag, the pages in the address space will either use
buffer heads or iomap_folio_state structs, and we cannot mix the two.
In the Linux kernel, the following vulnerability has been resolved:
fs/proc: fix softlockup in __read_vmcore (part 2)
Since commit 5cbcb62dddf5 ("fs/proc: fix softlockup in __read_vmcore") the
number of softlockups in __read_vmcore at kdump time have gone down, but
they still happen sometimes.
In a memory constrained environment like the kdump image, a softlockup is
not just a harmless message, but it can interfere with things like RCU
freeing memory, causing the crashdump to get stuck.
The second loop in __read_vmcore has a lot more opportunities for natural
sleep points, like scheduling out while waiting for a data write to
happen, but apparently that is not always enough.
Add a cond_resched() to the second loop in __read_vmcore to (hopefully)
get rid of the softlockups.
In the Linux kernel, the following vulnerability has been resolved:
platform/x86: dell-uart-backlight: fix serdev race
The dell_uart_bl_serdev_probe() function calls devm_serdev_device_open()
before setting the client ops via serdev_device_set_client_ops(). This
ordering can trigger a NULL pointer dereference in the serdev controller's
receive_buf handler, as it assumes serdev->ops is valid when
SERPORT_ACTIVE is set.
This is similar to the issue fixed in commit 5e700b384ec1
("platform/chrome: cros_ec_uart: properly fix race condition") where
devm_serdev_device_open() was called before fully initializing the
device.
Fix the race by ensuring client ops are set before enabling the port via
devm_serdev_device_open().
Note, serdev_device_set_baudrate() and serdev_device_set_flow_control()
calls should be after the devm_serdev_device_open() call.