Vulnerabilities

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.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cifs: prevent bad output lengths in smb2_ioctl_query_info()<br /> <br /> When calling smb2_ioctl_query_info() with<br /> smb_query_info::flags=PASSTHRU_FSCTL and<br /> smb_query_info::output_buffer_length=0, the following would return<br /> 0x10<br /> <br /> buffer = memdup_user(arg + sizeof(struct smb_query_info),<br /> qi.output_buffer_length);<br /> if (IS_ERR(buffer)) {<br /> kfree(vars);<br /> return PTR_ERR(buffer);<br /> }<br /> <br /> rather than a valid pointer thus making IS_ERR() check fail. This<br /> would then cause a NULL ptr deference in @buffer when accessing it<br /> later in smb2_ioctl_query_ioctl(). While at it, prevent having a<br /> @buffer smaller than 8 bytes to correctly handle SMB2_SET_INFO<br /> FileEndOfFileInformation requests when<br /> smb_query_info::flags=PASSTHRU_SET_INFO.<br /> <br /> Here is a small C reproducer which triggers a NULL ptr in @buffer when<br /> passing an invalid smb_query_info::flags<br /> <br /> #include <br /> #include <br /> #include <br /> #include <br /> #include <br /> #include <br /> <br /> #define die(s) perror(s), exit(1)<br /> #define QUERY_INFO 0xc018cf07<br /> <br /> int main(int argc, char *argv[])<br /> {<br /> int fd;<br /> <br /> if (argc

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: pcm: Fix potential AB/BA lock with buffer_mutex and mmap_lock<br /> <br /> syzbot caught a potential deadlock between the PCM<br /> runtime-&gt;buffer_mutex and the mm-&gt;mmap_lock. It was brought by the<br /> recent fix to cover the racy read/write and other ioctls, and in that<br /> commit, I overlooked a (hopefully only) corner case that may take the<br /> revert lock, namely, the OSS mmap. The OSS mmap operation<br /> exceptionally allows to re-configure the parameters inside the OSS<br /> mmap syscall, where mm-&gt;mmap_mutex is already held. Meanwhile, the<br /> copy_from/to_user calls at read/write operations also take the<br /> mm-&gt;mmap_lock internally, hence it may lead to a AB/BA deadlock.<br /> <br /> A similar problem was already seen in the past and we fixed it with a<br /> refcount (in commit b248371628aa). The former fix covered only the<br /> call paths with OSS read/write and OSS ioctls, while we need to cover<br /> the concurrent access via both ALSA and OSS APIs now.<br /> <br /> This patch addresses the problem above by replacing the buffer_mutex<br /> lock in the read/write operations with a refcount similar as we&amp;#39;ve<br /> used for OSS. The new field, runtime-&gt;buffer_accessing, keeps the<br /> number of concurrent read/write operations. Unlike the former<br /> buffer_mutex protection, this protects only around the<br /> copy_from/to_user() calls; the other codes are basically protected by<br /> the PCM stream lock. The refcount can be a negative, meaning blocked<br /> by the ioctls. If a negative value is seen, the read/write aborts<br /> with -EBUSY. In the ioctl side, OTOH, they check this refcount, too,<br /> and set to a negative value for blocking unless it&amp;#39;s already being<br /> accessed.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rtc: pl031: fix rtc features null pointer dereference<br /> <br /> When there is no interrupt line, rtc alarm feature is disabled.<br /> <br /> The clearing of the alarm feature bit was being done prior to allocations<br /> of ldata-&gt;rtc device, resulting in a null pointer dereference.<br /> <br /> Clear RTC_FEATURE_ALARM after the rtc device is allocated.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ocfs2: fix crash when mount with quota enabled<br /> <br /> There is a reported crash when mounting ocfs2 with quota enabled.<br /> <br /> RIP: 0010:ocfs2_qinfo_lock_res_init+0x44/0x50 [ocfs2]<br /> Call Trace:<br /> ocfs2_local_read_info+0xb9/0x6f0 [ocfs2]<br /> dquot_load_quota_sb+0x216/0x470<br /> dquot_load_quota_inode+0x85/0x100<br /> ocfs2_enable_quotas+0xa0/0x1c0 [ocfs2]<br /> ocfs2_fill_super.cold+0xc8/0x1bf [ocfs2]<br /> mount_bdev+0x185/0x1b0<br /> legacy_get_tree+0x27/0x40<br /> vfs_get_tree+0x25/0xb0<br /> path_mount+0x465/0xac0<br /> __x64_sys_mount+0x103/0x140<br /> <br /> It is caused by when initializing dqi_gqlock, the corresponding dqi_type<br /> and dqi_sb are not properly initialized.<br /> <br /> This issue is introduced by commit 6c85c2c72819, which wants to avoid<br /> accessing uninitialized variables in error cases. So make global quota<br /> info properly initialized.