Vulnerabilities

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.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> can: m_can: m_can_tx_handler(): fix use after free of skb<br /> <br /> can_put_echo_skb() will clone skb then free the skb. Move the<br /> can_put_echo_skb() for the m_can version 3.0.x directly before the<br /> start of the xmit in hardware, similar to the 3.1.x branch.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> jffs2: fix memory leak in jffs2_scan_medium<br /> <br /> If an error is returned in jffs2_scan_eraseblock() and some memory<br /> has been added to the jffs2_summary *s, we can observe the following<br /> kmemleak report:<br /> <br /> --------------------------------------------<br /> unreferenced object 0xffff88812b889c40 (size 64):<br /> comm "mount", pid 692, jiffies 4294838325 (age 34.288s)<br /> hex dump (first 32 bytes):<br /> 40 48 b5 14 81 88 ff ff 01 e0 31 00 00 00 50 00 @H........1...P.<br /> 00 00 01 00 00 00 01 00 00 00 02 00 00 00 09 08 ................<br /> backtrace:<br /> [] __kmalloc+0x613/0x910<br /> [] jffs2_sum_add_dirent_mem+0x5c/0xa0<br /> [] jffs2_scan_medium.cold+0x36e5/0x4794<br /> [] jffs2_do_mount_fs.cold+0xa7/0x2267<br /> [] jffs2_do_fill_super+0x383/0xc30<br /> [] jffs2_fill_super+0x2ea/0x4c0<br /> [] mtd_get_sb+0x254/0x400<br /> [] mtd_get_sb_by_nr+0x4f/0xd0<br /> [] get_tree_mtd+0x498/0x840<br /> [] jffs2_get_tree+0x25/0x30<br /> [] vfs_get_tree+0x8d/0x2e0<br /> [] path_mount+0x50f/0x1e50<br /> [] do_mount+0x107/0x130<br /> [] __se_sys_mount+0x1c5/0x2f0<br /> [] __x64_sys_mount+0xc7/0x160<br /> [] do_syscall_64+0x45/0x70<br /> unreferenced object 0xffff888114b54840 (size 32):<br /> comm "mount", pid 692, jiffies 4294838325 (age 34.288s)<br /> hex dump (first 32 bytes):<br /> c0 75 b5 14 81 88 ff ff 02 e0 02 00 00 00 02 00 .u..............<br /> 00 00 84 00 00 00 44 00 00 00 6b 6b 6b 6b 6b a5 ......D...kkkkk.<br /> backtrace:<br /> [] kmem_cache_alloc_trace+0x584/0x880<br /> [] jffs2_sum_add_inode_mem+0x54/0x90<br /> [] jffs2_scan_medium.cold+0x4481/0x4794<br /> [...]<br /> unreferenced object 0xffff888114b57280 (size 32):<br /> comm "mount", pid 692, jiffies 4294838393 (age 34.357s)<br /> hex dump (first 32 bytes):<br /> 10 d5 6c 11 81 88 ff ff 08 e0 05 00 00 00 01 00 ..l.............<br /> 00 00 38 02 00 00 28 00 00 00 6b 6b 6b 6b 6b a5 ..8...(...kkkkk.<br /> backtrace:<br /> [] kmem_cache_alloc_trace+0x584/0x880<br /> [] jffs2_sum_add_xattr_mem+0x54/0x90<br /> [] jffs2_scan_medium.cold+0x298c/0x4794<br /> [...]<br /> unreferenced object 0xffff8881116cd510 (size 16):<br /> comm "mount", pid 692, jiffies 4294838395 (age 34.355s)<br /> hex dump (first 16 bytes):<br /> 00 00 00 00 00 00 00 00 09 e0 60 02 00 00 6b a5 ..........`...k.<br /> backtrace:<br /> [] kmem_cache_alloc_trace+0x584/0x880<br /> [] jffs2_sum_add_xref_mem+0x54/0x90<br /> [] jffs2_scan_medium.cold+0x3a20/0x4794<br /> [...]<br /> --------------------------------------------<br /> <br /> Therefore, we should call jffs2_sum_reset_collected(s) on exit to<br /> release the memory added in s. In addition, a new tag "out_buf" is<br /> added to prevent the NULL pointer reference caused by s being NULL.<br /> (thanks to Zhang Yi for this analysis)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> jffs2: fix memory leak in jffs2_do_mount_fs<br /> <br /> If jffs2_build_filesystem() in jffs2_do_mount_fs() returns an error,<br /> we can observe the following kmemleak report:<br /> <br /> --------------------------------------------<br /> unreferenced object 0xffff88811b25a640 (size 64):<br /> comm "mount", pid 691, jiffies 4294957728 (age 71.952s)<br /> hex dump (first 32 bytes):<br /> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br /> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br /> backtrace:<br /> [] kmem_cache_alloc_trace+0x584/0x880<br /> [] jffs2_sum_init+0x86/0x130<br /> [] jffs2_do_mount_fs+0x798/0xac0<br /> [] jffs2_do_fill_super+0x383/0xc30<br /> [] jffs2_fill_super+0x2ea/0x4c0<br /> [...]<br /> unreferenced object 0xffff88812c760000 (size 65536):<br /> comm "mount", pid 691, jiffies 4294957728 (age 71.952s)<br /> hex dump (first 32 bytes):<br /> bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb ................<br /> bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb ................<br /> backtrace:<br /> [] __kmalloc+0x6b9/0x910<br /> [] jffs2_sum_init+0xd7/0x130<br /> [] jffs2_do_mount_fs+0x798/0xac0<br /> [] jffs2_do_fill_super+0x383/0xc30<br /> [] jffs2_fill_super+0x2ea/0x4c0<br /> [...]<br /> --------------------------------------------<br /> <br /> This is because the resources allocated in jffs2_sum_init() are not<br /> released. Call jffs2_sum_exit() to release these resources to solve<br /> the problem.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> remoteproc: Fix count check in rproc_coredump_write()<br /> <br /> Check count for 0, to avoid a potential underflow. Make the check the<br /> same as the one in rproc_recovery_write().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> NFSD: prevent integer overflow on 32 bit systems<br /> <br /> On a 32 bit system, the "len * sizeof(*p)" operation can have an<br /> integer overflow.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cifs: fix handlecache and multiuser<br /> <br /> In multiuser each individual user has their own tcon structure for the<br /> share and thus their own handle for a cached directory.<br /> When we umount such a share we much make sure to release the pinned down dentry<br /> for each such tcon and not just the master tcon.<br /> <br /> Otherwise we will get nasty warnings on umount that dentries are still in use:<br /> [ 3459.590047] BUG: Dentry 00000000115c6f41{i=12000000019d95,n=/} still in use\<br /> (2) [unmount of cifs cifs]<br /> ...<br /> [ 3459.590492] Call Trace:<br /> [ 3459.590500] d_walk+0x61/0x2a0<br /> [ 3459.590518] ? shrink_lock_dentry.part.0+0xe0/0xe0<br /> [ 3459.590526] shrink_dcache_for_umount+0x49/0x110<br /> [ 3459.590535] generic_shutdown_super+0x1a/0x110<br /> [ 3459.590542] kill_anon_super+0x14/0x30<br /> [ 3459.590549] cifs_kill_sb+0xf5/0x104 [cifs]<br /> [ 3459.590773] deactivate_locked_super+0x36/0xa0<br /> [ 3459.590782] cleanup_mnt+0x131/0x190<br /> [ 3459.590789] task_work_run+0x5c/0x90<br /> [ 3459.590798] exit_to_user_mode_loop+0x151/0x160<br /> [ 3459.590809] exit_to_user_mode_prepare+0x83/0xd0<br /> [ 3459.590818] syscall_exit_to_user_mode+0x12/0x30<br /> [ 3459.590828] do_syscall_64+0x48/0x90<br /> [ 3459.590833] entry_SYSCALL_64_after_hwframe+0x44/0xae