Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vt: Clear selection before changing the font<br /> <br /> When changing the console font with ioctl(KDFONTOP) the new font size<br /> can be bigger than the previous font. A previous selection may thus now<br /> be outside of the new screen size and thus trigger out-of-bounds<br /> accesses to graphics memory if the selection is removed in<br /> vc_do_resize().<br /> <br /> Prevent such out-of-memory accesses by dropping the selection before the<br /> various con_font_set() console handlers are called.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> firmware_loader: Fix memory leak in firmware upload<br /> <br /> In the case of firmware-upload, an instance of struct fw_upload is<br /> allocated in firmware_upload_register(). This data needs to be freed<br /> in fw_dev_release(). Create a new fw_upload_free() function in<br /> sysfs_upload.c to handle the firmware-upload specific memory frees<br /> and incorporate the missing kfree call for the fw_upload structure.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dma-buf/dma-resv: check if the new fence is really later<br /> <br /> Previously when we added a fence to a dma_resv object we always<br /> assumed the the newer than all the existing fences.<br /> <br /> With Jason&amp;#39;s work to add an UAPI to explicit export/import that&amp;#39;s not<br /> necessary the case any more. So without this check we would allow<br /> userspace to force the kernel into an use after free error.<br /> <br /> Since the change is very small and defensive it&amp;#39;s probably a good<br /> idea to backport this to stable kernels as well just in case others<br /> are using the dma_resv object in the same way.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> USB: core: Prevent nested device-reset calls<br /> <br /> Automatic kernel fuzzing revealed a recursive locking violation in<br /> usb-storage:<br /> <br /> ============================================<br /> WARNING: possible recursive locking detected<br /> 5.18.0 #3 Not tainted<br /> --------------------------------------------<br /> kworker/1:3/1205 is trying to acquire lock:<br /> ffff888018638db8 (&amp;us_interface_key[i]){+.+.}-{3:3}, at:<br /> usb_stor_pre_reset+0x35/0x40 drivers/usb/storage/usb.c:230<br /> <br /> but task is already holding lock:<br /> ffff888018638db8 (&amp;us_interface_key[i]){+.+.}-{3:3}, at:<br /> usb_stor_pre_reset+0x35/0x40 drivers/usb/storage/usb.c:230<br /> <br /> ...<br /> <br /> stack backtrace:<br /> CPU: 1 PID: 1205 Comm: kworker/1:3 Not tainted 5.18.0 #3<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS<br /> 1.13.0-1ubuntu1.1 04/01/2014<br /> Workqueue: usb_hub_wq hub_event<br /> Call Trace:<br /> <br /> __dump_stack lib/dump_stack.c:88 [inline]<br /> dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106<br /> print_deadlock_bug kernel/locking/lockdep.c:2988 [inline]<br /> check_deadlock kernel/locking/lockdep.c:3031 [inline]<br /> validate_chain kernel/locking/lockdep.c:3816 [inline]<br /> __lock_acquire.cold+0x152/0x3ca kernel/locking/lockdep.c:5053<br /> lock_acquire kernel/locking/lockdep.c:5665 [inline]<br /> lock_acquire+0x1ab/0x520 kernel/locking/lockdep.c:5630<br /> __mutex_lock_common kernel/locking/mutex.c:603 [inline]<br /> __mutex_lock+0x14f/0x1610 kernel/locking/mutex.c:747<br /> usb_stor_pre_reset+0x35/0x40 drivers/usb/storage/usb.c:230<br /> usb_reset_device+0x37d/0x9a0 drivers/usb/core/hub.c:6109<br /> r871xu_dev_remove+0x21a/0x270 drivers/staging/rtl8712/usb_intf.c:622<br /> usb_unbind_interface+0x1bd/0x890 drivers/usb/core/driver.c:458<br /> device_remove drivers/base/dd.c:545 [inline]<br /> device_remove+0x11f/0x170 drivers/base/dd.c:537<br /> __device_release_driver drivers/base/dd.c:1222 [inline]<br /> device_release_driver_internal+0x1a7/0x2f0 drivers/base/dd.c:1248<br /> usb_driver_release_interface+0x102/0x180 drivers/usb/core/driver.c:627<br /> usb_forced_unbind_intf+0x4d/0xa0 drivers/usb/core/driver.c:1118<br /> usb_reset_device+0x39b/0x9a0 drivers/usb/core/hub.c:6114<br /> <br /> This turned out not to be an error in usb-storage but rather a nested<br /> device reset attempt. That is, as the rtl8712 driver was being<br /> unbound from a composite device in preparation for an unrelated USB<br /> reset (that driver does not have pre_reset or post_reset callbacks),<br /> its -&gt;remove routine called usb_reset_device() -- thus nesting one<br /> reset call within another.<br /> <br /> Performing a reset as part of disconnect processing is a questionable<br /> practice at best. However, the bug report points out that the USB<br /> core does not have any protection against nested resets. Adding a<br /> reset_in_progress flag and testing it will prevent such errors in the<br /> future.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: mceusb: Use new usb_control_msg_*() routines<br /> <br /> Automatic kernel fuzzing led to a WARN about invalid pipe direction in<br /> the mceusb driver:<br /> <br /> ------------[ cut here ]------------<br /> usb 6-1: BOGUS control dir, pipe 80000380 doesn&amp;#39;t match bRequestType 40<br /> WARNING: CPU: 0 PID: 2465 at drivers/usb/core/urb.c:410<br /> usb_submit_urb+0x1326/0x1820 drivers/usb/core/urb.c:410<br /> Modules linked in:<br /> CPU: 0 PID: 2465 Comm: kworker/0:2 Not tainted 5.19.0-rc4-00208-g69cb6c6556ad #1<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS<br /> 1.13.0-1ubuntu1.1 04/01/2014<br /> Workqueue: usb_hub_wq hub_event<br /> RIP: 0010:usb_submit_urb+0x1326/0x1820 drivers/usb/core/urb.c:410<br /> Code: 7c 24 40 e8 ac 23 91 fd 48 8b 7c 24 40 e8 b2 70 1b ff 45 89 e8<br /> 44 89 f1 4c 89 e2 48 89 c6 48 c7 c7 a0 30 a9 86 e8 48 07 11 02 0b<br /> e9 1c f0 ff ff e8 7e 23 91 fd 0f b6 1d 63 22 83 05 31 ff 41<br /> RSP: 0018:ffffc900032becf0 EFLAGS: 00010282<br /> RAX: 0000000000000000 RBX: ffff8881100f3058 RCX: 0000000000000000<br /> RDX: ffffc90004961000 RSI: ffff888114c6d580 RDI: fffff52000657d90<br /> RBP: ffff888105ad90f0 R08: ffffffff812c3638 R09: 0000000000000000<br /> R10: 0000000000000005 R11: ffffed1023504ef1 R12: ffff888105ad9000<br /> R13: 0000000000000040 R14: 0000000080000380 R15: ffff88810ba96500<br /> FS: 0000000000000000(0000) GS:ffff88811a800000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007ffe810bda58 CR3: 000000010b720000 CR4: 0000000000350ef0<br /> Call Trace:<br /> <br /> usb_start_wait_urb+0x101/0x4c0 drivers/usb/core/message.c:58<br /> usb_internal_control_msg drivers/usb/core/message.c:102 [inline]<br /> usb_control_msg+0x31c/0x4a0 drivers/usb/core/message.c:153<br /> mceusb_gen1_init drivers/media/rc/mceusb.c:1431 [inline]<br /> mceusb_dev_probe+0x258e/0x33f0 drivers/media/rc/mceusb.c:1807<br /> <br /> The reason for the warning is clear enough; the driver sends an<br /> unusual read request on endpoint 0 but does not set the USB_DIR_IN bit<br /> in the bRequestType field.<br /> <br /> More importantly, the whole situation can be avoided and the driver<br /> simplified by converting it over to the relatively new<br /> usb_control_msg_recv() and usb_control_msg_send() routines. That&amp;#39;s<br /> what this fix does.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cifs: fix small mempool leak in SMB2_negotiate()<br /> <br /> In some cases of failure (dialect mismatches) in SMB2_negotiate(), after<br /> the request is sent, the checks would return -EIO when they should be<br /> rather setting rc = -EIO and jumping to neg_exit to free the response<br /> buffer from mempool.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> binder: fix UAF of ref-&gt;proc caused by race condition<br /> <br /> A transaction of type BINDER_TYPE_WEAK_HANDLE can fail to increment the<br /> reference for a node. In this case, the target proc normally releases<br /> the failed reference upon close as expected. However, if the target is<br /> dying in parallel the call will race with binder_deferred_release(), so<br /> the target could have released all of its references by now leaving the<br /> cleanup of the new failed reference unhandled.<br /> <br /> The transaction then ends and the target proc gets released making the<br /> ref-&gt;proc now a dangling pointer. Later on, ref-&gt;node is closed and we<br /> attempt to take spin_lock(&amp;ref-&gt;proc-&gt;inner_lock), which leads to the<br /> use-after-free bug reported below. Let&amp;#39;s fix this by cleaning up the<br /> failed reference on the spot instead of relying on the target to do so.<br /> <br /> ==================================================================<br /> BUG: KASAN: use-after-free in _raw_spin_lock+0xa8/0x150<br /> Write of size 4 at addr ffff5ca207094238 by task kworker/1:0/590<br /> <br /> CPU: 1 PID: 590 Comm: kworker/1:0 Not tainted 5.19.0-rc8 #10<br /> Hardware name: linux,dummy-virt (DT)<br /> Workqueue: events binder_deferred_func<br /> Call trace:<br /> dump_backtrace.part.0+0x1d0/0x1e0<br /> show_stack+0x18/0x70<br /> dump_stack_lvl+0x68/0x84<br /> print_report+0x2e4/0x61c<br /> kasan_report+0xa4/0x110<br /> kasan_check_range+0xfc/0x1a4<br /> __kasan_check_write+0x3c/0x50<br /> _raw_spin_lock+0xa8/0x150<br /> binder_deferred_func+0x5e0/0x9b0<br /> process_one_work+0x38c/0x5f0<br /> worker_thread+0x9c/0x694<br /> kthread+0x188/0x190<br /> ret_from_fork+0x10/0x20

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tty: n_gsm: add sanity check for gsm-&gt;receive in gsm_receive_buf()<br /> <br /> A null pointer dereference can happen when attempting to access the<br /> "gsm-&gt;receive()" function in gsmld_receive_buf(). Currently, the code<br /> assumes that gsm-&gt;recieve is only called after MUX activation.<br /> Since the gsmld_receive_buf() function can be accessed without the need to<br /> initialize the MUX, the gsm-&gt;receive() function will not be set and a<br /> NULL pointer dereference will occur.<br /> <br /> Fix this by avoiding the call to "gsm-&gt;receive()" in case the function is<br /> not initialized by adding a sanity check.<br /> <br /> Call Trace:<br /> <br /> gsmld_receive_buf+0x1c2/0x2f0 drivers/tty/n_gsm.c:2861<br /> tiocsti drivers/tty/tty_io.c:2293 [inline]<br /> tty_ioctl+0xa75/0x15d0 drivers/tty/tty_io.c:2692<br /> vfs_ioctl fs/ioctl.c:51 [inline]<br /> __do_sys_ioctl fs/ioctl.c:870 [inline]<br /> __se_sys_ioctl fs/ioctl.c:856 [inline]<br /> __x64_sys_ioctl+0x193/0x200 fs/ioctl.c:856<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mac80211: Fix UAF in ieee80211_scan_rx()<br /> <br /> ieee80211_scan_rx() tries to access scan_req-&gt;flags after a<br /> null check, but a UAF is observed when the scan is completed<br /> and __ieee80211_scan_completed() executes, which then calls<br /> cfg80211_scan_done() leading to the freeing of scan_req.<br /> <br /> Since scan_req is rcu_dereference()&amp;#39;d, prevent the racing in<br /> __ieee80211_scan_completed() by ensuring that from mac80211&amp;#39;s<br /> POV it is no longer accessed from an RCU read critical section<br /> before we call cfg80211_scan_done().

The Target Video Easy Publish plugin for WordPress is vulnerable to Stored Cross-Site Scripting via the ‘width’ parameter in all versions up to, and including, 3.8.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 an injected page.

The CSV Me plugin for WordPress is vulnerable to arbitrary file uploads due to insufficient file type validation in the &amp;#39;csv_me_options_page&amp;#39; function in all versions up to, and including, 2.0. This makes it possible for authenticated attackers, with Administrator-level access and above, to upload arbitrary files on the affected site&amp;#39;s server which may make remote code execution possible.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: pcm: Fix race of buffer access at PCM OSS layer<br /> <br /> The PCM OSS layer tries to clear the buffer with the silence data at<br /> initialization (or reconfiguration) of a stream with the explicit call<br /> of snd_pcm_format_set_silence() with runtime-&gt;dma_area. But this may<br /> lead to a UAF because the accessed runtime-&gt;dma_area might be freed<br /> concurrently, as it&amp;#39;s performed outside the PCM ops.<br /> <br /> For avoiding it, move the code into the PCM core and perform it inside<br /> the buffer access lock, so that it won&amp;#39;t be changed during the<br /> operation.