Vulnerabilities

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

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> NFSD: prevent underflow in nfssvc_decode_writeargs()<br /> <br /> Smatch complains:<br /> <br /> fs/nfsd/nfsxdr.c:341 nfssvc_decode_writeargs()<br /> warn: no lower bound on &amp;#39;args-&gt;len&amp;#39;<br /> <br /> Change the type to unsigned to prevent this issue.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/i915/gem: add missing boundary check in vm_access<br /> <br /> A missing bounds check in vm_access() can lead to an out-of-bounds read<br /> or write in the adjacent memory area, since the len attribute is not<br /> validated before the memcpy later in the function, potentially hitting:<br /> <br /> [ 183.637831] BUG: unable to handle page fault for address: ffffc90000c86000<br /> [ 183.637934] #PF: supervisor read access in kernel mode<br /> [ 183.637997] #PF: error_code(0x0000) - not-present page<br /> [ 183.638059] PGD 100000067 P4D 100000067 PUD 100258067 PMD 106341067 PTE 0<br /> [ 183.638144] Oops: 0000 [#2] PREEMPT SMP NOPTI<br /> [ 183.638201] CPU: 3 PID: 1790 Comm: poc Tainted: G D 5.17.0-rc6-ci-drm-11296+ #1<br /> [ 183.638298] Hardware name: Intel Corporation CoffeeLake Client Platform/CoffeeLake H DDR4 RVP, BIOS CNLSFWR1.R00.X208.B00.1905301319 05/30/2019<br /> [ 183.638430] RIP: 0010:memcpy_erms+0x6/0x10<br /> [ 183.640213] RSP: 0018:ffffc90001763d48 EFLAGS: 00010246<br /> [ 183.641117] RAX: ffff888109c14000 RBX: ffff888111bece40 RCX: 0000000000000ffc<br /> [ 183.642029] RDX: 0000000000001000 RSI: ffffc90000c86000 RDI: ffff888109c14004<br /> [ 183.642946] RBP: 0000000000000ffc R08: 800000000000016b R09: 0000000000000000<br /> [ 183.643848] R10: ffffc90000c85000 R11: 0000000000000048 R12: 0000000000001000<br /> [ 183.644742] R13: ffff888111bed190 R14: ffff888109c14000 R15: 0000000000001000<br /> [ 183.645653] FS: 00007fe5ef807540(0000) GS:ffff88845b380000(0000) knlGS:0000000000000000<br /> [ 183.646570] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 183.647481] CR2: ffffc90000c86000 CR3: 000000010ff02006 CR4: 00000000003706e0<br /> [ 183.648384] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> [ 183.649271] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> [ 183.650142] Call Trace:<br /> [ 183.650988] <br /> [ 183.651793] vm_access+0x1f0/0x2a0 [i915]<br /> [ 183.652726] __access_remote_vm+0x224/0x380<br /> [ 183.653561] mem_rw.isra.0+0xf9/0x190<br /> [ 183.654402] vfs_read+0x9d/0x1b0<br /> [ 183.655238] ksys_read+0x63/0xe0<br /> [ 183.656065] do_syscall_64+0x38/0xc0<br /> [ 183.656882] entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> [ 183.657663] RIP: 0033:0x7fe5ef725142<br /> [ 183.659351] RSP: 002b:00007ffe1e81c7e8 EFLAGS: 00000246 ORIG_RAX: 0000000000000000<br /> [ 183.660227] RAX: ffffffffffffffda RBX: 0000557055dfb780 RCX: 00007fe5ef725142<br /> [ 183.661104] RDX: 0000000000001000 RSI: 00007ffe1e81d880 RDI: 0000000000000005<br /> [ 183.661972] RBP: 00007ffe1e81e890 R08: 0000000000000030 R09: 0000000000000046<br /> [ 183.662832] R10: 0000557055dfc2e0 R11: 0000000000000246 R12: 0000557055dfb1c0<br /> [ 183.663691] R13: 00007ffe1e81e980 R14: 0000000000000000 R15: 0000000000000000<br /> <br /> Changes since v1:<br /> - Updated if condition with range_overflows_t [Chris Wilson]<br /> <br /> [mauld: tidy up the commit message and add Cc: stable]<br /> (cherry picked from commit 661412e301e2ca86799aa4f400d1cf0bd38c57c6)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: octeontx2 - remove CONFIG_DM_CRYPT check<br /> <br /> No issues were found while using the driver with dm-crypt enabled. So<br /> CONFIG_DM_CRYPT check in the driver can be removed.<br /> <br /> This also fixes the NULL pointer dereference in driver release if<br /> CONFIG_DM_CRYPT is enabled.<br /> <br /> ...<br /> Unable to handle kernel NULL pointer dereference at virtual address 0000000000000008<br /> ...<br /> Call trace:<br /> crypto_unregister_alg+0x68/0xfc<br /> crypto_unregister_skciphers+0x44/0x60<br /> otx2_cpt_crypto_exit+0x100/0x1a0<br /> otx2_cptvf_remove+0xf8/0x200<br /> pci_device_remove+0x3c/0xd4<br /> __device_release_driver+0x188/0x234<br /> device_release_driver+0x2c/0x4c<br /> ...