Vulnerabilities

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.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> gpio: davinci: Validate the obtained number of IRQs<br /> <br /> Value of pdata-&gt;gpio_unbanked is taken from Device Tree. In case of broken<br /> DT due to any error this value can be any. Without this value validation<br /> there can be out of chips-&gt;irqs array boundaries access in<br /> davinci_gpio_probe().<br /> <br /> Validate the obtained nirq value so that it won&amp;#39;t exceed the maximum<br /> number of IRQs per bank.<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with SVACE.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/dpaa2: Avoid explicit cpumask var allocation on stack<br /> <br /> For CONFIG_CPUMASK_OFFSTACK=y kernel, explicit allocation of cpumask<br /> variable on stack is not recommended since it can cause potential stack<br /> overflow.<br /> <br /> Instead, kernel code should always use *cpumask_var API(s) to allocate<br /> cpumask var in config-neutral way, leaving allocation strategy to<br /> CONFIG_CPUMASK_OFFSTACK.<br /> <br /> Use *cpumask_var API(s) to address it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/iucv: Avoid explicit cpumask var allocation on stack<br /> <br /> For CONFIG_CPUMASK_OFFSTACK=y kernel, explicit allocation of cpumask<br /> variable on stack is not recommended since it can cause potential stack<br /> overflow.<br /> <br /> Instead, kernel code should always use *cpumask_var API(s) to allocate<br /> cpumask var in config-neutral way, leaving allocation strategy to<br /> CONFIG_CPUMASK_OFFSTACK.<br /> <br /> Use *cpumask_var API(s) to address it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: mediatek: mt8195: Add platform entry for ETDM1_OUT_BE dai link<br /> <br /> Commit e70b8dd26711 ("ASoC: mediatek: mt8195: Remove afe-dai component<br /> and rework codec link") removed the codec entry for the ETDM1_OUT_BE<br /> dai link entirely instead of replacing it with COMP_EMPTY(). This worked<br /> by accident as the remaining COMP_EMPTY() platform entry became the codec<br /> entry, and the platform entry became completely empty, effectively the<br /> same as COMP_DUMMY() since snd_soc_fill_dummy_dai() doesn&amp;#39;t do anything<br /> for platform entries.<br /> <br /> This causes a KASAN out-of-bounds warning in mtk_soundcard_common_probe()<br /> in sound/soc/mediatek/common/mtk-soundcard-driver.c:<br /> <br /> for_each_card_prelinks(card, i, dai_link) {<br /> if (adsp_node &amp;&amp; !strncmp(dai_link-&gt;name, "AFE_SOF", strlen("AFE_SOF")))<br /> dai_link-&gt;platforms-&gt;of_node = adsp_node;<br /> else if (!dai_link-&gt;platforms-&gt;name &amp;&amp; !dai_link-&gt;platforms-&gt;of_node)<br /> dai_link-&gt;platforms-&gt;of_node = platform_node;<br /> }<br /> <br /> where the code expects the platforms array to have space for at least one entry.<br /> <br /> Add an COMP_EMPTY() entry so that dai_link-&gt;platforms has space.

Zohocorp ManageEngine OpManager, OpManager Plus, OpManager MSP and RMM versions 128317 and below are vulnerable to authenticated SQL injection in the URL monitoring.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ftruncate: pass a signed offset<br /> <br /> The old ftruncate() syscall, using the 32-bit off_t misses a sign<br /> extension when called in compat mode on 64-bit architectures. As a<br /> result, passing a negative length accidentally succeeds in truncating<br /> to file size between 2GiB and 4GiB.<br /> <br /> Changing the type of the compat syscall to the signed compat_off_t<br /> changes the behavior so it instead returns -EINVAL.<br /> <br /> The native entry point, the truncate() syscall and the corresponding<br /> loff_t based variants are all correct already and do not suffer<br /> from this mistake.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: dwc3: core: remove lock of otg mode during gadget suspend/resume to avoid deadlock<br /> <br /> When config CONFIG_USB_DWC3_DUAL_ROLE is selected, and trigger system<br /> to enter suspend status with below command:<br /> echo mem &gt; /sys/power/state<br /> There will be a deadlock issue occurring. Detailed invoking path as<br /> below:<br /> dwc3_suspend_common()<br /> spin_lock_irqsave(&amp;dwc-&gt;lock, flags); lock, flags); gadget_driver is NULL or not. It causes the<br /> following code is executed and deadlock occurs when trying to get the<br /> spinlock. In fact, the root cause is the commit 5265397f9442("usb: dwc3:<br /> Remove DWC3 locking during gadget suspend/resume") that forgot to remove<br /> the lock of otg mode. So, remove the redundant lock of otg mode during<br /> gadget suspend/resume.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iio: chemical: bme680: Fix overflows in compensate() functions<br /> <br /> There are cases in the compensate functions of the driver that<br /> there could be overflows of variables due to bit shifting ops.<br /> These implications were initially discussed here [1] and they<br /> were mentioned in log message of Commit 1b3bd8592780 ("iio:<br /> chemical: Add support for Bosch BME680 sensor").<br /> <br /> [1]: https://lore.kernel.org/linux-iio/20180728114028.3c1bbe81@archlinux/