Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nbd: fix race between nbd_alloc_config() and module removal<br /> <br /> When nbd module is being removing, nbd_alloc_config() may be<br /> called concurrently by nbd_genl_connect(), although try_module_get()<br /> will return false, but nbd_alloc_config() doesn&amp;#39;t handle it.<br /> <br /> The race may lead to the leak of nbd_config and its related<br /> resources (e.g, recv_workq) and oops in nbd_read_stat() due<br /> to the unload of nbd module as shown below:<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000040<br /> Oops: 0000 [#1] SMP PTI<br /> CPU: 5 PID: 13840 Comm: kworker/u17:33 Not tainted 5.14.0+ #1<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)<br /> Workqueue: knbd16-recv recv_work [nbd]<br /> RIP: 0010:nbd_read_stat.cold+0x130/0x1a4 [nbd]<br /> Call Trace:<br /> recv_work+0x3b/0xb0 [nbd]<br /> process_one_work+0x1ed/0x390<br /> worker_thread+0x4a/0x3d0<br /> kthread+0x12a/0x150<br /> ret_from_fork+0x22/0x30<br /> <br /> Fixing it by checking the return value of try_module_get()<br /> in nbd_alloc_config(). As nbd_alloc_config() may return ERR_PTR(-ENODEV),<br /> assign nbd-&gt;config only when nbd_alloc_config() succeeds to ensure<br /> the value of nbd-&gt;config is binary (valid or NULL).<br /> <br /> Also adding a debug message to check the reference counter<br /> of nbd_config during module removal.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> staging: rtl8712: fix uninit-value in usb_read8() and friends<br /> <br /> When r8712_usbctrl_vendorreq() returns negative, &amp;#39;data&amp;#39; in<br /> usb_read{8,16,32} will not be initialized.<br /> <br /> BUG: KMSAN: uninit-value in string_nocheck lib/vsprintf.c:643 [inline]<br /> BUG: KMSAN: uninit-value in string+0x4ec/0x6f0 lib/vsprintf.c:725<br /> string_nocheck lib/vsprintf.c:643 [inline]<br /> string+0x4ec/0x6f0 lib/vsprintf.c:725<br /> vsnprintf+0x2222/0x3650 lib/vsprintf.c:2806<br /> va_format lib/vsprintf.c:1704 [inline]<br /> pointer+0x18e6/0x1f70 lib/vsprintf.c:2443<br /> vsnprintf+0x1a9b/0x3650 lib/vsprintf.c:2810<br /> vprintk_store+0x537/0x2150 kernel/printk/printk.c:2158<br /> vprintk_emit+0x28b/0xab0 kernel/printk/printk.c:2256<br /> dev_vprintk_emit+0x5ef/0x6d0 drivers/base/core.c:4604<br /> dev_printk_emit+0x1dd/0x21f drivers/base/core.c:4615<br /> __dev_printk+0x3be/0x440 drivers/base/core.c:4627<br /> _dev_info+0x1ea/0x22f drivers/base/core.c:4673<br /> r871xu_drv_init+0x1929/0x3070 drivers/staging/rtl8712/usb_intf.c:401<br /> usb_probe_interface+0xf19/0x1600 drivers/usb/core/driver.c:396<br /> really_probe+0x6c7/0x1350 drivers/base/dd.c:621<br /> __driver_probe_device+0x3e9/0x530 drivers/base/dd.c:752<br /> driver_probe_device drivers/base/dd.c:782 [inline]<br /> __device_attach_driver+0x79f/0x1120 drivers/base/dd.c:899<br /> bus_for_each_drv+0x2d6/0x3f0 drivers/base/bus.c:427<br /> __device_attach+0x593/0x8e0 drivers/base/dd.c:970<br /> device_initial_probe+0x4a/0x60 drivers/base/dd.c:1017<br /> bus_probe_device+0x17b/0x3e0 drivers/base/bus.c:487<br /> device_add+0x1fff/0x26e0 drivers/base/core.c:3405<br /> usb_set_configuration+0x37e9/0x3ed0 drivers/usb/core/message.c:2170<br /> usb_generic_driver_probe+0x13c/0x300 drivers/usb/core/generic.c:238<br /> usb_probe_device+0x309/0x570 drivers/usb/core/driver.c:293<br /> really_probe+0x6c7/0x1350 drivers/base/dd.c:621<br /> __driver_probe_device+0x3e9/0x530 drivers/base/dd.c:752<br /> driver_probe_device drivers/base/dd.c:782 [inline]<br /> __device_attach_driver+0x79f/0x1120 drivers/base/dd.c:899<br /> bus_for_each_drv+0x2d6/0x3f0 drivers/base/bus.c:427<br /> __device_attach+0x593/0x8e0 drivers/base/dd.c:970<br /> device_initial_probe+0x4a/0x60 drivers/base/dd.c:1017<br /> bus_probe_device+0x17b/0x3e0 drivers/base/bus.c:487<br /> device_add+0x1fff/0x26e0 drivers/base/core.c:3405<br /> usb_new_device+0x1b91/0x2950 drivers/usb/core/hub.c:2566<br /> hub_port_connect drivers/usb/core/hub.c:5363 [inline]<br /> hub_port_connect_change drivers/usb/core/hub.c:5507 [inline]<br /> port_event drivers/usb/core/hub.c:5665 [inline]<br /> hub_event+0x58e3/0x89e0 drivers/usb/core/hub.c:5747<br /> process_one_work+0xdb6/0x1820 kernel/workqueue.c:2289<br /> worker_thread+0x10d0/0x2240 kernel/workqueue.c:2436<br /> kthread+0x3c7/0x500 kernel/kthread.c:376<br /> ret_from_fork+0x1f/0x30<br /> <br /> Local variable data created at:<br /> usb_read8+0x5d/0x130 drivers/staging/rtl8712/usb_ops.c:33<br /> r8712_read8+0xa5/0xd0 drivers/staging/rtl8712/rtl8712_io.c:29<br /> <br /> KMSAN: uninit-value in r871xu_drv_init<br /> https://syzkaller.appspot.com/bug?id=3cd92b1d85428b128503bfa7a250294c9ae00bd8

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: quota: fix loop condition at f2fs_quota_sync()<br /> <br /> cnt should be passed to sb_has_quota_active() instead of type to check<br /> active quota properly.<br /> <br /> Moreover, when the type is -1, the compiler with enough inline knowledge<br /> can discard sb_has_quota_active() check altogether, causing a NULL pointer<br /> dereference at the following inode_lock(dqopt-&gt;files[cnt]):<br /> <br /> [ 2.796010] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000a0<br /> [ 2.796024] Mem abort info:<br /> [ 2.796025] ESR = 0x96000005<br /> [ 2.796028] EC = 0x25: DABT (current EL), IL = 32 bits<br /> [ 2.796029] SET = 0, FnV = 0<br /> [ 2.796031] EA = 0, S1PTW = 0<br /> [ 2.796032] Data abort info:<br /> [ 2.796034] ISV = 0, ISS = 0x00000005<br /> [ 2.796035] CM = 0, WnR = 0<br /> [ 2.796046] user pgtable: 4k pages, 39-bit VAs, pgdp=00000003370d1000<br /> [ 2.796048] [00000000000000a0] pgd=0000000000000000, pud=0000000000000000<br /> [ 2.796051] Internal error: Oops: 96000005 [#1] PREEMPT SMP<br /> [ 2.796056] CPU: 7 PID: 640 Comm: f2fs_ckpt-259:7 Tainted: G S 5.4.179-arter97-r8-64666-g2f16e087f9d8 #1<br /> [ 2.796057] Hardware name: Qualcomm Technologies, Inc. Lahaina MTP lemonadep (DT)<br /> [ 2.796059] pstate: 80c00005 (Nzcv daif +PAN +UAO)<br /> [ 2.796065] pc : down_write+0x28/0x70<br /> [ 2.796070] lr : f2fs_quota_sync+0x100/0x294<br /> [ 2.796071] sp : ffffffa3f48ffc30<br /> [ 2.796073] x29: ffffffa3f48ffc30 x28: 0000000000000000<br /> [ 2.796075] x27: ffffffa3f6d718b8 x26: ffffffa415fe9d80<br /> [ 2.796077] x25: ffffffa3f7290048 x24: 0000000000000001<br /> [ 2.796078] x23: 0000000000000000 x22: ffffffa3f7290000<br /> [ 2.796080] x21: ffffffa3f72904a0 x20: ffffffa3f7290110<br /> [ 2.796081] x19: ffffffa3f77a9800 x18: ffffffc020aae038<br /> [ 2.796083] x17: ffffffa40e38e040 x16: ffffffa40e38e6d0<br /> [ 2.796085] x15: ffffffa40e38e6cc x14: ffffffa40e38e6d0<br /> [ 2.796086] x13: 00000000000004f6 x12: 00162c44ff493000<br /> [ 2.796088] x11: 0000000000000400 x10: ffffffa40e38c948<br /> [ 2.796090] x9 : 0000000000000000 x8 : 00000000000000a0<br /> [ 2.796091] x7 : 0000000000000000 x6 : 0000d1060f00002a<br /> [ 2.796093] x5 : ffffffa3f48ff718 x4 : 000000000000000d<br /> [ 2.796094] x3 : 00000000060c0000 x2 : 0000000000000001<br /> [ 2.796096] x1 : 0000000000000000 x0 : 00000000000000a0<br /> [ 2.796098] Call trace:<br /> [ 2.796100] down_write+0x28/0x70<br /> [ 2.796102] f2fs_quota_sync+0x100/0x294<br /> [ 2.796104] block_operations+0x120/0x204<br /> [ 2.796106] f2fs_write_checkpoint+0x11c/0x520<br /> [ 2.796107] __checkpoint_and_complete_reqs+0x7c/0xd34<br /> [ 2.796109] issue_checkpoint_thread+0x6c/0xb8<br /> [ 2.796112] kthread+0x138/0x414<br /> [ 2.796114] ret_from_fork+0x10/0x18<br /> [ 2.796117] Code: aa0803e0 aa1f03e1 52800022 aa0103e9 (c8e97d02)<br /> [ 2.796120] ---[ end trace 96e942e8eb6a0b53 ]---<br /> [ 2.800116] Kernel panic - not syncing: Fatal exception<br /> [ 2.800120] SMP: stopping secondary CPUs

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> firmware: sysfb: fix platform-device leak in error path<br /> <br /> Make sure to free the platform device also in the unlikely event that<br /> registration fails.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> coresight: syscfg: Fix memleak on registration failure in cscfg_create_device<br /> <br /> device_register() calls device_initialize(),<br /> according to doc of device_initialize:<br /> <br /> Use put_device() to give up your reference instead of freeing<br /> * @dev directly once you have called this function.<br /> <br /> To prevent potential memleak, use put_device() for error handling.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iio: accel: mma8452: use the correct logic to get mma8452_data<br /> <br /> The original logic to get mma8452_data is wrong, the *dev point to<br /> the device belong to iio_dev. we can&amp;#39;t use this dev to find the<br /> correct i2c_client. The original logic happen to work because it<br /> finally use dev-&gt;driver_data to get iio_dev. Here use the API<br /> to_i2c_client() is wrong and make reader confuse. To correct the<br /> logic, it should be like this<br /> <br /> struct mma8452_data *data = iio_priv(dev_get_drvdata(dev));<br /> <br /> But after commit 8b7651f25962 ("iio: iio_device_alloc(): Remove<br /> unnecessary self drvdata"), the upper logic also can&amp;#39;t work.<br /> When try to show the avialable scale in userspace, will meet kernel<br /> dump, kernel handle NULL pointer dereference.<br /> <br /> So use dev_to_iio_dev() to correct the logic.<br /> <br /> Dual fixes tags as the second reflects when the bug was exposed, whilst<br /> the first reflects when the original bug was introduced.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tpm: use try_get_ops() in tpm-space.c<br /> <br /> As part of the series conversion to remove nested TPM operations:<br /> <br /> https://lore.kernel.org/all/20190205224723.19671-1-jarkko.sakkinen@linux.intel.com/<br /> <br /> exposure of the chip-&gt;tpm_mutex was removed from much of the upper<br /> level code. In this conversion, tpm2_del_space() was missed. This<br /> didn&amp;#39;t matter much because it&amp;#39;s usually called closely after a<br /> converted operation, so there&amp;#39;s only a very tiny race window where the<br /> chip can be removed before the space flushing is done which causes a<br /> NULL deref on the mutex. However, there are reports of this window<br /> being hit in practice, so fix this by converting tpm2_del_space() to<br /> use tpm_try_get_ops(), which performs all the teardown checks before<br /> acquring the mutex.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tpm: fix reference counting for struct tpm_chip<br /> <br /> The following sequence of operations results in a refcount warning:<br /> <br /> 1. Open device /dev/tpmrm.<br /> 2. Remove module tpm_tis_spi.<br /> 3. Write a TPM command to the file descriptor opened at step 1.<br /> <br /> ------------[ cut here ]------------<br /> WARNING: CPU: 3 PID: 1161 at lib/refcount.c:25 kobject_get+0xa0/0xa4<br /> refcount_t: addition on 0; use-after-free.<br /> Modules linked in: tpm_tis_spi tpm_tis_core tpm mdio_bcm_unimac brcmfmac<br /> sha256_generic libsha256 sha256_arm hci_uart btbcm bluetooth cfg80211 vc4<br /> brcmutil ecdh_generic ecc snd_soc_core crc32_arm_ce libaes<br /> raspberrypi_hwmon ac97_bus snd_pcm_dmaengine bcm2711_thermal snd_pcm<br /> snd_timer genet snd phy_generic soundcore [last unloaded: spi_bcm2835]<br /> CPU: 3 PID: 1161 Comm: hold_open Not tainted 5.10.0ls-main-dirty #2<br /> Hardware name: BCM2711<br /> [] (unwind_backtrace) from [] (show_stack+0x10/0x14)<br /> [] (show_stack) from [] (dump_stack+0xc4/0xd8)<br /> [] (dump_stack) from [] (__warn+0x104/0x108)<br /> [] (__warn) from [] (warn_slowpath_fmt+0x74/0xb8)<br /> [] (warn_slowpath_fmt) from [] (kobject_get+0xa0/0xa4)<br /> [] (kobject_get) from [] (tpm_try_get_ops+0x14/0x54 [tpm])<br /> [] (tpm_try_get_ops [tpm]) from [] (tpm_common_write+0x38/0x60 [tpm])<br /> [] (tpm_common_write [tpm]) from [] (vfs_write+0xc4/0x3c0)<br /> [] (vfs_write) from [] (ksys_write+0x58/0xcc)<br /> [] (ksys_write) from [] (ret_fast_syscall+0x0/0x4c)<br /> Exception stack(0xc226bfa8 to 0xc226bff0)<br /> bfa0: 00000000 000105b4 00000003 beafe664 00000014 00000000<br /> bfc0: 00000000 000105b4 000103f8 00000004 00000000 00000000 b6f9c000 beafe684<br /> bfe0: 0000006c beafe648 0001056c b6eb6944<br /> ---[ end trace d4b8409def9b8b1f ]---<br /> <br /> The reason for this warning is the attempt to get the chip-&gt;dev reference<br /> in tpm_common_write() although the reference counter is already zero.<br /> <br /> Since commit 8979b02aaf1d ("tpm: Fix reference count to main device") the<br /> extra reference used to prevent a premature zero counter is never taken,<br /> because the required TPM_CHIP_FLAG_TPM2 flag is never set.<br /> <br /> Fix this by moving the TPM 2 character device handling from<br /> tpm_chip_alloc() to tpm_add_char_device() which is called at a later point<br /> in time when the flag has been set in case of TPM2.<br /> <br /> Commit fdc915f7f719 ("tpm: expose spaces via a device link /dev/tpmrm")<br /> already introduced function tpm_devs_release() to release the extra<br /> reference but did not implement the required put on chip-&gt;devs that results<br /> in the call of this function.<br /> <br /> Fix this by putting chip-&gt;devs in tpm_chip_unregister().<br /> <br /> Finally move the new implementation for the TPM 2 handling into a new<br /> function to avoid multiple checks for the TPM_CHIP_FLAG_TPM2 flag in the<br /> good case and error cases.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: pcm: Fix races among concurrent prealloc proc writes<br /> <br /> We have no protection against concurrent PCM buffer preallocation<br /> changes via proc files, and it may potentially lead to UAF or some<br /> weird problem. This patch applies the PCM open_mutex to the proc<br /> write operation for avoiding the racy proc writes and the PCM stream<br /> open (and further operations).

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> uaccess: fix integer overflow on access_ok()<br /> <br /> Three architectures check the end of a user access against the<br /> address limit without taking a possible overflow into account.<br /> Passing a negative length or another overflow in here returns<br /> success when it should not.<br /> <br /> Use the most common correct implementation here, which optimizes<br /> for a constant &amp;#39;size&amp;#39; argument, and turns the common case into a<br /> single comparison.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mac80211: fix potential double free on mesh join<br /> <br /> While commit 6a01afcf8468 ("mac80211: mesh: Free ie data when leaving<br /> mesh") fixed a memory leak on mesh leave / teardown it introduced a<br /> potential memory corruption caused by a double free when rejoining the<br /> mesh:<br /> <br /> ieee80211_leave_mesh()<br /> -&gt; kfree(sdata-&gt;u.mesh.ie);<br /> ...<br /> ieee80211_join_mesh()<br /> -&gt; copy_mesh_setup()<br /> -&gt; old_ie = ifmsh-&gt;ie;<br /> -&gt; kfree(old_ie);<br /> <br /> This double free / kernel panics can be reproduced by using wpa_supplicant<br /> with an encrypted mesh (if set up without encryption via "iw" then<br /> ifmsh-&gt;ie is always NULL, which avoids this issue). And then calling:<br /> <br /> $ iw dev mesh0 mesh leave<br /> $ iw dev mesh0 mesh join my-mesh<br /> <br /> Note that typically these commands are not used / working when using<br /> wpa_supplicant. And it seems that wpa_supplicant or wpa_cli are going<br /> through a NETDEV_DOWN/NETDEV_UP cycle between a mesh leave and mesh join<br /> where the NETDEV_UP resets the mesh.ie to NULL via a memcpy of<br /> default_mesh_setup in cfg80211_netdev_notifier_call, which then avoids<br /> the memory corruption, too.<br /> <br /> The issue was first observed in an application which was not using<br /> wpa_supplicant but "Senf" instead, which implements its own calls to<br /> nl80211.<br /> <br /> Fixing the issue by removing the kfree()&amp;#39;ing of the mesh IE in the mesh<br /> join function and leaving it solely up to the mesh leave to free the<br /> mesh IE.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: pcm: Fix races among concurrent hw_params and hw_free calls<br /> <br /> Currently we have neither proper check nor protection against the<br /> concurrent calls of PCM hw_params and hw_free ioctls, which may result<br /> in a UAF. Since the existing PCM stream lock can&amp;#39;t be used for<br /> protecting the whole ioctl operations, we need a new mutex to protect<br /> those racy calls.<br /> <br /> This patch introduced a new mutex, runtime-&gt;buffer_mutex, and applies<br /> it to both hw_params and hw_free ioctl code paths. Along with it, the<br /> both functions are slightly modified (the mmap_count check is moved<br /> into the state-check block) for code simplicity.