Vulnerabilities

SQL Injection vulnerability in Lost and Found Information System 1.0 allows a remote attacker to escalate privileges via id parameter to php-lfis/admin/categories/view_category.php.

SQL Injection vulnerability in Lost and Found Information System 1.0 allows a remote attacker to escalate privileges via the id parameter to php-lfis/admin/categories/manage_category.php.

Cross Site Scripting vulnerability in Lost and Found Information System 1.0 allows a remote attacker to escalate privileges via the page parameter to php-lfis/admin/index.php.

An issue was discovered in Italtel i-MCS NFV 12.1.0-20211215. Stored Cross-site scripting (XSS) can occur via POST.

An issue was discovered in Italtel i-MCS NFV 12.1.0-20211215. There is Incorrect Access Control.

Versions of Delphix Engine prior to Release 25.0.0.0 contain a flaw which results in Remote Code Execution (RCE).

A flaw in versions of Delphix Data Control Tower (DCT) prior to 19.0.0 results in broken authentication through the enable-scale-testing functionality of the application.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> serial: 8250_omap: Implementation of Errata i2310<br /> <br /> As per Errata i2310[0], Erroneous timeout can be triggered,<br /> if this Erroneous interrupt is not cleared then it may leads<br /> to storm of interrupts, therefore apply Errata i2310 solution.<br /> <br /> [0] https://www.ti.com/lit/pdf/sprz536 page 23

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> x86: stop playing stack games in profile_pc()<br /> <br /> The &amp;#39;profile_pc()&amp;#39; function is used for timer-based profiling, which<br /> isn&amp;#39;t really all that relevant any more to begin with, but it also ends<br /> up making assumptions based on the stack layout that aren&amp;#39;t necessarily<br /> valid.<br /> <br /> Basically, the code tries to account the time spent in spinlocks to the<br /> caller rather than the spinlock, and while I support that as a concept,<br /> it&amp;#39;s not worth the code complexity or the KASAN warnings when no serious<br /> profiling is done using timers anyway these days.<br /> <br /> And the code really does depend on stack layout that is only true in the<br /> simplest of cases. We&amp;#39;ve lost the comment at some point (I think when<br /> the 32-bit and 64-bit code was unified), but it used to say:<br /> <br /> Assume the lock function has either no stack frame or a copy<br /> of eflags from PUSHF.<br /> <br /> which explains why it just blindly loads a word or two straight off the<br /> stack pointer and then takes a minimal look at the values to just check<br /> if they might be eflags or the return pc:<br /> <br /> Eflags always has bits 22 and up cleared unlike kernel addresses<br /> <br /> but that basic stack layout assumption assumes that there isn&amp;#39;t any lock<br /> debugging etc going on that would complicate the code and cause a stack<br /> frame.<br /> <br /> It causes KASAN unhappiness reported for years by syzkaller [1] and<br /> others [2].<br /> <br /> With no real practical reason for this any more, just remove the code.<br /> <br /> Just for historical interest, here&amp;#39;s some background commits relating to<br /> this code from 2006:<br /> <br /> 0cb91a229364 ("i386: Account spinlocks to the caller during profiling for !FP kernels")<br /> 31679f38d886 ("Simplify profile_pc on x86-64")<br /> <br /> and a code unification from 2009:<br /> <br /> ef4512882dbe ("x86: time_32/64.c unify profile_pc")<br /> <br /> but the basics of this thing actually goes back to before the git tree.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: emux: improve patch ioctl data validation<br /> <br /> In load_data(), make the validation of and skipping over the main info<br /> block match that in load_guspatch().<br /> <br /> In load_guspatch(), add checking that the specified patch length matches<br /> the actually supplied data, like load_data() already did.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: ecdh - explicitly zeroize private_key<br /> <br /> private_key is overwritten with the key parameter passed in by the<br /> caller (if present), or alternatively a newly generated private key.<br /> However, it is possible that the caller provides a key (or the newly<br /> generated key) which is shorter than the previous key. In that<br /> scenario, some key material from the previous key would not be<br /> overwritten. The easiest solution is to explicitly zeroize the entire<br /> private_key array first.<br /> <br /> Note that this patch slightly changes the behavior of this function:<br /> previously, if the ecc_gen_privkey failed, the old private_key would<br /> remain. Now, the private_key is always zeroized. This behavior is<br /> consistent with the case where params.key is set and ecc_is_key_valid<br /> fails.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/xe: Check pat.ops before dumping PAT settings<br /> <br /> We may leave pat.ops unset when running on brand new platform or<br /> when running as a VF. While the former is unlikely, the latter<br /> is valid (future) use case and will cause NPD when someone will<br /> try to dump PAT settings by debugfs.<br /> <br /> It&amp;#39;s better to check pointer to pat.ops instead of specific .dump<br /> hook, as we have this hook always defined for every .ops variant.