Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> firmware_loader: Fix use-after-free during unregister<br /> <br /> In the following code within firmware_upload_unregister(), the call to<br /> device_unregister() could result in the dev_release function freeing the<br /> fw_upload_priv structure before it is dereferenced for the call to<br /> module_put(). This bug was found by the kernel test robot using<br /> CONFIG_KASAN while running the firmware selftests.<br /> <br /> device_unregister(&amp;fw_sysfs-&gt;dev);<br /> module_put(fw_upload_priv-&gt;module);<br /> <br /> The problem is fixed by copying fw_upload_priv-&gt;module to a local variable<br /> for use when calling device_unregister().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> misc: fastrpc: fix memory corruption on probe<br /> <br /> Add the missing sanity check on the probed-session count to avoid<br /> corrupting memory beyond the fixed-size slab-allocated session array<br /> when there are more than FASTRPC_MAX_SESSIONS sessions defined in the<br /> devicetree.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iio: light: cm3605: Fix an error handling path in cm3605_probe()<br /> <br /> The commit in Fixes also introduced a new error handling path which should<br /> goto the existing error handling path.<br /> Otherwise some resources leak.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Input: iforce - wake up after clearing IFORCE_XMIT_RUNNING flag<br /> <br /> syzbot is reporting hung task at __input_unregister_device() [1], for<br /> iforce_close() waiting at wait_event_interruptible() with dev-&gt;mutex held<br /> is blocking input_disconnect_device() from __input_unregister_device().<br /> <br /> It seems that the cause is simply that commit c2b27ef672992a20 ("Input:<br /> iforce - wait for command completion when closing the device") forgot to<br /> call wake_up() after clear_bit().<br /> <br /> Fix this problem by introducing a helper that calls clear_bit() followed<br /> by wake_up_all().

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.