Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> powerpc/rtas: Fix RTAS MSR[HV] handling for Cell<br /> <br /> The semi-recent changes to MSR handling when entering RTAS (firmware)<br /> cause crashes on IBM Cell machines. An example trace:<br /> <br /> kernel tried to execute user page (2fff01a8) - exploit attempt? (uid: 0)<br /> BUG: Unable to handle kernel instruction fetch<br /> Faulting instruction address: 0x2fff01a8<br /> Oops: Kernel access of bad area, sig: 11 [#1]<br /> BE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=4 NUMA Cell<br /> Modules linked in:<br /> CPU: 0 PID: 0 Comm: swapper/0 Tainted: G W 6.0.0-rc2-00433-gede0a8d3307a #207<br /> NIP: 000000002fff01a8 LR: 0000000000032608 CTR: 0000000000000000<br /> REGS: c0000000015236b0 TRAP: 0400 Tainted: G W (6.0.0-rc2-00433-gede0a8d3307a)<br /> MSR: 0000000008001002 CR: 00000000 XER: 20000000<br /> ...<br /> NIP 0x2fff01a8<br /> LR 0x32608<br /> Call Trace:<br /> 0xc00000000143c5f8 (unreliable)<br /> .rtas_call+0x224/0x320<br /> .rtas_get_boot_time+0x70/0x150<br /> .read_persistent_clock64+0x114/0x140<br /> .read_persistent_wall_and_boot_offset+0x24/0x80<br /> .timekeeping_init+0x40/0x29c<br /> .start_kernel+0x674/0x8f0<br /> start_here_common+0x1c/0x50<br /> <br /> Unlike PAPR platforms where RTAS is only used in guests, on the IBM Cell<br /> machines Linux runs with MSR[HV] set but also uses RTAS, provided by<br /> SLOF.<br /> <br /> Fix it by copying the MSR[HV] bit from the MSR value we&amp;#39;ve just read<br /> using mfmsr into the value used for RTAS.<br /> <br /> It seems like we could also fix it using an #ifdef CELL to set MSR[HV],<br /> but that doesn&amp;#39;t work because it&amp;#39;s possible to build a single kernel<br /> image that runs on both Cell native and pseries.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> kcm: fix strp_init() order and cleanup<br /> <br /> strp_init() is called just a few lines above this csk-&gt;sk_user_data<br /> check, it also initializes strp-&gt;work etc., therefore, it is<br /> unnecessary to call strp_done() to cancel the freshly initialized<br /> work.<br /> <br /> And if sk_user_data is already used by KCM, psock-&gt;strp should not be<br /> touched, particularly strp-&gt;work state, so we need to move strp_init()<br /> after the csk-&gt;sk_user_data check.<br /> <br /> This also makes a lockdep warning reported by syzbot go away.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> misc: fastrpc: fix memory corruption on open<br /> <br /> The probe session-duplication overflow check incremented the session<br /> count also when there were no more available sessions so that memory<br /> beyond the fixed-size slab-allocated session array could be corrupted in<br /> fastrpc_session_alloc() on open().

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.

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