| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| A weakness has been identified in Portabilis i-Educar up to 2.10. This affects an unknown part of the file /module/Api/matricula of the component Matricula API. Executing manipulation can lead to improper authorization. It is possible to launch the attack remotely. The exploit has been made available to the public and could be exploited. |
| A vulnerability was found in code-projects Online Book Shop 1.0. It has been classified as critical. This affects an unknown part of the file /booklist.php. The manipulation of the argument subcatid leads to sql injection. It is possible to initiate the attack remotely. The exploit has been disclosed to the public and may be used. |
| A vulnerability was found in code-projects Online Book Shop 1.0 and classified as problematic. Affected by this issue is some unknown functionality of the file /booklist.php?subcatid=1. The manipulation of the argument subcatnm leads to cross site scripting. The attack may be launched remotely. The exploit has been disclosed to the public and may be used. |
| A vulnerability has been found in PHPGurukul Employee Record Management System 1.3 and classified as critical. Affected by this vulnerability is an unknown functionality of the file /editmyeducation.php. The manipulation of the argument coursepg/yophsc leads to sql injection. The attack can be launched remotely. The exploit has been disclosed to the public and may be used. Other parameters might be affected as well. |
| Cross-process screen stack vulnerability in the UIExtension module
Impact: Successful exploitation of this vulnerability may affect service confidentiality. |
| Cross-process screen stack vulnerability in the UIExtension module
Impact: Successful exploitation of this vulnerability may affect service confidentiality. |
| Vulnerability of improper memory address protection in the HUKS module
Impact: Successful exploitation of this vulnerability may affect availability. |
| Access control vulnerability in the identity authentication module
Impact: Successful exploitation of this vulnerability may affect service confidentiality. |
| In the Linux kernel, the following vulnerability has been resolved:
net/mlx5e: IPoIB, Block PKEY interfaces with less rx queues than parent
A user is able to configure an arbitrary number of rx queues when
creating an interface via netlink. This doesn't work for child PKEY
interfaces because the child interface uses the parent receive channels.
Although the child shares the parent's receive channels, the number of
rx queues is important for the channel_stats array: the parent's rx
channel index is used to access the child's channel_stats. So the array
has to be at least as large as the parent's rx queue size for the
counting to work correctly and to prevent out of bound accesses.
This patch checks for the mentioned scenario and returns an error when
trying to create the interface. The error is propagated to the user. |
| In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: ASSERT when failing to find index by plane/stream id
[WHY]
find_disp_cfg_idx_by_plane_id and find_disp_cfg_idx_by_stream_id returns
an array index and they return -1 when not found; however, -1 is not a
valid index number.
[HOW]
When this happens, call ASSERT(), and return a positive number (which is
fewer than callers' array size) instead.
This fixes 4 OVERRUN and 2 NEGATIVE_RETURNS issues reported by Coverity. |
| DeepSeek R1 through V3.1 allows XSS, as demonstrated by JavaScript execution in the context of the run-html-chat.deepseeksvc.com domain. NOTE: some third parties have indicated that this is intended behavior. |
| A vulnerability has been found in PHPGurukul Vehicle Parking Management System 1.13 and classified as critical. Affected by this vulnerability is an unknown functionality of the file /admin/bwdates-reports-details.php. The manipulation of the argument fromdate/todate leads to sql injection. The attack can be launched remotely. The exploit has been disclosed to the public and may be used. |
| A vulnerability, which was classified as critical, has been found in PHPGurukul Vehicle Parking Management System 1.13. This issue affects some unknown processing of the file /admin/manage-category.php. The manipulation of the argument del leads to sql injection. The attack may be initiated remotely. The exploit has been disclosed to the public and may be used. |
| A vulnerability was found in PHPGurukul Online Fire Reporting System 1.2. It has been rated as critical. This issue affects some unknown processing of the file /admin/team-ontheway-requests.php. The manipulation of the argument teamid leads to sql injection. The attack may be initiated remotely. The exploit has been disclosed to the public and may be used. |
| A vulnerability was found in PHPGurukul Vehicle Parking Management System 1.13. It has been declared as critical. Affected by this vulnerability is an unknown functionality of the file /admin/manage-outgoingvehicle.php. The manipulation of the argument del leads to sql injection. The attack can be launched remotely. The exploit has been disclosed to the public and may be used. |
| A vulnerability was found in PHPGurukul Vehicle Parking Management System 1.13. It has been rated as critical. Affected by this issue is some unknown functionality of the file /admin/manage-incomingvehicle.php. The manipulation of the argument del leads to sql injection. The attack may be launched remotely. The exploit has been disclosed to the public and may be used. |
| Improper Check for Unusual or Exceptional Conditions vulnerability in Phoenix SecureCore Technology 4 allows Input Data Manipulation.This issue affects SecureCore Technology 4: from 4.0.1.0 before 4.0.1.1018, from 4.1.0.1 before 4.1.0.573, from 4.2.0.1 before 4.2.0.338, from 4.2.1.1 before 4.2.1.300, from 4.3.0.1 before 4.3.0.244, from 4.3.1.1 before 4.3.1.187, from 4.4.0.1 before 4.4.0.299, from 4.5.0.1 before 4.5.0.231, from 4.5.1.1 before 4.5.1.103, from 4.5.5.1 before 4.5.5.36, from 4.6.0.1 before 4.6.0.67. |
| Discourse is an open-source discussion platform. Versions prior to 3.5.0.beta6 are vulnerable to cross-site scripting when the content security policy isn't enabled when using social logins. Version 3.5.0.beta6 patches the issue. As a workaround, have the content security policy enabled. |
| In the Linux kernel, the following vulnerability has been resolved:
bpf: Defer work in bpf_timer_cancel_and_free
Currently, the same case as previous patch (two timer callbacks trying
to cancel each other) can be invoked through bpf_map_update_elem as
well, or more precisely, freeing map elements containing timers. Since
this relies on hrtimer_cancel as well, it is prone to the same deadlock
situation as the previous patch.
It would be sufficient to use hrtimer_try_to_cancel to fix this problem,
as the timer cannot be enqueued after async_cancel_and_free. Once
async_cancel_and_free has been done, the timer must be reinitialized
before it can be armed again. The callback running in parallel trying to
arm the timer will fail, and freeing bpf_hrtimer without waiting is
sufficient (given kfree_rcu), and bpf_timer_cb will return
HRTIMER_NORESTART, preventing the timer from being rearmed again.
However, there exists a UAF scenario where the callback arms the timer
before entering this function, such that if cancellation fails (due to
timer callback invoking this routine, or the target timer callback
running concurrently). In such a case, if the timer expiration is
significantly far in the future, the RCU grace period expiration
happening before it will free the bpf_hrtimer state and along with it
the struct hrtimer, that is enqueued.
Hence, it is clear cancellation needs to occur after
async_cancel_and_free, and yet it cannot be done inline due to deadlock
issues. We thus modify bpf_timer_cancel_and_free to defer work to the
global workqueue, adding a work_struct alongside rcu_head (both used at
_different_ points of time, so can share space).
Update existing code comments to reflect the new state of affairs. |
| In the Linux kernel, the following vulnerability has been resolved:
bpf: Fix reg_set_min_max corruption of fake_reg
Juan reported that after doing some changes to buzzer [0] and implementing
a new fuzzing strategy guided by coverage, they noticed the following in
one of the probes:
[...]
13: (79) r6 = *(u64 *)(r0 +0) ; R0=map_value(ks=4,vs=8) R6_w=scalar()
14: (b7) r0 = 0 ; R0_w=0
15: (b4) w0 = -1 ; R0_w=0xffffffff
16: (74) w0 >>= 1 ; R0_w=0x7fffffff
17: (5c) w6 &= w0 ; R0_w=0x7fffffff R6_w=scalar(smin=smin32=0,smax=umax=umax32=0x7fffffff,var_off=(0x0; 0x7fffffff))
18: (44) w6 |= 2 ; R6_w=scalar(smin=umin=smin32=umin32=2,smax=umax=umax32=0x7fffffff,var_off=(0x2; 0x7ffffffd))
19: (56) if w6 != 0x7ffffffd goto pc+1
REG INVARIANTS VIOLATION (true_reg2): range bounds violation u64=[0x7fffffff, 0x7ffffffd] s64=[0x7fffffff, 0x7ffffffd] u32=[0x7fffffff, 0x7ffffffd] s32=[0x7fffffff, 0x7ffffffd] var_off=(0x7fffffff, 0x0)
REG INVARIANTS VIOLATION (false_reg1): range bounds violation u64=[0x7fffffff, 0x7ffffffd] s64=[0x7fffffff, 0x7ffffffd] u32=[0x7fffffff, 0x7ffffffd] s32=[0x7fffffff, 0x7ffffffd] var_off=(0x7fffffff, 0x0)
REG INVARIANTS VIOLATION (false_reg2): const tnum out of sync with range bounds u64=[0x0, 0xffffffffffffffff] s64=[0x8000000000000000, 0x7fffffffffffffff] u32=[0x0, 0xffffffff] s32=[0x80000000, 0x7fffffff] var_off=(0x7fffffff, 0x0)
19: R6_w=0x7fffffff
20: (95) exit
from 19 to 21: R0=0x7fffffff R6=scalar(smin=umin=smin32=umin32=2,smax=umax=smax32=umax32=0x7ffffffe,var_off=(0x2; 0x7ffffffd)) R7=map_ptr(ks=4,vs=8) R9=ctx() R10=fp0 fp-24=map_ptr(ks=4,vs=8) fp-40=mmmmmmmm
21: R0=0x7fffffff R6=scalar(smin=umin=smin32=umin32=2,smax=umax=smax32=umax32=0x7ffffffe,var_off=(0x2; 0x7ffffffd)) R7=map_ptr(ks=4,vs=8) R9=ctx() R10=fp0 fp-24=map_ptr(ks=4,vs=8) fp-40=mmmmmmmm
21: (14) w6 -= 2147483632 ; R6_w=scalar(smin=umin=umin32=2,smax=umax=0xffffffff,smin32=0x80000012,smax32=14,var_off=(0x2; 0xfffffffd))
22: (76) if w6 s>= 0xe goto pc+1 ; R6_w=scalar(smin=umin=umin32=2,smax=umax=0xffffffff,smin32=0x80000012,smax32=13,var_off=(0x2; 0xfffffffd))
23: (95) exit
from 22 to 24: R0=0x7fffffff R6_w=14 R7=map_ptr(ks=4,vs=8) R9=ctx() R10=fp0 fp-24=map_ptr(ks=4,vs=8) fp-40=mmmmmmmm
24: R0=0x7fffffff R6_w=14 R7=map_ptr(ks=4,vs=8) R9=ctx() R10=fp0 fp-24=map_ptr(ks=4,vs=8) fp-40=mmmmmmmm
24: (14) w6 -= 14 ; R6_w=0
[...]
What can be seen here is a register invariant violation on line 19. After
the binary-or in line 18, the verifier knows that bit 2 is set but knows
nothing about the rest of the content which was loaded from a map value,
meaning, range is [2,0x7fffffff] with var_off=(0x2; 0x7ffffffd). When in
line 19 the verifier analyzes the branch, it splits the register states
in reg_set_min_max() into the registers of the true branch (true_reg1,
true_reg2) and the registers of the false branch (false_reg1, false_reg2).
Since the test is w6 != 0x7ffffffd, the src_reg is a known constant.
Internally, the verifier creates a "fake" register initialized as scalar
to the value of 0x7ffffffd, and then passes it onto reg_set_min_max(). Now,
for line 19, it is mathematically impossible to take the false branch of
this program, yet the verifier analyzes it. It is impossible because the
second bit of r6 will be set due to the prior or operation and the
constant in the condition has that bit unset (hex(fd) == binary(1111 1101).
When the verifier first analyzes the false / fall-through branch, it will
compute an intersection between the var_off of r6 and of the constant. This
is because the verifier creates a "fake" register initialized to the value
of the constant. The intersection result later refines both registers in
regs_refine_cond_op():
[...]
t = tnum_intersect(tnum_subreg(reg1->var_off), tnum_subreg(reg2->var_off));
reg1->var_o
---truncated--- |
