Vulnerabilities

Multiple Cross Site Scripting (XSS) vulnerabilities exist in PHPGurukul Hospital Management System 4.0 via the docname parameter in /admin/add-doctor.php and /admin/edit-doctor.php

Multiple cross-site scripting vulnerabilities exist in PHPGurukul Hospital Management System 4.0 via the docname parameter in /doctor/edit-profile.php and adminremark parameter in /admin/query-details.php.

Cilium is a networking, observability, and security solution with an eBPF-based dataplane. Starting in version 1.14.0 and prior to versions 1.14.16 and 1.15.10, a policy rule denying a prefix that is broader than `/32` may be ignored if there is a policy rule referencing a more narrow prefix (`CIDRSet` or `toFQDN`) and this narrower policy rule specifies either `enableDefaultDeny: false` or `- toEntities: all`. Note that a rule specifying `toEntities: world` or `toEntities: 0.0.0.0/0` is insufficient, it must be to entity `all`.This issue has been patched in Cilium v1.14.16 and v1.15.10. As this issue only affects policies using `enableDefaultDeny: false` or that set `toEntities` to `all`, some workarounds are available. For users with policies using `enableDefaultDeny: false`, remove this configuration option and explicitly define any allow rules required. For users with egress policies that explicitly specify `toEntities: all`, use `toEntities: world`.

CodeAstro Membership Management System v1.0 is vulnerable to Cross Site Scripting (XSS) via the address parameter in add_members.php and edit_member.php.

CodeAstro Membership Management System v1.0 is vulnerable to Cross Site Scripting (XSS) via the membershipType parameter in edit_type.php

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5e: Fix NULL deref in mlx5e_tir_builder_alloc()<br /> <br /> In mlx5e_tir_builder_alloc() kvzalloc() may return NULL<br /> which is dereferenced on the next line in a reference<br /> to the modify field.<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with SVACE.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5: Fix error path in multi-packet WQE transmit<br /> <br /> Remove the erroneous unmap in case no DMA mapping was established<br /> <br /> The multi-packet WQE transmit code attempts to obtain a DMA mapping for<br /> the skb. This could fail, e.g. under memory pressure, when the IOMMU<br /> driver just can&amp;#39;t allocate more memory for page tables. While the code<br /> tries to handle this in the path below the err_unmap label it erroneously<br /> unmaps one entry from the sq&amp;#39;s FIFO list of active mappings. Since the<br /> current map attempt failed this unmap is removing some random DMA mapping<br /> that might still be required. If the PCI function now presents that IOVA,<br /> the IOMMU may assumes a rogue DMA access and e.g. on s390 puts the PCI<br /> function in error state.<br /> <br /> The erroneous behavior was seen in a stress-test environment that created<br /> memory pressure.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> static_call: Handle module init failure correctly in static_call_del_module()<br /> <br /> Module insertion invokes static_call_add_module() to initialize the static<br /> calls in a module. static_call_add_module() invokes __static_call_init(),<br /> which allocates a struct static_call_mod to either encapsulate the built-in<br /> static call sites of the associated key into it so further modules can be<br /> added or to append the module to the module chain.<br /> <br /> If that allocation fails the function returns with an error code and the<br /> module core invokes static_call_del_module() to clean up eventually added<br /> static_call_mod entries.<br /> <br /> This works correctly, when all keys used by the module were converted over<br /> to a module chain before the failure. If not then static_call_del_module()<br /> causes a #GP as it blindly assumes that key::mods points to a valid struct<br /> static_call_mod.<br /> <br /> The problem is that key::mods is not a individual struct member of struct<br /> static_call_key, it&amp;#39;s part of a union to save space:<br /> <br /> union {<br /> /* bit 0: 0 = mods, 1 = sites */<br /> unsigned long type;<br /> struct static_call_mod *mods;<br /> struct static_call_site *sites;<br /> };<br /> <br /> key::sites is a pointer to the list of built-in usage sites of the static<br /> call. The type of the pointer is differentiated by bit 0. A mods pointer<br /> has the bit clear, the sites pointer has the bit set.<br /> <br /> As static_call_del_module() blidly assumes that the pointer is a valid<br /> static_call_mod type, it fails to check for this failure case and<br /> dereferences the pointer to the list of built-in call sites, which is<br /> obviously bogus.<br /> <br /> Cure it by checking whether the key has a sites or a mods pointer.<br /> <br /> If it&amp;#39;s a sites pointer then the key is not to be touched. As the sites are<br /> walked in the same order as in __static_call_init() the site walk can be<br /> terminated because all subsequent sites have not been touched by the init<br /> code due to the error exit.<br /> <br /> If it was converted before the allocation fail, then the inner loop which<br /> searches for a module match will find nothing.<br /> <br /> A fail in the second allocation in __static_call_init() is harmless and<br /> does not require special treatment. The first allocation succeeded and<br /> converted the key to a module chain. That first entry has mod::mod == NULL<br /> and mod::next == NULL, so the inner loop of static_call_del_module() will<br /> neither find a module match nor a module chain. The next site in the walk<br /> was either already converted, but can&amp;#39;t match the module, or it will exit<br /> the outer loop because it has a static_call_site pointer and not a<br /> static_call_mod pointer.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpftool: Fix undefined behavior in qsort(NULL, 0, ...)<br /> <br /> When netfilter has no entry to display, qsort is called with<br /> qsort(NULL, 0, ...). This results in undefined behavior, as UBSan<br /> reports:<br /> <br /> net.c:827:2: runtime error: null pointer passed as argument 1, which is declared to never be null<br /> <br /> Although the C standard does not explicitly state whether calling qsort<br /> with a NULL pointer when the size is 0 constitutes undefined behavior,<br /> Section 7.1.4 of the C standard (Use of library functions) mentions:<br /> <br /> "Each of the following statements applies unless explicitly stated<br /> otherwise in the detailed descriptions that follow: If an argument to a<br /> function has an invalid value (such as a value outside the domain of<br /> the function, or a pointer outside the address space of the program, or<br /> a null pointer, or a pointer to non-modifiable storage when the<br /> corresponding parameter is not const-qualified) or a type (after<br /> promotion) not expected by a function with variable number of<br /> arguments, the behavior is undefined."<br /> <br /> To avoid this, add an early return when nf_link_info is NULL to prevent<br /> calling qsort with a NULL pointer.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: add refcnt to ksmbd_conn struct<br /> <br /> When sending an oplock break request, opinfo-&gt;conn is used,<br /> But freed -&gt;conn can be used on multichannel.<br /> This patch add a reference count to the ksmbd_conn struct<br /> so that it can be freed when it is no longer used.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/xe/hdcp: Check GSC structure validity<br /> <br /> Sometimes xe_gsc is not initialized when checked at HDCP capability<br /> check. Add gsc structure check to avoid null pointer error.

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.