Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Revert "serial: 8250_omap: Set the console genpd always on if no console suspend"<br /> <br /> This reverts commit 68e6939ea9ec3d6579eadeab16060339cdeaf940.<br /> <br /> Kevin reported that this causes a crash during suspend on platforms that<br /> dont use PM domains.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> workqueue: Fix spruious data race in __flush_work()<br /> <br /> When flushing a work item for cancellation, __flush_work() knows that it<br /> exclusively owns the work item through its PENDING bit. 134874e2eee9<br /> ("workqueue: Allow cancel_work_sync() and disable_work() from atomic<br /> contexts on BH work items") added a read of @work-&gt;data to determine whether<br /> to use busy wait for BH work items that are being canceled. While the read<br /> is safe when @from_cancel, @work-&gt;data was read before testing @from_cancel<br /> to simplify code structure:<br /> <br /> data = *work_data_bits(work);<br /> if (from_cancel &amp;&amp;<br /> !WARN_ON_ONCE(data &amp; WORK_STRUCT_PWQ) &amp;&amp; (data &amp; WORK_OFFQ_BH)) {<br /> <br /> While the read data was never used if !@from_cancel, this could trigger<br /> KCSAN data race detection spuriously:<br /> <br /> ==================================================================<br /> BUG: KCSAN: data-race in __flush_work / __flush_work<br /> <br /> write to 0xffff8881223aa3e8 of 8 bytes by task 3998 on cpu 0:<br /> instrument_write include/linux/instrumented.h:41 [inline]<br /> ___set_bit include/asm-generic/bitops/instrumented-non-atomic.h:28 [inline]<br /> insert_wq_barrier kernel/workqueue.c:3790 [inline]<br /> start_flush_work kernel/workqueue.c:4142 [inline]<br /> __flush_work+0x30b/0x570 kernel/workqueue.c:4178<br /> flush_work kernel/workqueue.c:4229 [inline]<br /> ...<br /> <br /> read to 0xffff8881223aa3e8 of 8 bytes by task 50 on cpu 1:<br /> __flush_work+0x42a/0x570 kernel/workqueue.c:4188<br /> flush_work kernel/workqueue.c:4229 [inline]<br /> flush_delayed_work+0x66/0x70 kernel/workqueue.c:4251<br /> ...<br /> <br /> value changed: 0x0000000000400000 -&gt; 0xffff88810006c00d<br /> <br /> Reorganize the code so that @from_cancel is tested before @work-&gt;data is<br /> accessed. The only problem is triggering KCSAN detection spuriously. This<br /> shouldn&amp;#39;t need READ_ONCE() or other access qualifiers.<br /> <br /> No functional changes.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/xe: reset mmio mappings with devm<br /> <br /> Set our various mmio mappings to NULL. This should make it easier to<br /> catch something rogue trying to mess with mmio after device removal. For<br /> example, we might unmap everything and then start hitting some mmio<br /> address which has already been unmamped by us and then remapped by<br /> something else, causing all kinds of carnage.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tty: serial: fsl_lpuart: mark last busy before uart_add_one_port<br /> <br /> With "earlycon initcall_debug=1 loglevel=8" in bootargs, kernel<br /> sometimes boot hang. It is because normal console still is not ready,<br /> but runtime suspend is called, so early console putchar will hang<br /> in waiting TRDE set in UARTSTAT.<br /> <br /> The lpuart driver has auto suspend delay set to 3000ms, but during<br /> uart_add_one_port, a child device serial ctrl will added and probed with<br /> its pm runtime enabled(see serial_ctrl.c).<br /> The runtime suspend call path is:<br /> device_add<br /> |-&gt; bus_probe_device<br /> |-&gt;device_initial_probe<br /> |-&gt;__device_attach<br /> |-&gt; pm_runtime_get_sync(dev-&gt;parent);<br /> |-&gt; pm_request_idle(dev);<br /> |-&gt; pm_runtime_put(dev-&gt;parent);<br /> <br /> So in the end, before normal console ready, the lpuart get runtime<br /> suspended. And earlycon putchar will hang.<br /> <br /> To address the issue, mark last busy just after pm_runtime_enable,<br /> three seconds is long enough to switch from bootconsole to normal<br /> console.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: arm64: Make ICC_*SGI*_EL1 undef in the absence of a vGICv3<br /> <br /> On a system with a GICv3, if a guest hasn&amp;#39;t been configured with<br /> GICv3 and that the host is not capable of GICv2 emulation,<br /> a write to any of the ICC_*SGI*_EL1 registers is trapped to EL2.<br /> <br /> We therefore try to emulate the SGI access, only to hit a NULL<br /> pointer as no private interrupt is allocated (no GIC, remember?).<br /> <br /> The obvious fix is to give the guest what it deserves, in the<br /> shape of a UNDEF exception.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> pinctrl: qcom: x1e80100: Fix special pin offsets<br /> <br /> Remove the erroneus 0x100000 offset to prevent the boards from crashing<br /> on pin state setting, as well as for the intended state changes to take<br /> effect.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/vmwgfx: Fix prime with external buffers<br /> <br /> Make sure that for external buffers mapping goes through the dma_buf<br /> interface instead of trying to access pages directly.<br /> <br /> External buffers might not provide direct access to readable/writable<br /> pages so to make sure the bo&amp;#39;s created from external dma_bufs can be<br /> read dma_buf interface has to be used.<br /> <br /> Fixes crashes in IGT&amp;#39;s kms_prime with vgem. Regular desktop usage won&amp;#39;t<br /> trigger this due to the fact that virtual machines will not have<br /> multiple GPUs but it enables better test coverage in IGT.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/vmwgfx: Prevent unmapping active read buffers<br /> <br /> The kms paths keep a persistent map active to read and compare the cursor<br /> buffer. These maps can race with each other in simple scenario where:<br /> a) buffer "a" mapped for update<br /> b) buffer "a" mapped for compare<br /> c) do the compare<br /> d) unmap "a" for compare<br /> e) update the cursor<br /> f) unmap "a" for update<br /> At step "e" the buffer has been unmapped and the read contents is bogus.<br /> <br /> Prevent unmapping of active read buffers by simply keeping a count of<br /> how many paths have currently active maps and unmap only when the count<br /> reaches 0.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mptcp: pm: fix ID 0 endp usage after multiple re-creations<br /> <br /> &amp;#39;local_addr_used&amp;#39; and &amp;#39;add_addr_accepted&amp;#39; are decremented for addresses<br /> not related to the initial subflow (ID0), because the source and<br /> destination addresses of the initial subflows are known from the<br /> beginning: they don&amp;#39;t count as "additional local address being used" or<br /> "ADD_ADDR being accepted".<br /> <br /> It is then required not to increment them when the entrypoint used by<br /> the initial subflow is removed and re-added during a connection. Without<br /> this modification, this entrypoint cannot be removed and re-added more<br /> than once.

Media Encoder versions 24.5, 23.6.8 and earlier are affected by an out-of-bounds read vulnerability when parsing a crafted file, which could result in a read past the end of an allocated memory structure. An attacker could leverage this vulnerability to execute code in the context of the current user. Exploitation of this issue requires user interaction in that a victim must open a malicious file.

Media Encoder versions 24.5, 23.6.8 and earlier are affected by an out-of-bounds read vulnerability that could lead to disclosure of sensitive memory. An attacker could leverage this vulnerability to bypass mitigations such as ASLR. Exploitation of this issue requires user interaction in that a victim must open a malicious file.

Media Encoder versions 24.5, 23.6.8 and earlier are affected by an out-of-bounds read vulnerability that could lead to disclosure of sensitive memory. An attacker could leverage this vulnerability to bypass mitigations such as ASLR. Exploitation of this issue requires user interaction in that a victim must open a malicious file.