Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mac80211: Don&amp;#39;t finalize CSA in IBSS mode if state is disconnected<br /> <br /> When we are not connected to a channel, sending channel "switch"<br /> announcement doesn&amp;#39;t make any sense.<br /> <br /> The BSS list is empty in that case. This causes the for loop in<br /> cfg80211_get_bss() to be bypassed, so the function returns NULL<br /> (check line 1424 of net/wireless/scan.c), causing the WARN_ON()<br /> in ieee80211_ibss_csa_beacon() to get triggered (check line 500<br /> of net/mac80211/ibss.c), which was consequently reported on the<br /> syzkaller dashboard.<br /> <br /> Thus, check if we have an existing connection before generating<br /> the CSA beacon in ieee80211_ibss_finish_csa().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> USB: gadget: Fix obscure lockdep violation for udc_mutex<br /> <br /> A recent commit expanding the scope of the udc_lock mutex in the<br /> gadget core managed to cause an obscure and slightly bizarre lockdep<br /> violation. In abbreviated form:<br /> <br /> ======================================================<br /> WARNING: possible circular locking dependency detected<br /> 5.19.0-rc7+ #12510 Not tainted<br /> ------------------------------------------------------<br /> udevadm/312 is trying to acquire lock:<br /> ffff80000aae1058 (udc_lock){+.+.}-{3:3}, at: usb_udc_uevent+0x54/0xe0<br /> <br /> but task is already holding lock:<br /> ffff000002277548 (kn-&gt;active#4){++++}-{0:0}, at: kernfs_seq_start+0x34/0xe0<br /> <br /> which lock already depends on the new lock.<br /> <br /> the existing dependency chain (in reverse order) is:<br /> <br /> -&gt; #3 (kn-&gt;active#4){++++}-{0:0}:<br />        lock_acquire+0x68/0x84<br />        __kernfs_remove+0x268/0x380<br />        kernfs_remove_by_name_ns+0x58/0xac<br />        sysfs_remove_file_ns+0x18/0x24<br />        device_del+0x15c/0x440<br /> <br /> -&gt; #2 (device_links_lock){+.+.}-{3:3}:<br />        lock_acquire+0x68/0x84<br />        __mutex_lock+0x9c/0x430<br />        mutex_lock_nested+0x38/0x64<br />        device_link_remove+0x3c/0xa0<br />        _regulator_put.part.0+0x168/0x190<br />        regulator_put+0x3c/0x54<br />        devm_regulator_release+0x14/0x20<br /> <br /> -&gt; #1 (regulator_list_mutex){+.+.}-{3:3}:<br />        lock_acquire+0x68/0x84<br />        __mutex_lock+0x9c/0x430<br />        mutex_lock_nested+0x38/0x64<br />        regulator_lock_dependent+0x54/0x284<br />        regulator_enable+0x34/0x80<br />        phy_power_on+0x24/0x130<br />        __dwc2_lowlevel_hw_enable+0x100/0x130<br />        dwc2_lowlevel_hw_enable+0x18/0x40<br />        dwc2_hsotg_udc_start+0x6c/0x2f0<br />        gadget_bind_driver+0x124/0x1f4<br /> <br /> -&gt; #0 (udc_lock){+.+.}-{3:3}:<br />        __lock_acquire+0x1298/0x20cc<br />        lock_acquire.part.0+0xe0/0x230<br />        lock_acquire+0x68/0x84<br />        __mutex_lock+0x9c/0x430<br />        mutex_lock_nested+0x38/0x64<br />        usb_udc_uevent+0x54/0xe0<br /> <br /> Evidently this was caused by the scope of udc_mutex being too large.<br /> The mutex is only meant to protect udc-&gt;driver along with a few other<br /> things. As far as I can tell, there&amp;#39;s no reason for the mutex to be<br /> held while the gadget core calls a gadget driver&amp;#39;s -&gt;bind or -&gt;unbind<br /> routine, or while a UDC is being started or stopped. (This accounts<br /> for link #1 in the chain above, where the mutex is held while the<br /> dwc2_hsotg_udc is started as part of driver probing.)<br /> <br /> Gadget drivers&amp;#39; -&gt;disconnect callbacks are problematic. Even though<br /> usb_gadget_disconnect() will now acquire the udc_mutex, there&amp;#39;s a<br /> window in usb_gadget_bind_driver() between the times when the mutex is<br /> released and the -&gt;bind callback is invoked. If a disconnect occurred<br /> during that window, we could call the driver&amp;#39;s -&gt;disconnect routine<br /> before its -&gt;bind routine. To prevent this from happening, it will be<br /> necessary to prevent a UDC from connecting while it has no gadget<br /> driver. This should be done already but it doesn&amp;#39;t seem to be;<br /> currently usb_gadget_connect() has no check for this. Such a check<br /> will have to be added later.<br /> <br /> Some degree of mutual exclusion is required in soft_connect_store(),<br /> which can dereference udc-&gt;driver at arbitrary times since it is a<br /> sysfs callback. The solution here is to acquire the gadget&amp;#39;s device<br /> lock rather than the udc_mutex. Since the driver core guarantees that<br /> the device lock is always held during driver binding and unbinding,<br /> this will make the accesses in soft_connect_store() mutually exclusive<br /> with any changes to udc-&gt;driver.<br /> <br /> Lastly, it turns out there is one place which should hold the<br /> udc_mutex but currently does not: The function_show() routine needs<br /> protection while it dereferences udc-&gt;driver. The missing lock and<br /> unlock calls are added.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Revert "usb: typec: ucsi: add a common function ucsi_unregister_connectors()"<br /> <br /> The recent commit 87d0e2f41b8c ("usb: typec: ucsi: add a common<br /> function ucsi_unregister_connectors()") introduced a regression that<br /> caused NULL dereference at reading the power supply sysfs. It&amp;#39;s a<br /> stale sysfs entry that should have been removed but remains with NULL<br /> ops. The commit changed the error handling to skip the entries after<br /> a NULL con-&gt;wq, and this leaves the power device unreleased.<br /> <br /> For addressing the regression, the straight revert is applied here.<br /> Further code improvements can be done from the scratch again.

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