Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> PCI: rcar: Demote WARN() to dev_warn_ratelimited() in rcar_pcie_wakeup()<br /> <br /> Avoid large backtrace, it is sufficient to warn the user that there has<br /> been a link problem. Either the link has failed and the system is in need<br /> of maintenance, or the link continues to work and user has been informed.<br /> The message from the warning can be looked up in the sources.<br /> <br /> This makes an actual link issue less verbose.<br /> <br /> First of all, this controller has a limitation in that the controller<br /> driver has to assist the hardware with transition to L1 link state by<br /> writing L1IATN to PMCTRL register, the L1 and L0 link state switching<br /> is not fully automatic on this controller.<br /> <br /> In case of an ASMedia ASM1062 PCIe SATA controller which does not support<br /> ASPM, on entry to suspend or during platform pm_test, the SATA controller<br /> enters D3hot state and the link enters L1 state. If the SATA controller<br /> wakes up before rcar_pcie_wakeup() was called and returns to D0, the link<br /> returns to L0 before the controller driver even started its transition to<br /> L1 link state. At this point, the SATA controller did send an PM_ENTER_L1<br /> DLLP to the PCIe controller and the PCIe controller received it, and the<br /> PCIe controller did set PMSR PMEL1RX bit.<br /> <br /> Once rcar_pcie_wakeup() is called, if the link is already back in L0 state<br /> and PMEL1RX bit is set, the controller driver has no way to determine if<br /> it should perform the link transition to L1 state, or treat the link as if<br /> it is in L0 state. Currently the driver attempts to perform the transition<br /> to L1 link state unconditionally, which in this specific case fails with a<br /> PMSR L1FAEG poll timeout, however the link still works as it is already<br /> back in L0 state.<br /> <br /> Reduce this warning verbosity. In case the link is really broken, the<br /> rcar_pcie_config_access() would fail, otherwise it will succeed and any<br /> system with this controller and ASM1062 can suspend without generating<br /> a backtrace.

A vulnerability was found in Genexis Tilgin Home Gateway 322_AS0500-03_05_13_05. It has been rated as problematic. This issue affects some unknown processing of the file /vood/cgi-bin/vood_view.cgi?lang=EN&amp;act=user/spec_conf&amp;sessionId=86213915328111654515&amp;user=A&amp;message2user=Account%20updated. The manipulation of the argument Phone Number leads to cross site scripting. The attack may be initiated remotely. The exploit has been disclosed to the public and may be used. NOTE: The vendor was contacted early about this disclosure but did not respond in any way.

A vulnerability classified as critical has been found in chillzhuang SpringBlade 4.1.0. Affected is an unknown function of the file /api/blade-system/menu/list?updatexml. The manipulation leads to sql injection. It is possible to launch the attack remotely. The exploit has been disclosed to the public and may be used. NOTE: The vendor was contacted early about this disclosure but did not respond in any way.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5: Always drain health in shutdown callback<br /> <br /> There is no point in recovery during device shutdown. if health<br /> work started need to wait for it to avoid races and NULL pointer<br /> access.<br /> <br /> Hence, drain health WQ on shutdown callback.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/nouveau: prime: fix refcount underflow<br /> <br /> Calling nouveau_bo_ref() on a nouveau_bo without initializing it (and<br /> hence the backing ttm_bo) leads to a refcount underflow.<br /> <br /> Instead of calling nouveau_bo_ref() in the unwind path of<br /> drm_gem_object_init(), clean things up manually.<br /> <br /> (cherry picked from commit 1b93f3e89d03cfc576636e195466a0d728ad8de5)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> riscv/purgatory: align riscv_kernel_entry<br /> <br /> When alignment handling is delegated to the kernel, everything must be<br /> word-aligned in purgatory, since the trap handler is then set to the<br /> kexec one. Without the alignment, hitting the exception would<br /> ultimately crash. On other occasions, the kernel&amp;#39;s handler would take<br /> care of exceptions.<br /> This has been tested on a JH7110 SoC with oreboot and its SBI delegating<br /> unaligned access exceptions and the kernel configured to handle them.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: wan: fsl_qmc_hdlc: Convert carrier_lock spinlock to a mutex<br /> <br /> The carrier_lock spinlock protects the carrier detection. While it is<br /> held, framer_get_status() is called which in turn takes a mutex.<br /> This is not correct and can lead to a deadlock.<br /> <br /> A run with PROVE_LOCKING enabled detected the issue:<br /> [ BUG: Invalid wait context ]<br /> ...<br /> c204ddbc (&amp;framer-&gt;mutex){+.+.}-{3:3}, at: framer_get_status+0x40/0x78<br /> other info that might help us debug this:<br /> context-{4:4}<br /> 2 locks held by ifconfig/146:<br /> #0: c0926a38 (rtnl_mutex){+.+.}-{3:3}, at: devinet_ioctl+0x12c/0x664<br /> #1: c2006a40 (&amp;qmc_hdlc-&gt;carrier_lock){....}-{2:2}, at: qmc_hdlc_framer_set_carrier+0x30/0x98<br /> <br /> Avoid the spinlock usage and convert carrier_lock to a mutex.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5e: Fix CT entry update leaks of modify header context<br /> <br /> The cited commit allocates a new modify header to replace the old<br /> one when updating CT entry. But if failed to allocate a new one, eg.<br /> exceed the max number firmware can support, modify header will be<br /> an error pointer that will trigger a panic when deallocating it. And<br /> the old modify header point is copied to old attr. When the old<br /> attr is freed, the old modify header is lost.<br /> <br /> Fix it by restoring the old attr to attr when failed to allocate a<br /> new modify header context. So when the CT entry is freed, the right<br /> modify header context will be freed. And the panic of accessing<br /> error pointer is also fixed.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> s390/fpu: Re-add exception handling in load_fpu_state()<br /> <br /> With the recent rewrite of the fpu code exception handling for the<br /> lfpc instruction within load_fpu_state() was erroneously removed.<br /> <br /> Add it again to prevent that loading invalid floating point register<br /> values cause an unhandled specification exception.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/vmwgfx: Fix a deadlock in dma buf fence polling<br /> <br /> Introduce a version of the fence ops that on release doesn&amp;#39;t remove<br /> the fence from the pending list, and thus doesn&amp;#39;t require a lock to<br /> fix poll-&gt;fence wait-&gt;fence unref deadlocks.<br /> <br /> vmwgfx overwrites the wait callback to iterate over the list of all<br /> fences and update their status, to do that it holds a lock to prevent<br /> the list modifcations from other threads. The fence destroy callback<br /> both deletes the fence and removes it from the list of pending<br /> fences, for which it holds a lock.<br /> <br /> dma buf polling cb unrefs a fence after it&amp;#39;s been signaled: so the poll<br /> calls the wait, which signals the fences, which are being destroyed.<br /> The destruction tries to acquire the lock on the pending fences list<br /> which it can never get because it&amp;#39;s held by the wait from which it<br /> was called.<br /> <br /> Old bug, but not a lot of userspace apps were using dma-buf polling<br /> interfaces. Fix those, in particular this fixes KDE stalls/deadlock.

** UNSUPPORTED WHEN ASSIGNED ** The Apache Helix Front (UI) component contained a hard-coded secret, allowing an attacker to spoof sessions by generating their own fake cookies.<br /> <br /> This issue affects Apache Helix Front (UI): all versions.<br /> <br /> As this project is retired, we do not plan to release a version that fixes this issue. Users are recommended to find an alternative or restrict access to the instance to trusted users.<br /> <br /> NOTE: This vulnerability only affects products that are no longer supported by the maintainer.

Kanister is a data protection workflow management tool. The kanister has a deployment called default-kanister-operator, which is bound with a ClusterRole called edit via ClusterRoleBinding. The "edit" ClusterRole is one of Kubernetes default-created ClusterRole, and it has the create/patch/udpate verbs of daemonset resources, create verb of serviceaccount/token resources, and impersonate verb of serviceaccounts resources. A malicious user can leverage access the worker node which has this component to make a cluster-level privilege escalation.