Vulnerabilities

The Betheme theme for WordPress is vulnerable to Stored Cross-Site Scripting via SVG File uploads in all versions up to, and including, 27.5.5 due to insufficient input sanitization and output escaping. This makes it possible for authenticated attackers, with Contributor-level access and above, to inject arbitrary web scripts in pages that will execute whenever a user accesses the SVG file.

The Classified Listing – Classified ads & Business Directory Plugin plugin for WordPress is vulnerable to unauthorized access due to a missing capability check on several functions like export_forms(), import_forms(), update_fb_options(), and many more in all versions up to, and including, 3.1.7. This makes it possible for authenticated attackers, with subscriber-level access and above, to modify forms and various other settings.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> libfs: fix infinite directory reads for offset dir<br /> <br /> After we switch tmpfs dir operations from simple_dir_operations to<br /> simple_offset_dir_operations, every rename happened will fill new dentry<br /> to dest dir&amp;#39;s maple tree(&amp;SHMEM_I(inode)-&gt;dir_offsets-&gt;mt) with a free<br /> key starting with octx-&gt;newx_offset, and then set newx_offset equals to<br /> free key + 1. This will lead to infinite readdir combine with rename<br /> happened at the same time, which fail generic/736 in xfstests(detail show<br /> as below).<br /> <br /> 1. create 5000 files(1 2 3...) under one dir<br /> 2. call readdir(man 3 readdir) once, and get one entry<br /> 3. rename(entry, "TEMPFILE"), then rename("TEMPFILE", entry)<br /> 4. loop 2~3, until readdir return nothing or we loop too many<br /> times(tmpfs break test with the second condition)<br /> <br /> We choose the same logic what commit 9b378f6ad48cf ("btrfs: fix infinite<br /> directory reads") to fix it, record the last_index when we open dir, and<br /> do not emit the entry which index &gt;= last_index. The file-&gt;private_data<br /> now used in offset dir can use directly to do this, and we also update<br /> the last_index when we llseek the dir file.<br /> <br /> [brauner: only update last_index after seek when offset is zero like Jan suggested]

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 /> 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 /> thunderbolt: Mark XDomain as unplugged when router is removed<br /> <br /> I noticed that when we do discrete host router NVM upgrade and it gets<br /> hot-removed from the PCIe side as a result of NVM firmware authentication,<br /> if there is another host connected with enabled paths we hang in tearing<br /> them down. This is due to fact that the Thunderbolt networking driver<br /> also tries to cleanup the paths and ends up blocking in<br /> tb_disconnect_xdomain_paths() waiting for the domain lock.<br /> <br /> However, at this point we already cleaned the paths in tb_stop() so<br /> there is really no need for tb_disconnect_xdomain_paths() to do that<br /> anymore. Furthermore it already checks if the XDomain is unplugged and<br /> bails out early so take advantage of that and mark the XDomain as<br /> unplugged when we remove the parent router.

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 /> 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.