Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> perf: Fix event leak upon exit<br /> <br /> When a task is scheduled out, pending sigtrap deliveries are deferred<br /> to the target task upon resume to userspace via task_work.<br /> <br /> However failures while adding an event&amp;#39;s callback to the task_work<br /> engine are ignored. And since the last call for events exit happen<br /> after task work is eventually closed, there is a small window during<br /> which pending sigtrap can be queued though ignored, leaking the event<br /> refcount addition such as in the following scenario:<br /> <br /> TASK A<br /> -----<br /> <br /> do_exit()<br /> exit_task_work(tsk);<br /> <br /> <br /> perf_event_overflow()<br /> event-&gt;pending_sigtrap = pending_id;<br /> irq_work_queue(&amp;event-&gt;pending_irq);<br /> <br /> =========&gt; PREEMPTION: TASK A -&gt; TASK B<br /> event_sched_out()<br /> event-&gt;pending_sigtrap = 0;<br /> atomic_long_inc_not_zero(&amp;event-&gt;refcount)<br /> // FAILS: task work has exited<br /> task_work_add(&amp;event-&gt;pending_task)<br /> [...]<br /> <br /> perf_pending_irq()<br /> // early return: event-&gt;oncpu = -1<br /> <br /> [...]<br /> =========&gt; TASK B -&gt; TASK A<br /> perf_event_exit_task(tsk)<br /> perf_event_exit_event()<br /> free_event()<br /> WARN(atomic_long_cmpxchg(&amp;event-&gt;refcount, 1, 0) != 1)<br /> // leak event due to unexpected refcount == 2<br /> <br /> As a result the event is never released while the task exits.<br /> <br /> Fix this with appropriate task_work_add()&amp;#39;s error handling.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> devres: Fix memory leakage caused by driver API devm_free_percpu()<br /> <br /> It will cause memory leakage when use driver API devm_free_percpu()<br /> to free memory allocated by devm_alloc_percpu(), fixed by using<br /> devres_release() instead of devres_destroy() within devm_free_percpu().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vhost/vsock: always initialize seqpacket_allow<br /> <br /> There are two issues around seqpacket_allow:<br /> 1. seqpacket_allow is not initialized when socket is<br /> created. Thus if features are never set, it will be<br /> read uninitialized.<br /> 2. if VIRTIO_VSOCK_F_SEQPACKET is set and then cleared,<br /> then seqpacket_allow will not be cleared appropriately<br /> (existing apps I know about don&amp;#39;t usually do this but<br /> it&amp;#39;s legal and there&amp;#39;s no way to be sure no one relies<br /> on this).<br /> <br /> To fix:<br /> - initialize seqpacket_allow after allocation<br /> - set it unconditionally in set_features

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> PCI: endpoint: Clean up error handling in vpci_scan_bus()<br /> <br /> Smatch complains about inconsistent NULL checking in vpci_scan_bus():<br /> <br /> drivers/pci/endpoint/functions/pci-epf-vntb.c:1024 vpci_scan_bus() error: we previously assumed &amp;#39;vpci_bus&amp;#39; could be null (see line 1021)<br /> <br /> Instead of printing an error message and then crashing we should return<br /> an error code and clean up.<br /> <br /> Also the NULL check is reversed so it prints an error for success<br /> instead of failure.

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.