Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Input: appletouch - initialize work before device registration<br /> <br /> Syzbot has reported warning in __flush_work(). This warning is caused by<br /> work-&gt;func == NULL, which means missing work initialization.<br /> <br /> This may happen, since input_dev-&gt;close() calls<br /> cancel_work_sync(&amp;dev-&gt;work), but dev-&gt;work initalization happens _after_<br /> input_register_device() call.<br /> <br /> So this patch moves dev-&gt;work initialization before registering input<br /> device

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: gadget: f_fs: Clear ffs_eventfd in ffs_data_clear.<br /> <br /> ffs_data_clear is indirectly called from both ffs_fs_kill_sb and<br /> ffs_ep0_release, so it ends up being called twice when userland closes ep0<br /> and then unmounts f_fs.<br /> If userland provided an eventfd along with function&amp;#39;s USB descriptors, it<br /> ends up calling eventfd_ctx_put as many times, causing a refcount<br /> underflow.<br /> NULL-ify ffs_eventfd to prevent these extraneous eventfd_ctx_put calls.<br /> <br /> Also, set epfiles to NULL right after de-allocating it, for readability.<br /> <br /> For completeness, ffs_data_clear actually ends up being called thrice, the<br /> last call being before the whole ffs structure gets freed, so when this<br /> specific sequence happens there is a second underflow happening (but not<br /> being reported):<br /> <br /> /sys/kernel/debug/tracing# modprobe usb_f_fs<br /> /sys/kernel/debug/tracing# echo ffs_data_clear &gt; set_ftrace_filter<br /> /sys/kernel/debug/tracing# echo function &gt; current_tracer<br /> /sys/kernel/debug/tracing# echo 1 &gt; tracing_on<br /> (setup gadget, run and kill function userland process, teardown gadget)<br /> /sys/kernel/debug/tracing# echo 0 &gt; tracing_on<br /> /sys/kernel/debug/tracing# cat trace<br /> smartcard-openp-436 [000] ..... 1946.208786: ffs_data_clear

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> i2c: validate user data in compat ioctl<br /> <br /> Wrong user data may cause warning in i2c_transfer(), ex: zero msgs.<br /> Userspace should not be able to trigger warnings, so this patch adds<br /> validation checks for user data in compact ioctl to prevent reported<br /> warnings

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> binder: fix async_free_space accounting for empty parcels<br /> <br /> In 4.13, commit 74310e06be4d ("android: binder: Move buffer out of area shared with user space")<br /> fixed a kernel structure visibility issue. As part of that patch,<br /> sizeof(void *) was used as the buffer size for 0-length data payloads so<br /> the driver could detect abusive clients sending 0-length asynchronous<br /> transactions to a server by enforcing limits on async_free_size.<br /> <br /> Unfortunately, on the "free" side, the accounting of async_free_space<br /> did not add the sizeof(void *) back. The result was that up to 8-bytes of<br /> async_free_space were leaked on every async transaction of 8-bytes or<br /> less. These small transactions are uncommon, so this accounting issue<br /> has gone undetected for several years.<br /> <br /> The fix is to use "buffer_size" (the allocated buffer size) instead of<br /> "size" (the logical buffer size) when updating the async_free_space<br /> during the free operation. These are the same except for this<br /> corner case of asynchronous transactions with payloads

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> locking/qrwlock: Fix ordering in queued_write_lock_slowpath()<br /> <br /> While this code is executed with the wait_lock held, a reader can<br /> acquire the lock without holding wait_lock. The writer side loops<br /> checking the value with the atomic_cond_read_acquire(), but only truly<br /> acquires the lock when the compare-and-exchange is completed<br /> successfully which isn’t ordered. This exposes the window between the<br /> acquire and the cmpxchg to an A-B-A problem which allows reads<br /> following the lock acquisition to observe values speculatively before<br /> the write lock is truly acquired.<br /> <br /> We&amp;#39;ve seen a problem in epoll where the reader does a xchg while<br /> holding the read lock, but the writer can see a value change out from<br /> under it.<br /> <br /> Writer | Reader<br /> --------------------------------------------------------------------------------<br /> ep_scan_ready_list() |<br /> |- write_lock_irq() |<br /> |- queued_write_lock_slowpath() |<br /> |- atomic_cond_read_acquire() |<br /> | read_lock_irqsave(&amp;ep-&gt;lock, flags);<br /> --&gt; (observes value before unlock) | chain_epi_lockless()<br /> | | epi-&gt;next = xchg(&amp;ep-&gt;ovflist, epi);<br /> | | read_unlock_irqrestore(&amp;ep-&gt;lock, flags);<br /> | |<br /> | atomic_cmpxchg_relaxed() |<br /> |-- READ_ONCE(ep-&gt;ovflist); |<br /> <br /> A core can order the read of the ovflist ahead of the<br /> atomic_cmpxchg_relaxed(). Switching the cmpxchg to use acquire<br /> semantics addresses this issue at which point the atomic_cond_read can<br /> be switched to use relaxed semantics.<br /> <br /> [peterz: use try_cmpxchg()]

The WP JobSearch WordPress plugin before 2.3.4 does not prevent attackers from logging-in as any users with the only knowledge of that user&amp;#39;s email address.

The WP JobSearch WordPress plugin before 2.3.4 does not validate files to be uploaded, which could allow unauthenticated attackers to upload arbitrary files such as PHP on the server

The Page Builder: Pagelayer WordPress plugin before 1.8.1 does not sanitise and escape some of its settings, which could allow high privilege users such as admin to perform Stored Cross-Site Scripting attacks even when the unfiltered_html capability is disallowed (for example in multisite setup)

The JetBackup WordPress plugin before 2.0.9.9 doesn&amp;#39;t use index files to prevent public directory listing of sensitive directories in certain configurations, which allows malicious actors to leak backup files.

The Persian Fonts WordPress plugin through 1.6 does not sanitise and escape some of its settings, which could allow high privilege users such as admin to perform Stored Cross-Site Scripting attacks even when the unfiltered_html capability is disallowed (for example in multisite setup).

The WP Dashboard Notes WordPress plugin before 1.0.11 is vulnerable to Insecure Direct Object References (IDOR) in post_id= parameter. Authenticated users are able to delete private notes associated with different user accounts. This poses a significant security risk as it violates the principle of least privilege and compromises the integrity and privacy of user data.

The Fatal Error Notify WordPress plugin before 1.5.3 does not have authorisation and CSRF checks in its test_error AJAX action, allowing any authenticated users, such as subscriber to call it and spam the admin email address with error messages. The issue is also exploitable via CSRF