Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> staging: rtl8712: fix use after free bugs<br /> <br /> _Read/Write_MACREG callbacks are NULL so the read/write_macreg_hdl()<br /> functions don&amp;#39;t do anything except free the "pcmd" pointer. It<br /> results in a use after free. Delete them.

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

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

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