Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> hwmon: (gpio-fan) Fix array out of bounds access<br /> <br /> The driver does not check if the cooling state passed to<br /> gpio_fan_set_cur_state() exceeds the maximum cooling state as<br /> stored in fan_data-&gt;num_speeds. Since the cooling state is later<br /> used as an array index in set_fan_speed(), an array out of bounds<br /> access can occur.<br /> This can be exploited by setting the state of the thermal cooling device<br /> to arbitrary values, causing for example a kernel oops when unavailable<br /> memory is accessed this way.<br /> <br /> Example kernel oops:<br /> [ 807.987276] Unable to handle kernel paging request at virtual address ffffff80d0588064<br /> [ 807.987369] Mem abort info:<br /> [ 807.987398] ESR = 0x96000005<br /> [ 807.987428] EC = 0x25: DABT (current EL), IL = 32 bits<br /> [ 807.987477] SET = 0, FnV = 0<br /> [ 807.987507] EA = 0, S1PTW = 0<br /> [ 807.987536] FSC = 0x05: level 1 translation fault<br /> [ 807.987570] Data abort info:<br /> [ 807.987763] ISV = 0, ISS = 0x00000005<br /> [ 807.987801] CM = 0, WnR = 0<br /> [ 807.987832] swapper pgtable: 4k pages, 39-bit VAs, pgdp=0000000001165000<br /> [ 807.987872] [ffffff80d0588064] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000<br /> [ 807.987961] Internal error: Oops: 96000005 [#1] PREEMPT SMP<br /> [ 807.987992] Modules linked in: cmac algif_hash aes_arm64 algif_skcipher af_alg bnep hci_uart btbcm bluetooth ecdh_generic ecc 8021q garp stp llc snd_soc_hdmi_codec brcmfmac vc4 brcmutil cec drm_kms_helper snd_soc_core cfg80211 snd_compress bcm2835_codec(C) snd_pcm_dmaengine syscopyarea bcm2835_isp(C) bcm2835_v4l2(C) sysfillrect v4l2_mem2mem bcm2835_mmal_vchiq(C) raspberrypi_hwmon sysimgblt videobuf2_dma_contig videobuf2_vmalloc fb_sys_fops videobuf2_memops rfkill videobuf2_v4l2 videobuf2_common i2c_bcm2835 snd_bcm2835(C) videodev snd_pcm snd_timer snd mc vc_sm_cma(C) gpio_fan uio_pdrv_genirq uio drm fuse drm_panel_orientation_quirks backlight ip_tables x_tables ipv6<br /> [ 807.988508] CPU: 0 PID: 1321 Comm: bash Tainted: G C 5.15.56-v8+ #1575<br /> [ 807.988548] Hardware name: Raspberry Pi 3 Model B Rev 1.2 (DT)<br /> [ 807.988574] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> [ 807.988608] pc : set_fan_speed.part.5+0x34/0x80 [gpio_fan]<br /> [ 807.988654] lr : gpio_fan_set_cur_state+0x34/0x50 [gpio_fan]<br /> [ 807.988691] sp : ffffffc008cf3bd0<br /> [ 807.988710] x29: ffffffc008cf3bd0 x28: ffffff80019edac0 x27: 0000000000000000<br /> [ 807.988762] x26: 0000000000000000 x25: 0000000000000000 x24: ffffff800747c920<br /> [ 807.988787] x23: 000000000000000a x22: ffffff800369f000 x21: 000000001999997c<br /> [ 807.988854] x20: ffffff800369f2e8 x19: ffffff8002ae8080 x18: 0000000000000000<br /> [ 807.988877] x17: 0000000000000000 x16: 0000000000000000 x15: 000000559e271b70<br /> [ 807.988938] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000<br /> [ 807.988960] x11: 0000000000000000 x10: ffffffc008cf3c20 x9 : ffffffcfb60c741c<br /> [ 807.989018] x8 : 000000000000000a x7 : 00000000ffffffc9 x6 : 0000000000000009<br /> [ 807.989040] x5 : 000000000000002a x4 : 0000000000000000 x3 : ffffff800369f2e8<br /> [ 807.989062] x2 : 000000000000e780 x1 : 0000000000000001 x0 : ffffff80d0588060<br /> [ 807.989084] Call trace:<br /> [ 807.989091] set_fan_speed.part.5+0x34/0x80 [gpio_fan]<br /> [ 807.989113] gpio_fan_set_cur_state+0x34/0x50 [gpio_fan]<br /> [ 807.989199] cur_state_store+0x84/0xd0<br /> [ 807.989221] dev_attr_store+0x20/0x38<br /> [ 807.989262] sysfs_kf_write+0x4c/0x60<br /> [ 807.989282] kernfs_fop_write_iter+0x130/0x1c0<br /> [ 807.989298] new_sync_write+0x10c/0x190<br /> [ 807.989315] vfs_write+0x254/0x378<br /> [ 807.989362] ksys_write+0x70/0xf8<br /> [ 807.989379] __arm64_sys_write+0x24/0x30<br /> [ 807.989424] invoke_syscall+0x4c/0x110<br /> [ 807.989442] el0_svc_common.constprop.3+0xfc/0x120<br /> [ 807.989458] do_el0_svc+0x2c/0x90<br /> [ 807.989473] el0_svc+0x24/0x60<br /> [ 807.989544] el0t_64_sync_handler+0x90/0xb8<br /> [ 807.989558] el0t_64_sync+0x1a0/0x1a4<br /> [ 807.989579] Code: b9403801 f9402800 7100003f 8b35cc00 (b9400416)<br /> [ 807.989627] ---[ end t<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> clk: bcm: rpi: Prevent out-of-bounds access<br /> <br /> The while loop in raspberrypi_discover_clocks() relies on the assumption<br /> that the id of the last clock element is zero. Because this data comes<br /> from the Videocore firmware and it doesn&amp;#39;t guarantuee such a behavior<br /> this could lead to out-of-bounds access. So fix this by providing<br /> a sentinel element.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> binder: fix alloc-&gt;vma_vm_mm null-ptr dereference<br /> <br /> Syzbot reported a couple issues introduced by commit 44e602b4e52f<br /> ("binder_alloc: add missing mmap_lock calls when using the VMA"), in<br /> which we attempt to acquire the mmap_lock when alloc-&gt;vma_vm_mm has not<br /> been initialized yet.<br /> <br /> This can happen if a binder_proc receives a transaction without having<br /> previously called mmap() to setup the binder_proc-&gt;alloc space in [1].<br /> Also, a similar issue occurs via binder_alloc_print_pages() when we try<br /> to dump the debugfs binder stats file in [2].<br /> <br /> Sample of syzbot&amp;#39;s crash report:<br /> ==================================================================<br /> KASAN: null-ptr-deref in range [0x0000000000000128-0x000000000000012f]<br /> CPU: 0 PID: 3755 Comm: syz-executor229 Not tainted 6.0.0-rc1-next-20220819-syzkaller #0<br /> syz-executor229[3755] cmdline: ./syz-executor2294415195<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/22/2022<br /> RIP: 0010:__lock_acquire+0xd83/0x56d0 kernel/locking/lockdep.c:4923<br /> [...]<br /> Call Trace:<br /> <br /> lock_acquire kernel/locking/lockdep.c:5666 [inline]<br /> lock_acquire+0x1ab/0x570 kernel/locking/lockdep.c:5631<br /> down_read+0x98/0x450 kernel/locking/rwsem.c:1499<br /> mmap_read_lock include/linux/mmap_lock.h:117 [inline]<br /> binder_alloc_new_buf_locked drivers/android/binder_alloc.c:405 [inline]<br /> binder_alloc_new_buf+0xa5/0x19e0 drivers/android/binder_alloc.c:593<br /> binder_transaction+0x242e/0x9a80 drivers/android/binder.c:3199<br /> binder_thread_write+0x664/0x3220 drivers/android/binder.c:3986<br /> binder_ioctl_write_read drivers/android/binder.c:5036 [inline]<br /> binder_ioctl+0x3470/0x6d00 drivers/android/binder.c:5323<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<br /> [...]<br /> ==================================================================<br /> <br /> Fix these issues by setting up alloc-&gt;vma_vm_mm pointer during open()<br /> and caching directly from current-&gt;mm. This guarantees we have a valid<br /> reference to take the mmap_lock during scenarios described above.<br /> <br /> [1] https://syzkaller.appspot.com/bug?extid=f7dc54e5be28950ac459<br /> [2] https://syzkaller.appspot.com/bug?extid=a75ebe0452711c9e56d9

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().